/rss20.xml">
fedora

Fedora People
Blog List
RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll

CoreOS 45 Test Week

Posted by Fedora Magazine on 2026-09-16 08:00:00 UTC

The Fedora CoreOS and QA teams are gearing up for Fedora 45, and we need your help! We are organizing a Fedora CoreOS Test Week starting on September 21, 2026.

This event is a great opportunity for the community to test Fedora CoreOS (FCOS) based on Fedora 45 content before it officially reaches the testing and stable streams. By participating, you help us ensure a smooth and reliable experience for all users.

How does a Test Week work?

A Test Week is an event where anyone can help verify that the upcoming release works as expected. If you’ve been looking for a way to get started with Fedora contribution, this is the perfect entry point.

To participate, you simply need to:

  • Download the Fedora CoreOS test images.
  • Follow the step-by-step test cases provided.
  • Report whether the tests passed or failed on your hardware or VM.

The Wiki Page is your primary source of information for this event. It contains information on what to download (and from where), what and how to test, who you can contact if necessary, and where to report any bugs you may find. Once you have completed your tests, please log your results there!

Your contribution, big or small, makes a huge difference. Let’s work together to make Fedora CoreOS 45 a great release. Happy testing!

Privilege Escalation Vulnerabilities in NetworkManager Plugins

Posted by Michael Catanzaro on 2026-09-15 16:26:48 UTC

Andreas Gabriel Berbescu has reported several root privilege escalation vulnerabilities in various NetworkManager VPN plugins. If the VPN plugin is installed, then an unprivileged user can escalate to root by loading a malicious VPN configuration file:

While most obviously bad for multi-user systems, root privilege escalation is also a serious defense in depth problem for single user systems. You are vulnerable if you have the VPN plugin installed; it does not matter whether you actually use it or not.

These are not vulnerabilities in NetworkManager itself. The VPN plugins are each separate projects, with their own separate maintainers, hosted by GNOME rather than by freedesktop.org. The status of each project is a little different:

  • The NetworkManager-vpnc and Network-Manager-fortisslvpn git repos have both been archived. Contributions are no longer accepted, and you should uninstall them immediately. NetworkManager-vpnc users should migrate to NetworkManager-libreswan, and NetworkManager-fortisslvpn users should migrate to NetworkManager-openconnect.
  • network-manager-sstp is currently unmaintained, but it is not obsolete. If you are interested in SSTP, this project needs a new maintainer.
  • network-manager-iodine is maintained, and the maintainer has created a merge request to resolve this issue.

For more information on NetworkManager VPN plugins, see Josephine’s VPN plugin overview and announcement.

Announcing Fedora Linux Asahi Remix 45 Beta

Posted by Fedora Magazine on 2026-09-15 14:05:00 UTC

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

Fedora Linux Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. Fedora Asahi Remix 45 Beta includes all of the Changes from Fedora Linux 45. Notably, this is the first Fedora Asahi Remix release to include out of the box initial support for Apple M3, M3 Pro and M3 Max systems, which are now officially supported by Asahi Linux upstream. The GPU drivers to enable performant 3D acceleration on these M3 systems are not included at this point and will be available via a Mesa update in the future. This release also includes support for hardware accelerated H.264 and VP9 video decoding for all Apple Silicon systems; additionally, Apple M3 systems include support for AV1 decoding.

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

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

Announcing Fedora Linux 45 Beta

Posted by Fedora Magazine on 2026-09-15 14:05:00 UTC

Fedora Linux 45 Beta is here! On Tuesday, 15 September 2026 you can download or upgrade your systems from your usual spots to start enjoying what F45 has to offer early.

How to get the beta release

You can download F45 Beta, or our pre-release edition versions, from any of the following places:

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

The Fedora Linux 45 Beta release content is also available for Fedora Atomic Desktops, Spins and Labs, with the exception of the following:

  • MiracleWM (x86_64 and aarch64 isos)
  • Budgie-Atomic iso
  • Sway-Atomic iso

    • Fedora Linux 45 Beta highlights

    Fedora Linux 45 replaces the legacy in-kernel console with kmscon, bringing smooth rendering, better Unicode/font support, and enhanced system stability.

    Fedora Linux 45 now requires valid package signatures by default before installation, preventing unsigned packages from being installed unintentionally.

    Desktop secret management has also been standardized across environments with oo7, replacing legacy backend implementations like GNOME Keyring and KWallet.

    Fedora Linux 45 Beta has a lot of new versions available, including Podman 6, Pandas 3, MySQL and MariaDB, to name but a few, and boasts early access to updated toolchains and runtimes, including Python 3.15, Go 1.27, GCC 16.2, and glibc 2.44.

    Atomic Desktop ISO builds also now use image-builder, and Fedora Linux 45 beta adds systemd-oomd and zram swap support to Fedora CoreOS.

    Anaconda now has initial WebUI installation flows for Atomic Desktops, and native support for partitioning stratis filesystems.

    More information

    Visit the Fedora Linux 45 Change Set page for more details on the changes in store for this release.

    Syslog-ng repo for Amazon Linux 2023 updated to syslog-ng version 4.12

    Posted by Peter Czanik on 2026-09-15 13:28:47 UTC

    Two years ago, I created a syslog-ng repo for Amazon Linux 2023. As I received zero feedback, I left it alone until last week. The repo is now updated to the latest version of syslog-ng: 4.12.

    According to Fedora Copr download stats, my Amazon Linux 2023 repo has many downloads. However, for over two years, I received zero feedback from the community, no matter how many GitHub, e-mail or social media posts I used to ask users about their experiences and requirements. As any kind of package maintenance needs some effort, I left the repo alone without updates.

    Fast forward to last week: someone responded to my post on GitHub, asking for an update. So, once I got some idle time during a longer task, I updated the repo to syslog-ng version 4.12. During another break, I disabled Java support and slog, just as in any other repository we maintain.

    As usual, you can find my Amazon Linux 2023 repo at https://copr.fedorainfracloud.org/coprs/czanik/syslog-ng-amazon23/ and share your feedback at https://github.com/syslog-ng/syslog-ng/discussions/4965

    syslog-ng logo

    Originally published at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-repo-for-amazon-linux-2023-updated-to-syslog-ng-version-4-12

    What does AI Alignment mean in open source?

    Posted by Justin Wheeler on 2026-09-15 08:00:00 UTC
    What does AI Alignment mean in open source?

    In July, I shared an update about my new role as AI Alignment Community Architect at Red Hat, focused on Fedora. This post clarifies what that role entails, why "AI alignment" is more than a technical term, and how I plan to support the Fedora community in leveraging LLM-gen-AI.

    I organized this blog post into three sections:

    1. Reclaiming AI Alignment: The meaning behind the term.

    2. Model builder engagement: Why do we need bidirectional feedback loops?

    3. My work in Fedora: Upcoming priorities this quarter and the path forward.

    Note

    I use the term “LLM-gen-AI” throughout this article aligned to the Software Freedom Conservancy’s recommendations. This is in support of addressing this technology in community-first terms.

    Reclaiming AI Alignment: The meaning behind a term

    As I defined my new role, I carefully considered the title. The Fedora community sentiment toward LLM-gen-AI is deeply divided: some rally against it, while others push for rapid adoption without wider community consensus. I needed a title that signaled a neutral, balanced approach. My mandate at Red Hat is to support upstream projects in adopting AI, focused primarily on Fedora. Working in the “AI” space at Red Hat is fascinating because I am exposed to diverse ways that customers use and deploy innovative open source technology. Additionally, Red Hat provides real value by supporting customers in their “hybrid AI” journeys. Many of my Red Hat colleagues consistently push for more Free Software and open source answers for customers and enterprises building infrastructure to support AI inference, local models, and more. Red Hat has a responsibility to innovate when new technology opportunities emerge that its customers are acting upon. With this in mind, I am more convinced that LLM-gen-AI is something that open source maintainers and contributors can leverage for real workloads. There are opportunities to solve real problems and routine maintenance tasks for complex projects. LLM-gen-AI used right can support maintainers in automating boring, cyclical work so they can focus more on the exciting work of innovation and focused engineering efforts within their projects. Or even going outside and spending time offline.

    However, I distinguish "AI alignment" from "AI adoption." "AI adoption" communicates a pre-defined, non-negotiable stance where the goal is simply to increase usage. "AI alignment," by contrast, communicates that LLM-gen-AI use exists on a spectrum.

    My intent in Fedora is not to insist, but to negotiate and compromise. I want to align how our community uses these tools with our existing values, norms, and culture.

    CHAOSS AI Alignment Working Group & model builders

    My approach to "AI alignment" is influenced by the CHAOSS Project. I co-chair the CHAOSS AI Alignment Working Group with Emma Irwin and Coraline Ada Ehmke. Recently, Emma, Adrian Edwards, and I presented at FOSSY 2026 on this topic in greater detail. This experience frames my definition of "alignment" as I move forward in my new role.

    Traditionally, "AI alignment" is a term used by model builders to describe processes where communities have little influence. As LLM-gen-AI grows in widespread use, the power gap between those model builders and the communities they impact will widen. This creates an unsustainable dynamic in the safety and well-being of our communities with these new tools.

    We need more than just "AI adoption". We need bidirectional feedback loops. Free Software communities deserve a seat at the table. This is not just for iterating on model development, but for defining how we integrate LLM-gen-AI tools sustainably and responsibly.

    To achieve this, we (i.e., open source community citizens) need a stronger value proposition for engagement with model builders. Whether commercial or altruistic, we must persuade model builders that a community-driven approach is a critical advantage. If we refuse to engage, we risk Free Software values and culture being shut out of conversations entirely. So, I believe it is better to be an advisor than a bystander. Advising is its own form of open source contribution. Therefore, I lend my support toward the wider notion that "AI alignment" fosters two-way conversations that ensure model builders actually listen to the communities their work impacts.

    My work in Fedora: What I hope to work on next

    September 2026 is my first full month in this role. While there is still much to define, a few priorities have emerged. Here is where I will be focusing my initial energy:

    • Migrating "This Week in Fedora": Aurélien Bompard (@abompard) created a useful tool for AI-curated, human-reviewed weekly summaries. Currently, it lives on a personal fedorapeople.org space. I am beginning to work with Aurélien to migrate this to a weekly WordPress article on the Fedora Community Blog, since we first began talking about this in July. I am already submitting pull requests to support this transition.

    • Launching LLM-gen-AI Agent Skills: Together with the AI/ML SIG, we are building the Fedora Agent Skills Library. These define best practices for using LLM-gen-AI agents to automate routine maintenance. My immediate task is community architecture: setting up the repository for contributions and improving documentation so these skills are accessible and scalable.

    • AI/ML SIG Documentation: As the Fedora Docs Team works to identify "team captains" for specific topics, I am volunteering to lead AI/ML SIG documentation. This involves importing or deprecating content in the Quick Docs site and migrating extensive Wiki documentation to the Fedora Docs site, creating a central, discoverable home for all things LLM-gen-AI in Fedora.

    • An update to the Fedora AI-Assisted Contributions Policy?: Honestly, I am not sure about this one yet. But it seems apparent to me that eleven months after the Fedora Council first introduced the Fedora AI-Assisted Contributions Policy, it is time for an update. Nearly a full year of lived experience has happened within the framework of this lightweight policy. Furthermore, a coalition of Fedora contributors agree that an update is needed, but there is not a single, shared view of what those updates should be. It will take more community input and feedback to shape the next iteration to that policy. I anticipate facilitating inclusive future community conversations about what those changes should be.

    I am both excited and nervous to work with fellow Fedorans on these initiatives. I know there are strongly-held opinions on both sides of the LLM-gen-AI debate. (An understatement!) I accepted this role because I believe participation is more constructive than standing on the sidelines. My goal is to navigate this work in alignment with Fedora’s Four Foundations: Freedom, Friends, Features, First.

    Until next time!

    Since March 2026, I invested a lot of time into migrating my blog to a new publishing system and improving the website user interface. However, now that my site is fully functioning on a technical level, it is refreshing to begin writing content again here. There is more to come from me in this space. Expect new content about my work in Fedora and the LLM-gen-AI space, and other open source and personal items too.

    damiand commented on issue packaging/sponsors#794

    Posted by Damian Daniel on 2026-09-14 20:44:54 UTC
    Heads-up: sponsoring Damian Daniel (damiand) for scenefx

    Hi

    damiand opened issue releng/fedora-scm-requests#903

    Posted by Damian Daniel on 2026-09-14 18:29:29 UTC 
    {
 "action": "new_branch",
 "branch": "f45",
 "namespace": "rpms",
 "repo": "scenefx",
 "create_git_branch": true
}

    damiand opened issue releng/fedora-scm-requests#902

    Posted by Damian Daniel on 2026-09-14 18:28:46 UTC 
    {
 "action": "new_branch",
 "branch": "f44",
 "namespace": "rpms",
 "repo": "scenefx",
 "create_git_branch": true
}

    damiand opened issue releng/fedora-scm-requests#900

    Posted by Damian Daniel on 2026-09-14 17:32:47 UTC 
    {
 "action": "new_repo",
 "branch": "rawhide",
 "bug_id": 2529330,
 "description": "",
 "exception": false,
 "monitor": "monitoring",
 "namespace": "rpms",
 "onboard_packit": "no",
 "repo": "scenefx",
 "summary": "A drop-in replacement for the wlroots scene API with eye-candy effects",
 "upstreamurl": "",
 "backend": "custom",
 "project_name": "scenefx",
 "distribution": "Fedora"
}

    From September 07 to September 13

    Posted by Aurélien Bompard on 2026-09-14 14:52:00 UTC

    A primary focus across the Fedora project this week was the successful testing, blocker review, and official "GO" approval for the Fedora 45 Beta release, alongside preparations for associated test weeks. Another dominant, cross-group administrative discussion centered on this LLM-powered "This Week in Fedora" summary bot. Numerous teams debated whether to consent to automated data collection from their public Matrix channels, actively weighing the benefits of newcomer visibility against privacy concerns and the need to preserve informal, safe conversational spaces. Additionally, several desktop and server groups evaluated a Quality Assurance proposal to drop legacy hardware requirements from the list of release-blocking storage interfaces during installation. On the technical and operational front, infrastructure teams focused on RHEL 10 database migrations and Forgejo repository transitions, while various other working groups collaborated on package rebuilds, CVE triage processes, and managing a wave of orphaned packages to prevent maintainer burnout.

    Announcements

    In broader Linux community news, the newly announced Framework Laptop 12 will optionally come with the KDE Edition of Fedora Linux pre-installed, offering a hardware-validated experience straight out of the box. A recent Fedora Magazine article also highlights BTRFS boot failures and easy GUI methods for system recovery using a live USB to roll back to previous snapshots. Additionally, after navigating various processing challenges, the session recordings from the 2025 and 2026 Flock To Fedora events have officially been published to the project's YouTube and PeerTube libraries.

    For existing contributors, please be aware that the Fedora Linux 45 Beta is GO and will ship on September 15, 2026; mark your calendars as the Final Freeze will begin shortly after on October 6, 2026. On the community leadership front, Fedora Podcast 060 highlighted a changing of the guard: Shaun McCance is taking over as the new Fedora Community Architect, while Justin Wheeler transitions into a new AI Alignment Community Architect role. If you are looking for a way to get more involved, the Fedora Podcast is currently seeking a behind-the-scenes producer to help manage episode scheduling and guest lists.

    Council

    The Fedora Council met this week to push forward several ongoing governance and policy items. The newly drafted Fedora Forge Usage Policy reached its fifth iteration and is scheduled for a final vote at the next Council meeting, following extensive community discussion and a compromise regarding repository archiving rules. Additionally, the Council reviewed a temporary workaround for handling private issues on the Fedora Forge and deemed it sufficient for their needs, moving to close the related tracker.

    The Council also addressed Fedora's expiring recognition as a Digital Public Good (DPG). While the current and incoming Fedora Community Architects will handle the immediate 2026 renewal, the Council voted to formally ask the Mindshare Committee to take on the broader representation responsibilities going forward. In other business, brainstorming has begun for the Flock to Fedora 2027 Call for Proposals (CfP) themes, and a proposed Conflict of Interest policy addition was put on hold as discussions on Fedora Discussion suggest a formal policy change may be unnecessary.

    Decisions

    Contribution opportunities

    • Community members are invited to provide feedback and suggestions for the Flock to Fedora 2027 CfP Themes. Following the Council's initial drafting phase, the themes will be opened for wider community input from September 21 to October 16, 2026.

    Learn more about the Council team.

    FESCo

    FESCo concluded the requirements gathering phase for the upcoming Bugzilla migration, with an extensive analysis pointing toward migrating to a modernized Bugzilla (Harmony) instance rather than Forgejo due to critical missing tracking features. The committee also completed a massive review of the F45 Incomplete Changes, deferring several high-profile changes (including mkosi-initrd, disabling Vendor Change by default, and libxml215) to Fedora 46.

    Additionally, a significant policy exception was granted allowing the use of aws-lc Rust crates for cryptography. This unblocks projects relying on Rustls from using the unmaintained ring crate in favor of an AWS-supported implementation.

    Decisions

    Contribution opportunities

    • Dozens of packages maintained by gui1ty (Issue #3678) are slated for mass orphaning and will soon need new maintainers.
    • Community members looking to join the packager group have an opportunity to take over orphaned packages. Users have already expressed interest in mcelog (Issue #3665), xaos (Issue #3678), and python-anytree (Issue #3681), but some require packager sponsorship.
    • Feedback and testing are requested for the Encapsule isolated devel containers F45 Change Proposal, particularly regarding GUI support and SELinux policies.

    Learn more about the FESCo team.

    Packaging Committee

    Tyler Fanelli reported an issue when trying to add a newly approved package (libnsm) to the SCM system using the fedpkg request-repo command. The execution failed and returned a 404 Not Found HTML error from Pagure, prompting a request to the committee for advice on how to proceed.

    Learn more about the Packaging Committee team.

    Mindshare

    This week, the Mindshare committee was heavily focused on approving budgets and swag for upcoming international events, reflecting a strong global presence. Approved funding includes travel and swag for LinuxDays 2026 in Prague, IndiaFOSS 2026 in Bangalore, a Fedora Podcast recording trip to Texas Linux Fest, and event support for Software Freedom Day Bukidnon in the Philippines. Additionally, the committee confirmed its Fedora Council Representative for the current cycle and is considering formally adopting the representation of Fedora Linux in the Digital Public Goods Alliance (DPGA).

    The team is also working on improving post-event follow-up, keeping tickets open for Data Con LA and FrOSCon until event reports are submitted, and exploring a new standard template for event reporting to better evaluate the impact of community funding. Finally, a community request was submitted to collect Mindshare's public data, including Matrix chat logs, for this LLM-powered "This Week in Fedora" newsletter.

    Decisions

    • Confirmed that Akashdeep will remain the Mindshare representative to the Fedora Council for this cycle (URL).
    • Approved a $150 budget for Software Freedom Day Bukidnon 2026 (URL).
    • Approved a $200 travel budget and the distribution of stickers for LinuxDays 2026 in Prague (URL).
    • Approved travel support for Eric Hendricks to record Fedora Podcast episodes on-site at Texas Linux Fest 2026 (URL).
    • Approved $800 for travel and $200 for swag to host a Fedora sub-booth at IndiaFOSS 2026 (URL).
    • Approved sending stickers to promote Fedora among IT students at a technical school in Jankowice, Poland (URL).
    • Closed the Data Con LA Event Box Shipment ticket, moving remaining financial and reporting follow-ups to the main event ticket (URL).

    Contribution opportunities

    • A volunteer shadowing the Fedora Ambassadors process is being considered to help draft a standardized event report template for funded event owners.
    • The committee is seeking feedback on a proposal to collect its public data, including Matrix chat logs, for this LLM-powered weekly report called "This Week in Fedora."

    Learn more about the Mindshare team.

    Diversity & Inclusion

    This week, the Diversity & Inclusion team discussed whether to allow their communications to be collected for this LLM-powered weekly report called "This Week in Fedora." In issue #69, a request was made to ingest data from mailing lists, Discourse, the issue tracker, and the Matrix channel. Initial feedback is supportive of collecting data from Discourse and the tracker, but there is strong hesitation regarding the Matrix room. Keeping the Matrix room out of automated summaries is seen as critical for maintaining a safe space to discuss sensitive topics. Additionally, it was noted that the team's meetings are currently on a temporary pause.

    Learn more about the Diversity & Inclusion team.

    Workstation / GNOME

    The Workstation / GNOME group discussed the upcoming Fedora 45 release, notably tracking a Mutter bug that is currently breaking openQA tests for the 51 Release Candidate, and began searching for a volunteer author for the Fedora Magazine's release article. The QA team also requested feedback on a proposal to reduce the list of release-blocking storage interfaces during installation by dropping outdated technologies like PATA and Hardware RAID.

    Additionally, the working group deliberated on their strategy for Flathub integration, addressing pre-installation requirements and metadata fact-finding. Several package and tooling requests were debated by the community, including a proposal to add 1Password as an approved third-party repository, a suggestion to remove gamemode from Workstation, packaging the local AI assistant Newelle, and a request for consent to allow an LLM to collect Matrix channel history for community reports.

    Decisions

    • The working group decided to postpone the Flathub strategy discussion until fact-finding regarding available metadata is completed, at which point they will reconvene and potentially re-invite external developers. (Meeting Summary)

    Contribution opportunities

    Learn more about the Workstation / GNOME team.

    KDE

    This week, the KDE group announced the availability of the KDE Plasma 6.8 Beta for testing on Fedora 44 and 45. Alongside this, work is being tracked for the Plasma 6.8 release, including package updates, retirements, and required rebuilds due to library changes.

    In other discussions, the Fedora QA team requested feedback from desktop teams on a proposal to reduce the list of release-blocking storage interfaces during installation. Users also discussed how to disable startup and shutdown sounds in Plasma, and a Fedora 45 Blocker Review Meeting was scheduled to review bugs and freeze exceptions.

    Decisions

    • kcm_wacomtablet and kgamma will no longer receive updates as part of the Plasma 6.8 transition (Link).

    Contribution opportunities

    Learn more about the KDE team.

    Server

    This week, the Server Working Group heavily focused on Fedora 45 Beta testing, major restructuring of the Server documentation, and planning for upcoming feature announcements. Beta testing across local, remote, and SBC ARM installations has largely passed, though a regression in the KVM x86_64 image was identified in Beta 1.3. The documentation is being reorganized to feature a new "Postinstallation Customizations" section, and updates are being pushed to reflect DNF5 syntax changes. Additionally, the group reviewed a QA proposal to drop legacy storage interfaces from the release-blocking criteria and debated the adoption of an LLM-powered weekly summary bot for their Matrix channel.

    Decisions

    • The group agreed to create a new documentation section titled "Postinstallation Customizations" and position it immediately after the "Installation" guide. (Issue #228, Meeting)
    • Documentation referring to dnf group install will be updated to use group IDs (e.g., cinnamon-desktop-environment) instead of group names, as DNF5 no longer supports group names. (Issue #264)
    • The decision regarding the collection of Matrix channel data for LLM-powered weekly reports was deferred to an informal meeting, due to concerns regarding privacy and the need for an opt-out mechanism. (Issue #263, Meeting)

    Contribution opportunities

    Learn more about the Server team.

    Infrastructure

    The Infrastructure team made significant progress on the RHEL 10 database server migrations this week, successfully moving several staging databases (including koji and fas). Plans are forming for the next mass update window, which is targeted for the week before the final freeze. Several maintenance emergencies were efficiently handled, including planning reinstalls across the buildhw-x86 fleet to resolve a BTRFS inode exhaustion issue breaking 32-bit builds, and compressing firewall logs to prevent disk space exhaustion on ns* nameservers.

    In addition, the team welcomed new contributors from the community, granted heavybuilder access in Koji for the vtk and nodejs-electron packages, and set up new Copr tracking groups. They also resolved an intermittent Kerberos pre-authentication issue impacting Packit and RISC-V Koji by restarting the ipa01 service, and approved the collection of public Matrix chat data for LLM-powered community weekly reports.

    Decisions

    • Approved the collection of public Matrix channels (#admin and #forge) data for this LLM-powered "This Week in Fedora" report (Ticket #13552).
    • Approved a freeze break to increase storage on os-control01 to serve as a temporary backup scratch space for Forgejo (Ticket #13555).
    • Granted Koji heavybuilder channel access for the vtk and nodejs-electron packages (Ticket #13544, Ticket #13545).
    • Discontinued investigating Apache LoadBalancer monitoring in favor of opening a spike to migrate components to HAProxy (Ticket #13553, Ticket #13525).

    Contribution opportunities

    Learn more about the Infrastructure team.

    Release Engineering

    Fedora 45 Beta is officially a "GO" and is scheduled for release on September 15th, 2026. Prior to the final decision, multiple Beta release candidates were composed and tested, incorporating various blocker and freeze exception fixes. Additionally, a recurring issue causing Rawhide OSTree composes to fail due to missing commits was diagnosed as a race condition involving a weekly pruning job; manual repairs were applied to unblock composes while a permanent fix is developed.

    In other news, the upcoming Fedora 45 Blocker Review Meeting will take place on September 14th to review final blockers and freeze exceptions. The Release Engineering team has also agreed to include its Matrix channel discussions in automated LLM-generated weekly reports to improve team visibility and lower the barrier for new contributors catching up on active topics.

    Decisions

    Contribution opportunities

    Learn more about the Release Engineering team.

    Quality

    The Quality group successfully held the Fedora 45 Beta Go/No-Go meeting, resulting in a unanimous 'GO' decision for Release Candidate 1.3, which is scheduled to ship on September 15. The team also conducted blocker review meetings to handle freeze exceptions and blockers ahead of the beta release.

    In other activities, a formal proposal was submitted to reduce the list of release-blocking storage interfaces during installation, aiming to remove obsolete or untestable hardware requirements. Test days are actively being organized, including the ongoing Internationalization (i18n) test days, and upcoming events for KDE Plasma 6.7 and Fedora CoreOS. Additionally, the community discussed concerns regarding LLM summarization of informal Matrix channels, leaning towards excluding chat history to preserve conversational freedom.

    Decisions

    Contribution opportunities

    Learn more about the Quality team.

    Websites and Apps

    During the week of September 7 to September 13, 2026, the Websites and Apps group discussed a feature request for visualizing package dependencies. A user proposed adding an interactive web-based package dependency tree to packages.fedoraproject.org. The goal is to help users visually trace and understand why specific, seemingly unrelated packages are pulled in during dnf installations without having to remember complex terminal commands.

    In response, a community member noted that omitting the -y flag in dnf provides a preview of what will be installed, but agreed that requesting a built-in dependency tree view directly from dnf would also be a reasonable feature request.

    Contribution opportunities

    • Community members who know of existing interactive package dependency visualization tools are encouraged to share their links in the Interactive package dependency tree thread.
    • Web contributors and developers have an opportunity to explore adding an interactive dependency tree feature to packages.fedoraproject.org.

    Learn more about the Websites and Apps team.

    Design

    The Design team heavily focused on standardizing and redesigning the Jekyll-based website for "Project Resistor," a Fedora Remix. This effort was organized into an Epic, kicking off with research into existing remix sites and planning for initial wireframes. Alongside this new project, the team advanced the design of an EPEL Steering Committee badge, managed the archiving of older repositories migrated from Pagure, and began discussing consent for data collection in LLM-powered weekly community reports.

    Decisions

    • Decided to use existing Jekyll themes and components to redesign the Project Resistor website rather than building it from scratch.
    • Decided to keep older migrated repositories (like designassets) archived to maintain a clean workspace, and added custom Fedora-colored icons to active repositories to differentiate them.

    Contribution opportunities

    • Participate in the discussion regarding consent for LLM data collection of the team's Matrix channel and issue tracker.
    • Contribute to the initial research of existing Fedora remix sites and Jekyll themes to inspire the Project Resistor design.

    Learn more about the Design team.

    Docs

    The Docs team is evaluating new initiatives to streamline documentation and improve accessibility. A proposal is under discussion to generate llms.txt indexes for the English Fedora Docs site, aiming to help AI agents navigate the documentation more efficiently (Ticket #64). Concurrently, the team is polling members on whether to retain the "This Week in Fedora" summary bot in their Matrix channel (Ticket #63) and preparing to propose targeted questions for the Fedora Release Notes Change templates to better guide system change owners (Meeting).

    Internally, efforts to modernize documentation are progressing. A comprehensive review of outdated wiki pages is underway, requiring manual vetting of older content to prevent data loss, and a push is being made to deprecate legacy Commops SIG wiki pages in favor of the modern Docs site (Ticket #59). Work is also kicking off to update the Beginner's Guide for Fedora 45, presenting an excellent onboarding opportunity for new contributors.

    Decisions

    • The Docs team decided to manually vet outdated wiki pages for deletion rather than using automated batch scripts, minimizing the risk of accidentally deleting content that remains relevant to the broader community (Meeting).
    • The team resolved to draft specific, targeted questions for the official Fedora Change proposal templates to compel Change owners to clarify their target audience and user impact. This will be formally proposed to FESCo for approval (Meeting).
    • Meeting agenda threads on the Fedora Discussion forums will now be opened immediately following the conclusion of the previous meeting, rather than right before the next one, to allow more time for asynchronous participation (Meeting).

    Contribution opportunities

    • Fedora 45 Beginner's Guide: Contributors are needed to help update the Beginner's Guide for F45. This is noted as a straightforward task and an excellent starting point for newcomers. Feedback is also requested on whether to switch the guide's recommended backup solution from kbackup to Vorta (Meeting).
    • Matrix Bot Polling: Team members are asked to vote (+1 or -1) on whether to keep the "This Week in Fedora" bot active in the public Docs Matrix channel (Ticket #63).
    • Feedback on llms.txt: The team is seeking input on a proposal to generate llms.txt discovery indexes for the Docs site to better support AI agents and LLMs (Ticket #64).

    Learn more about the Docs team.

    Internationalization

    The Internationalization group kicked off the Fedora 45 i18n test week on September 7th, which notably includes a new section for testing installation-related issues.

    Additionally, an article proposal was submitted for the Fedora blog to highlight the recent migration of the MATE Desktop project translations to the Fedora Weblate instance. This migration transitions the MATE project from Transifex to an open-source collaboration platform, aiming to resolve previous upstream integration issues and improve the overall experience for translators and developers.

    Contribution opportunities

    Learn more about the Internationalization team.

    COPR

    The COPR group announced that they are dropping support for pyp2rpm as an on-the-fly specfile generator for PyPI builds. This change is being made because the Fedora package for pyp2rpm was recently retired. Users can continue submitting builds directly from PyPI using pyp2spec, which has been Copr's default option since 2023.

    The removal of pyp2rpm will go live with the next Copr release. The overall impact is expected to be minimal, as database metrics show only 9 builds used pyp2rpm in 2026, compared to over 114,000 builds that used pyp2spec. The remaining affected users are being notified off-list.

    Decisions

    • Support for pyp2rpm is being dropped from Copr in the next release due to its upstream Fedora package retirement; users submitting PyPI builds must use the default pyp2spec generator instead. (Source)

    Learn more about the COPR team.

    EPEL

    The EPEL team focused heavily on infrastructure maintenance following the recent mass-branching, specifically adjusting mock configurations and symlink scripts to accommodate the new CentOS Stream 10 structure ("10s"). Several package updates were released to the wider Linux community, including critical security fixes for gum (fixing three CVEs) and a pending fix for a djvulibre out-of-bounds write vulnerability. Additionally, new packages like keychecker were added to EPEL 10, and epel-rpm-macros was added to ELN.

    Internally, the team is actively refining their release engineering automation by converting legacy branching and archiving processes into RBAC-compatible Ansible playbooks. They are also discussing community governance topics, including whether to allow automated LLM tools to summarize their public Matrix chat logs, weighing transparency and accessibility against the casual, ephemeral nature of the chat medium.

    Decisions

    • Postponed the decision on whether to allow LLM data collection from the EPEL Matrix chat for one week to gather more community feedback (Issue #373).
    • Decided to restrict the epel-release latest symlink creation exclusively to EPEL 10.2 to prevent constant link churning across minor releases, bypassing 10.3 and 10.4 (Issue #117).

    Contribution opportunities

    • Community Feedback: Provide feedback on whether the public EPEL Matrix chat should be included in automated LLM weekly summaries (Issue #373).
    • Packaging Help: Assist in updating the Alma Kitten mock configurations to use the new CentOS Stream 10s paths, following the recent fixes applied to mock-core-configs (Issue #126).
    • QA/Testing: Investigate and resolve the dependency issue that caused negative karma for the yubikey-manager update in EPEL 10.

    Learn more about the EPEL team.

    ELN

    The ELN SIG met this week to discuss extending the EBS timeout duration for Bodhi updates and to review progress on image-builder configurations. The group agreed to extend the Bodhi update wait time to 24 hours, though implementation is deferred until after an upcoming asyncio rewrite. In addition, composes for Rawhide and ELN had been paused for a few days due to a systemd bug, but a fix is now available and composes are expected to resume.

    On the container front, the generic and minimal container images were updated to remove unwanted weak dependencies, and the fixes are currently rolling out. A new minimal install image is also planned, which will allow non-network installations without requiring the large DVD image. Finally, the group discussed and informally opted out of having a summarization bot process their main Matrix channel for the "This Week in Fedora" publication.

    Decisions

    • Increase the EBS Bodhi update wait time to 24 hours, contingent on adding an endpoint for administrators to terminate the wait early and sending an email notification at the 24-hour mark (discussed in Issue #586).
    • Opt out of the 'This Week in Fedora' Matrix channel summarization bot for the main ELN chat room (discussed in the meeting).

    Learn more about the ELN team.

    Atomic

    The Fedora Atomic group spent the week advancing integration efforts, most notably hosting a kick-off meeting for the proposed unification of Fedora CoreOS and Fedora bootc base images ahead of Fedora 46. This shift aims to consolidate community efforts, build pipelines, and documentation into a more unified strategy.

    On the technical side, contributors are investigating an issue where systemd-oomd fails to intervene during severe RAM exhaustion on Kinoite-based systems, and addressing image bloat by dropping redundant packages. Additionally, CI infrastructure on the new forge has successfully transitioned to Testing Farm, leading to the closure of previous runner requests.

    Decisions

    Contribution opportunities

    • Code contribution: Submit a Pull Request to remove totem-video-thumbnailer from the Silverblue image, starting in Rawhide: Issue 129
    • Testing: Help reproduce and test the systemd-oomd failure to intervene during severe RAM/zram exhaustion on pristine Fedora Kinoite: Issue 130
    • Community Feedback: Provide feedback on the inclusion of Matrix chat logs for the "This Week in Fedora" LLM-powered summary: Issue 128
    • Collaboration: Join the effort to build and distribute systemd-sysexts by participating in the proposal to create a systemd-sysexts SIG

    Learn more about the Atomic team.

    CoreOS

    The CoreOS group is preparing for the Fedora 45 Beta release scheduled for September 15, 2026. As part of this transition, the team plans to switch over next-devel and cut the first next release based on F45, while preparing for a test week starting on September 21. In other developments, releases for coreos-installer, afterburn, and zincati are planned for the current sprint, and the group is scheduling a dedicated meeting to discuss the unification of CoreOS and bootc in Fedora.

    Community interest continues to grow around the proposed systemd-sysexts SIG, with members actively joining the initiative to build and distribute system-extensions based on Fedora content.

    Decisions

    • Switch over next-devel and cut the first next release based on F45 assuming the Fedora 45 Beta Release occurs on schedule (2026-09-15).
    • Begin weekly releases of the next stream when entering "Final Freeze" as per the design guidelines.
    • Hold a CoreOS test week starting on 2026-09-21, kicking off with a video session on the first day.
    • Host and record a dedicated meeting to discuss CoreOS and bootc unification in Fedora.

    Contribution opportunities

    • Review and provide input on Tracker Issue #2185. The team mentioned they "could really use some eyes" on this if anyone has spare cycles.
    • Help investigate Tracker Issue #2184 to ensure the project is ready to support the new golang version.
    • Join the newly forming systemd-sysexts SIG by adding your name to the wiki page, as discussed in the forum proposal.

    Learn more about the CoreOS team.

    ARM

    This week, the ARM group investigated a potential Wi-Fi regression on the Raspberry Pi 5 following a recent brcmfmac-firmware update. The package maintainer noted that WPA3 has known upstream issues with this driver and suspected an access point misconfiguration rather than a package regression, advising the user to open a bug report if the problem persists. Additionally, the group was notified about the upcoming Fedora 45 Blocker Review Meeting, featuring a call for asynchronous voting on proposed blockers and freeze exceptions.

    Contribution opportunities

    • Review and vote on proposed blocker bugs and freeze exceptions for Fedora 45 using the Fedora QA blockerbugs app. Instructions for asynchronous voting can be found here.
    • Users experiencing firmware-related hardware regressions (such as Wi-Fi or Bluetooth issues) are encouraged to file comprehensive bug reports against the linux-firmware package.

    Learn more about the ARM team.

    Alternative Images

    The Alternative Images group held a meeting to announce the release of the CentOS Stream 10 RISC-V images, which include minimal Generic (qcow2) and P550 (raw) builds. These images are now available on the AltImage RISC-V page and the AltImages Download page. Currently, the images use a default centos:centos login with a forced password change, but the group plans to integrate the text-mode initial-setup package in the next quarterly release.

    Additionally, the group resolved previous issues with building RAW images using Kiwi and plans to release their first aarch64 RAW image soon, starting with a minimal build. This upcoming aarch64 release will also serve as a testbed for the initial-setup integration. It was also noted that Kiwi 11.0 is coming soon but will only be available for EPEL 10 and above due to dependency limitations in EPEL 9.

    Decisions

    • Integrate the text-mode initial-setup package into the next quarterly release of the RISC-V images, as decided in the Alternative Images meeting.
    • Begin producing aarch64 RAW images, starting with a minimal image, to test the initial-setup integration.

    Learn more about the Alternative Images team.

    Cloud

    The Cloud group's activity this week centered around data collection policies and project visibility. In Issue 447, the creator of the "This Week in Fedora" LLM-powered report requested the group's permission to ingest data from their mailing lists, Discourse tags, issue tracker, and public Matrix channel. The author emphasized that summarizing Matrix channels helps newcomers understand the group's current topics and tone, but explicitly requested the group's consent to ensure contributors feel comfortable with their chat messages being included in public summaries.

    Contribution opportunities

    • Group members are requested to review and provide feedback on Issue 447 regarding which data sources (mailing lists, Discourse, tracker, Matrix channel) they are comfortable having collected for the "This Week in Fedora" weekly report.
    • Individuals who wish to opt out of Matrix channel collection can request to have their specific usernames excluded from the LLM summary generation.

    Learn more about the Cloud team.

    AI & ML

    A discussion was opened regarding which data sources from the AI & ML group should be collected for "This Week in Fedora" (TWIF), an LLM-powered weekly report. The author (Ticket #39) proposed collecting data from mailing lists, Discourse, trackers, and the Matrix channel. While a participating group member agreed that collecting data from clearly public sources like trackers and forums is acceptable, concerns were raised about summarizing Matrix channel discussions due to the platform's more informal nature.

    Contribution opportunities

    • Provide feedback on Ticket #39 regarding whether the AI & ML Matrix channel should be included in data collection for the automated "This Week in Fedora" weekly reports.

    Learn more about the AI & ML team.

    RISC-V

    The RISC-V group made significant progress on system rebuilds, with the Fedora 45 rebuild mostly complete and Fedora 46 toolchains (Rust, Python, Perl) currently building. A major focus was resolving LLVM test suite failures on Fedora, specifically addressing MLIR, OpenMP, and Flang issues on RISC-V architectures through testing several pull requests from package maintainers.

    In the community, members are actively working on installer images and Fedora "omni" kernel builds. The group is also currently discussing whether to opt into having their Matrix channel, Discourse posts, and issue tracker collected for automated LLM-powered weekly Fedora reports.

    Decisions

    • It was determined that patches for MLIR and Flang are not needed for CentOS Stream 10 (c10s), as those sub-packages are not built on that platform (Ticket #2).

    Contribution opportunities

    • Community members are asked to provide feedback on whether they consent to having the #riscv Matrix channel, Discourse posts, and issue tracker collected to generate weekly LLM-powered Fedora reports (Ticket #30).

    Learn more about the RISC-V team.

    Security

    The Security SIG met this week to tackle the high volume of invalid CVE bugs being filed against Fedora packages. A tool called fedora-cve-triage is being updated to help maintainers interactively close these invalid reports. Red Hat Product Security shared that they are working on internal tools (ManifestCube and BomQ) and an SBOM database to improve vulnerability tracking, though these are not yet public. In the interim, the SIG plans to propose an opt-out mechanism for automated CVE reporting to protect package maintainers from burnout.

    In other discussions, the group is evaluating a request to allow an LLM-powered tool to summarize their Matrix channel and tracker activities for the "This Week in Fedora" report, with some members expressing ethical and accuracy concerns. Additionally, the scope for the proposed Fedora Privacy SIG has been refined to focus on privacy-related packaging and analyzing or mitigating privacy issues in existing packages, explicitly excluding legal compliance evaluation.

    Decisions

    • To file a formal ticket proposing an opt-out mechanism for automated CVE reporting to prevent package maintainer burnout, as decided in the weekly meeting.
    • To officially discuss and vote on the inclusion of the Security SIG's Matrix channel and tracker in the LLM-powered weekly report at the next meeting, following the creation of Ticket #22.

    Contribution opportunities

    • Provide feedback on the drafted scope and activities for the Fedora Privacy SIG.
    • Share opinions in Ticket #22 regarding whether the Security SIG's Matrix channel and issue tracker data should be collected for the LLM-powered "This Week in Fedora" report.

    Learn more about the Security team.

    Gaming

    An issue was opened regarding the collection of the group's data for an LLM-powered weekly report called "This Week in Fedora". The author is seeking the group's consent to aggregate activity from mailing lists, Discourse, the issue tracker, and particularly the Matrix channel, in order to improve visibility for newcomers and highlight engagement opportunities.

    Learn more about the Gaming team.

    DotNET

    The DotNET group received a request regarding the collection of the group's data for an LLM-powered weekly report known as "This Week in Fedora" (this page). The author is seeking permission from the group to gather activity data from their mailing lists, meetings, issue trackers, and the public Matrix channel. The goal of this data collection is to help newcomers catch up and to provide visibility for the group's work.

    Learn more about the DotNET team.

    Go

    During the Go SIG meeting, which was lightly attended due to a US national holiday, it was announced that Go 1.26 is already available in Fedora 43. Additionally, updates for Go 1.27.1 and 1.26.8 are currently pending in Bodhi.

    On the mailing list, a prospective packager reached out for assistance to finalize the adoption of the orphaned "fx" package. While the package review has successfully passed, the contributor is looking for a sponsor to grant them packager permissions so they can officially request the repository.

    Contribution opportunities

    • A sponsor is needed to approve packager group access for Emanuele Petriglia, which is required to complete the repository request for the newly reviewed "fx" package.

    Learn more about the Go team.

    Perl

    During the week of September 7 to September 13, 2026, the Perl group's activity consisted entirely of routine package maintenance on Fedora RPMs. Michal Josef Špaček successfully opened and merged multiple pull requests focused on version bumps and license additions across several Perl libraries.

    The updates included version bumps for perl-Locale-Codes, perl-Text-VCardFast, perl-Mail-JMAPTalk, perl-Net-DAVTalk, perl-Net-CardDAVTalk, and perl-Net-CalDAVTalk. A missing LICENSE file was also added to the perl-Mail-JMAPTalk repository.

    Decisions

    Learn more about the Perl team.

    Ruby

    Volunteer testing for Fedora 45 Beta 1.3 revealed a deployment issue when following the Ruby on Rails 8.1 change documentation. A tester encountered a dependency error involving rdoc and rbs, which maintainers identified was caused by inadvertently installing a newer version of RDoc directly from rubygems.org rather than relying strictly on Fedora dependencies.

    In response to the feedback, maintainer Vít Ondruch tested the deployment in a clean environment and subsequently updated the Fedora 45 change page. Notably, bundler-audit was removed from the instructions as it is unavailable on Fedora, helping to streamline future testing and prevent disruptive surprises for users deploying Rails applications on the upcoming release.

    Decisions

    Contribution opportunities

    • Volunteers are encouraged to continue testing the Ruby on Rails 8.1 deployment for Fedora 45 using clean environments (such as Mock or by clearing .local/share/gem) to ensure documentation accurately reflects necessary dependencies.
    • Users testing the Ruby on Rails deployment are requested to provide feedback on environmental setup steps to help make the change documentation more welcoming and accurate for newcomers.

    Learn more about the Ruby team.

    Rust

    This week, the Rust group discussed a proposal to include their communication channels in an LLM-powered weekly report called "This Week in Fedora" (this page). The author proposed collecting data from the mailing lists, Discourse, the issue tracker, and the public Matrix channel to help newcomers understand the group's current activities and foster participation. While members were generally accepting or neutral toward including data from the mailing list, Discourse, and issue tracker, multiple members expressed opposition or reservations regarding the ingestion of Matrix channel history.

    Learn more about the Rust team.

    Other Discussions

    Orphaning packages

    Package updates

    New contributor introductions

    • On the Sway mailing list, Damian Daniel introduced themselves and expressed interest in joining the Sway SIG to help package SwayFX and other wlroots-based compositors.

    Contribution opportunities

    Testing and Quality Assurance Skills There is a massive need for community testing, which serves as an excellent entry point for non-group members. Contributors can participate in dedicated events like the KDE Plasma 6.7 Test Week, the Fedora 45 i18n test week, and the tentatively scheduled F45 Fedora CoreOS Test Day. Independent testing is heavily requested for the proposed Google Drive integration in GNOME, the KDE Plasma 6.8 Beta, and the Ruby on Rails 8.1 deployment. Contributors with minimal time can simply run a dummy dnf distro-sync to test F44 to F45 upgrades, while those with debugging experience can help reproduce a systemd-oomd failure on Fedora Kinoite or review bugs using the QA blockerbugs app.

    Writing, Documentation, and Research Skills If you have writing skills, several groups need help drafting community-facing materials. The Fedora Magazine needs authors for the "What's New in F45" articles covering Workstation and Server. Newcomers are specifically encouraged to help update the Fedora 45 Beginner's Guide. More experienced writers can shadow the Mindshare committee to draft a standardized event report template or review the MATE Desktop migration article prior to publication. For those preferring research over writing, the Design team needs help researching Jekyll themes to inspire the Project Resistor design, and community opinions are widely sought on the Flock to Fedora 2027 CfP Themes and the Fedora Privacy SIG scope.

    Packaging and System Administration Skills The project currently has a high demand for packagers to take over orphaned packages, most notably dozens of packages formerly maintained by gui1ty (Issue #3678), as well as specific software like mcelog (Issue #3665), python-anytree (Issue #3681), mangohud, and ddcutil. Sysadmins and infrastructure-minded packagers can assist by fixing EPEL's Alma Kitten mock configurations (Issue #126), building missing packages for the Mailman RHEL 10 migration, or diagnosing a 404 error affecting libnsm on the Packaging mailing list. Those looking for new collaborations can join the newly forming systemd-sysexts SIG, the Crystal SIG, or the Sway SIG.

    Software Development and Automation Skills Developers are needed across multiple languages to build and maintain Fedora's tooling. Python and Matrix developers can help rewrite the Standupbot using the Maubot framework, while web developers can explore adding an interactive dependency tree to packages.fedoraproject.org. Automation engineers are requested to help automate Testcase_base_update_cli for Cloud tests (Ticket #938). Go developers can review CoreOS Tracker Issue #2184 to ensure readiness for the new golang version, and anyone familiar with metrics can help define "abnormal" triggers for Infrastructure's new Zabbix Varnish monitoring template. Finally, a quick Git pull request is needed to remove totem-video-thumbnailer from the Silverblue image (Issue 129).

    Fedora Badges Revamp Project: From The Ground Up

    Posted by Akashdeep Dhar on 2026-09-13 18:30:47 UTC
    Fedora Badges Revamp Project: From The Ground Up

    After years of technical research and foundational work, the Fedora Badges application service has been rebuilt from the ground up, and it is heading to production. Whether you have been collecting badges for years or you are brand new to the Fedora Project community, here is what is waiting for you there.

    Completely modernized user interface

    The archaic server rendered pages are now gone. The Fedora Badges application service now runs on a modern single page application. This provides you with a much faster and more responsive experience, while functioning across various screen sizes and devices types, all without full refreshes or front-end reloads.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest A

    Navigations have been revamped as well. But do not worry at all – if you have bookmarked any old service links, they should redirect you to the right place.

    Colour schemes, Dark mode

    You can now customize the look of the Fedora Badges application service choosing from eight colour schemes. Your choice flows through the various elements of the front-end – from navbar to borders, from charts to accents, etc. The dark mode and light mode switch respects your system preference and can also be toggled.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest B

    Your choices are persistent across visits residing in your session storage. As long as the same session is used, the colour schemes and dark mode settings stay.

    Revitalized badges collectathon experience

    Not only does the profile page show your precious badges, it also shows a radar chart that maps your collection across categories. This is a rudimentary method to gauge your progress and discover the areas you have not explored yet. Giving a means to diversify the activities, this encourages more people to join in.

    Fedora Badges Revamp Project: From The Ground Up
    Fedora Badges Revamp Project: From The Ground Up

    Manifest C

    The refreshed history page also adds a collection time-line chart showing yours (and your friends’) contribution activities over months and years at a glance.

    Compare (or compete) with your friends

    The renewed difference page lets you compare your badges collection with those of your friends’ possessions. See which badges you both share, which ones only you have, and most importantly, which ones they have earned that you have not yet. It’s a fun way to discover new badges and unearth new ways to contribute.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest D

    You can also reach out to your fellow community members for potential mentoring opportunities, based on their contribution activities and collected badges.

    Explore badges by rarities

    Every active badge now has a rarity tier based on how many users currently hold it:

    • Fedorable — Unobtanium stuff
    • Legendary — Mythical prestige
    • Epic — Serious bragging
    • Rare — Principled hustle
    • Uncommon — Striving future
    • Common — Warm greeting
    Fedora Badges Revamp Project: From The Ground Up
    Manifest E

    You can now browse active badges by their rarity tiers, making it easy to hunt down the ones that fewer people have earned. Not only does it allow you to find new pathways for contribution, you also get a sense of the impactful work and relevant tracks that are waiting for you in your community activities.

    Involved semantic collective lookup

    Departing from different searches for badges and users, the search bar now helps unified lookup across both badges and users. Start typing and results start appearing immediately after – with better lookup results. These will appear when the query is general enough to return more than eight results.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest F

    To save server resources, the asynchronous search request begins only when at least four characters are entered into the search bar for the query.

    Leaderboards with time navigation

    Departing from the restricted rankings page, it is now possible to request custom period filtering on the leaderboards page. Filters can be based on days, weeks, months, and years. One can see who has been earning most badges in those times, and generally look back at the community’s evolving progress over a time period.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest G

    The rankings are deterministic and can be shared with others, using the sharing link that inherently applies the same filters. This creates a reproducible resource.

    Clearer badge activity lifecycle

    Badges can now be manually marked as legacy (retired, unobtainable) after they should no longer be awarded to the users. For instance, the badges for joining the Fedora Linux Release Party 42 should no longer be available to new users in 2026. Hence, they should not be accounted for while computing rarity tiers.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest H

    And nope — we are not taking awarded badges away from users who have already earned them. These retired badges are still going to be visible in the history.

    Stronger foundational supports underneath

    You see, the revamp was not just about the front-end. The data layer that powers the application service got a major overhaul as well. The Database Library project, which handles all database operations, saw 105 commits across 7 contributors during the same period, pushing from version 1.4.1 to 1.5.5.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest I

    Here’s what changed under the hood, and why it matters to you:

    • Faster queries — Redundant database lookups were eliminated, foreign key indexes were added, and pagination now happens at the database level instead of in the application code. Pages that list badges or users load significantly faster, especially as the count of badges or users grow.
    • Effective lookup — The search you use from the navbar section is powered by new search methods added to the API. This covers both badges and users. This not only makes the search noticeably faster, but the actual process is also more efficient on a synchronous database accessing layer.
    • Rarity calculation — The rarity tiers you see on badge pages are computed every day by an updated algorithm in the API code. Various edge cases are now handled too. The fall-back is set to the common tier on zero available users who own the said badges at that particular time.
    • Legacy support — A schema level change was made to introduce a new legacy column to the badges table to distinguish active badges from the retired ones. Filtering is built into the API code so the front-end shows them on separate pages when requested by the users.
    • Categories normalization — Badge tags are now stored in their own tables instead of as raw comma separated strings. This makes category browsing reliable.
    • Cascading deletions — Removing a badge when done in exigent circumstances now properly cleans up its assertions in the database purging orphaned data.
    • Removing invitations — Invitations are soft deleted and not hard removed. This preserves access history while preventing accidental assertions.
    • Quality assurance — Nearly every new feature ships with its test cases. Python < 3.9 support was dropped in favor of Python > 3.13.

    Overall smoother authentication events

    Authentication has been reworked. The old session-based login has been replaced completely with a modern token-based flow using OpenID Connect. The application service now has its own dedicated authentication client so logging in through Fedora Accounts is more consistent across other things.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest J

    If you are visiting for the first time, like it has been for years, your user account is automatically created without requiring any further steps.

    Your privacy really matters

    Email addresses are no longer visible across various API responses. They are hashed before being sent as an asynchronous response, for use by Libravatar. Users have the choice to opt out of the Fedora Badges application service entirely. In that case they will stop receiving badge awards for their community tasks.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest K

    RSS feeds are now limited to recent entries for performance and efficiency, so you can still stay informed about the latest incoming activities on the app.

    For badge creators, maintainers and administrators

    If you are a part of the team, the new interface gives you a full set of tools.

    • Advanced database management front-end
    • Creating and revoking awards from your users
    • Creating and expiring invitations for the badges
    • Creating and revoking authorizations from your users
    • Creating and updating badges
    • Creating and updating users
    Fedora Badges Revamp Project: From The Ground Up
    Manifest L

    Access control is tiered — community members see the service experience, while authorized team members get the administrative controls they need.

    Progress by the numbers

    This revamp (codenamed स्वातंत्र्य or Svātantrya) represents a year of active work across the two repositories. These comprised 165 commits in Tahrir and 105 commits in Tahrir API. This occurred after many years of technical research and foundational work  resulting in a leaner codebase with a net reduction of 13,320 lines of code.

    Thank you to our amazing contributors

    I mean it when I say, this revamp would have been dead in the water without the help of the following folks (in the alphabetical order):

    • Akashdeep Dhar
    • Aurelien Bompard
    • Awwal Adetomiwa
    • Chibuezem Marvinrose
    • Daniel Mungai Chege
    • Emma Kidney
    • Gregory Sutcliffe
    • John Iweh
    • Joy Aruku
    • Kevin Fenzi
    • Michael Scherer
    • Michal Konecny
    • Olamide Peter Ojo
    • Payal Sumbhe
    • Shounak Dey
    • Vanshikha Shri
    • Yash Sheorey
    • Xavier Lamien

    And those, of course, from Flock 2026’s workshop on the Fedora Badges Revamp Project.

    • Ankur Sinha
    • Cornelius Emase
    • Emmanuel Seyman
    • Guillermo Leiro
    • Jakub Jelen
    • Jona Azizaj
    • Jonáš Hubený
    • Justin Wheeler
    • Mat Holmes
    • Matthew Miller
    • Misia Mary
    • Shawn Dunn
    • Vít Smolík
    • Vittorio Cioe

    This revamp project was in a development hell for quite some time. It was able to come out of it thanks to those listed above and countless others who have helped maintain the project for the past fourteen years or so. It is now time for me to pass this torch on to others who can help maintain this.

    The project codebase currently lives on the Fedora Infrastructure’s GitHub namespace. Please consider providing feedback and contributing changes to help maintain the projects. You can also hang out with us in the Fedora Badges chat room on Fedora Project’s Matrix server to learn more.

    Go on - give it a try!

    The production deployment should be live by the time this article is publicly available. Head over to Fedora Badges to explore the refreshed experience. As it might be a little rough around the edges in the starting days, please bear with us while we hammer down the oddities with your useful reports.

    Fedora Badges Revamp Project: From The Ground Up
    Manifest M

    Your input influences what comes next to the Fedora Badges application service. Please consider giving it a try right now and let us know what you think!

    This article was originally posted on Fedora Magazine on 19 August 2026.

    SeedboxSync v4.1 : Authentification OIDC, Gravatar et refonte de l’administration

    Posted by Guillaume Kulakowski on 2026-09-13 09:55:32 UTC
    Découvrez les nouveautés de SeedboxSync v4.1 : intégration d'un système d'authentification natif et OIDC (SSO), support de Gravatar, gestion des utilisateurs en CLI, formulaires Flask-WTForm et transition vers Peewee-Migrate.

    misc fedora bits: second week of sep 2026

    Posted by Kevin Fenzi on 2026-09-12 20:50:47 UTC
    Scrye into the crystal ball

    Another saturday, time for another recap of interesting things in longer form.

    RHEL10 database migrations

    I managed to migrate all but one database server in staging. No particular problems with those and they are all on postgresql 18 now with data page checksums enabled (well, except the single mariadb instance, and it's on 10.11.18). Hopefully I can get the production ones done in the next outage we have (probibly the week before final freeze).

    The last staging database server is more interesting: db-datanommer01.stg This is using timescaledb on top of postgres and is currently the rhel9 default version: 13.

    After looking around, I think this one is doable, but needs another step:

    • sync a data backup off the existing server

    • upgrade it to postgresql 16

    • enable data page checksums

    • install a new rhel10 vm

    • sync the data to it

    • upgrade to 18

    • install the correct timescaledb extension

    • take down the old instance and swap in the new

    I think this will all work, just an extra 13->16 jump. I will try it out in staging next week. I'm also a bit worried about how long it will take to generate all those checksums. The datanommer db's are really large. However, if we can do it I would love to as it's a very nice feature. Doing staging should at least give us an idea.

    Fedora 45 Beta is go for release next tuesday ( 2026-09-15 )

    Looks like we are go for fedora 45 beta next week. I hope everyone will test it out and help us iron out any problems before the final release.

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

    Wrapping up Google Summer of Code 2026 with GNOME!

    Posted by Felipe Borges on 2026-09-12 12:16:43 UTC

    It’s been another fantastic year for Google Summer of Code with GNOME! This year, six contributors worked on a range of interesting projects across our ecosystem.

    Our contributors have been blogging about their progress on Planet GNOME throughout the summer. In case you missed their updates, here is a breakdown of what they have worked on:

    Our interns also presented their work during GUADEC. You can watch their lightning talks on YouTube.

    This would not have been possible without the support of our community mentors. A huge thank you to Jonathan Blandford, Federico Mena Quintero, Alex Băluț, Yatin, Adrian Vovk, Jonas Ådahl, Robert Mader, Carlos Garnacho, and Philip Chimento. Mentoring takes a lot of time and energy, and it plays a vital role in onboarding new contributors to our community.

    If you are a GNOME developer and interested in mentoring a project next year, you can already start working on your project ideas and submit them at gitlab.gnome.org/Teams/internship/project-ideas.

    If you are a newcomer interested in starting your journey toward becoming a GNOME contributor, check out gsoc.gnome.org and stay tuned to Planet GNOME and our social media channels for updates on the 2027 program!

     

    De Jellystat à Jellydash : moderniser le suivi de mon serveur Jellyfin

    Posted by Guillaume Kulakowski on 2026-09-11 18:33:40 UTC
    Pourquoi et comment j'ai remplacé Jellystat par Jellydash pour le suivi des statistiques de mon serveur Jellyfin. Retour d'expérience sur la découverte de cet outil moderne, léger et prometteur repéré dans la newsletter selfh.st.

    🎲 PHP version 8.4.26RC1 and 8.5.11RC1

    Posted by Remi Collet on 2026-09-11 04:32:00 UTC

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

    RPMs of PHP version 8.5.11RC1 are available

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

    RPMs of PHP version 8.4.26RC1 are available

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

    ℹ️ The packages are available for x86_64 and aarch64.

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

    ℹ️ Installation: follow the wizard instructions.

    ℹ️ Announcements:

    Parallel installation of version 8.5 as Software Collection:

    yum --enablerepo=remi-test install php85

    Parallel installation of version 8.4 as Software Collection:

    yum --enablerepo=remi-test install php84

    Update of system version 8.5:

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

    Update of system version 8.4:

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

    ℹ️ Notice:

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

    Software Collections (php84, php85)

    Base packages (php)

    I packaged vLLM to illustrate the problem with Fedora’s branching strategy

    Posted by Gordon Messmer on 2026-09-11 00:00:00 UTC

    Diagram of dist-git branches

    A while back, a coworker at Red Hat mentioned that it would be useful to have a build of vLLM that supported a broader range of consumer AMD GPUs. Attempting to build vLLM raised the question, “Why is it easier to write a build process from scratch using shell scripts than it is to use Fedora’s build process tools?” Surely build process tools should make build processes easier to write.

    Many build process tools do make it easy to write build processes. Most contemporary languages are associated with a registry that makes it trivial to consume shared libraries. One of the most important characteristics of these systems is that developers can publish semantically “stable” releases. The stable release process allows developers to evolve the interface for the software they publish without breaking compatibility in projects that consume it. In order to support this, a system must allow developers to publish multiple interfaces simultaneously. Simultaneous publication means that software compatible with interface version 1 and software compatible with interface version 2 of a shared library can both continue to access an appropriate version of the shared library.

    That doesn’t necessarily mean that software using interface version 1 is outdated or unsafe. Developers can continue to publish maintenance releases to the v1 release stream while work on v2 is also active. Continued maintenance of old release series makes it viable to use a feature set and interface other than the newest one until a port to the new interface is finished.

    Distributions like Fedora follow a similar process. They also publish “stable” releases with overlapping lifecycles. That fact tends to obscure the thing that makes it very difficult to build complex software using distribution tools. A stable distribution release is just a snapshot of a rolling release, which continues to get updates for some period of time.

    The implications of that might be lost on some readers, so I’ll explain that statement a little bit. A rolling release component is one where there is a single version at any given point in time, unlike a stable release which allows users to select multiple releases based on their compatibility needs. It’s possible for distributions to offer stable release components. On Fedora 44, users can install any version of CPython from 3.10 through 3.15. But that’s not usually the case… there’s only one release of PyTorch available, and one ROCm. When more than one release is available it is because the maintainers have taken extraordinary steps to make more than one release available.

    That is the thing that makes non-trivial software much more difficult to build in Fedora (and most other distributions!) than it is to build almost any other way. The distribution is developed as a rolling release system, and every release branch inherits the basic characteristics of a rolling release, internally.

    vLLM demonstrates the problem building software in a rolling release model. While vLLM integrates support for the shared libraries it uses very quickly, the same is not necessarily true throughout its dependency stack. For example, that means that vLLM requires a very recent release of PyTorch (i.e. release 2.12 which will be featured in the upcoming Fedora 45 release), but its amd-quark dependency supports only much older Python releases (officially, up to 3.13). There is no release of Fedora that provides PyTorch 2.12 (and the rest of the massive collection of modules required by vLLM) for CPython 3.13.

    Nor is it easy for a Fedora package maintainer to arrange such a thing. It’s possible to have a build of PyTorch for a CPython release other than the default, as a “compat” package perhaps, but due to the way that Fedora structures it component repos and branches, there will only be one PyTorch compat package for all Fedora release. That means that the owner(s) of the PyTorch package will generally need to manage it. That creates a second major barrier, which is that the maintainers who need compatibility packages aren’t necessarily empowered to provide compatibility packages.

    There is a simple and straightforward solution to these problems. These problems are rooted in building a collection of software in which everything is synchronized and every component is flattened to a single version (a rolling release system.)

    Instead, Fedora could function more like registries, providing branches that reflect the releases of upstream projects. That doesn’t mean replacing distribution release branches; I expect they would be an addition.

    If Fedora dist-git repos had upstream-release branches, I would anticipate:

    1. Updates would need to be automated. We don’t want to make the work harder for maintainers.

    2. Fewer patches. Maybe none. Most of the patches I find are necessitated by the internal rolling release model. They support adapting to specific versions of dependencies.

    3. Packages in dist-git that are not in Fedora releases. Packages that don’t synchronize well with a distribution release are hosted without distribution release branches. Builds of these packages would be decoupled from a distribution release and delivered through some other channel (like Flatpak or other container image registry.)

    Solving this problem would allow Fedora to ship complex applications like vLLM that are infeasible for Fedora to build today. But it also enables functionality that I think is far more consequential.

    1. Closer to upstream configurations: Decoupling applications from the distribution can in some cases allow us to ship applications with a dependency set closer to the one that has been tested by the upstream projects. Numerous developers have complained about Fedora shipping applications with unsupported dependencies.

    2. Fewer packages: Applications are are decoupled from the distribution release can be built and shipped just at any given time instead of once per release. For example, it might not make sense to have multiple builds of OBS Studio, especially if we know that one of them does not work.

    3. Fewer packages lost to Fail-To-Build-From-Source: Many of our build failures with each release are the result of building an application before it’s ready for the dependencies that have been rebased for a release. Allowing them to update asynchronously might allow Fedora to keep applications that are actively maintained, but difficult to build in a rolling-release root.

    4. Zero-CVE releases: Automating spec updates and eliminating patches will allow many containers to build with low-cost deterministic build systems.

    5. Close the registry gap: Language-specific registries are an essential part of most developers workflows, with near universal adoption rates. Yet, despite decades of demonstrated utility for builds, no registry has emerged to provide that service in a language agnostic manner, to fill that role for languages like C and C++ that don’t have a dedicated registry or to tie together projects composed of code in multiple languages. Not only does no individual distribution have that kind of broad adoption, it’s not clear that distributions in general have that kind of adoption. If you ask for help building a CI pipeline that includes the latest version of “OpenSSL < 4” you will most likely end up with a shell script. Fedora’s dist-git can’t replace language-specific registries, but it could provide a language-agnostic equivalent to communities of developers who don’t have similar tools today. Many developers see RPM only as a format for builds delivered to platforms that use RPM to install software. From that point of view, RPM is overhead, not value. Providing a language-independent software registry that developers can use to create declarative CI and build pipelines frames RPM as a tool that enables reusable development workflows. If RPM is a tool that makes development easier, then developers have an incentive to participate that they lack today.

    Demo

    Because vLLM demonstrates the problems with Fedora’s branching model, I built a prototype vLLM pipeline that illustrates what a better branching model and build tooling might look like. The configuration below builds a sequence of components from source and then assembles a container image with the necessary runtime packages.

    Releases for which no package specifies an upper bound might use the “main” branch, while dependencies that do have an upper bound may use some “release-x.y” branch provided by the dist-git repo.

    The “packages” listed in this configuration are merely the path to a git repo relative to the “url” in the parent configuration. Much like Go’s decentralized module system, this does not rely on a centralized package registry, only on a sequence of dist-git or source-git repositories. It is both language-agnostic and decentralized.

    base: fedora-44-x86_64
localrepo: /home/gmessmer/git/vllm-build/vllm-result/

build:
  - type: dist-git
    url: https://src.fedoraproject.org/rpms/
    packages:
      - python-huggingface-hub:rawhide
      - python-click:f45
      - python-httpx2:f45
      - cpuinfo:f45
      - python-hatchling:main
      - python-jaraco-path:main
      - python-filelock:main
      - python-httpx-aiohttp:main
      - python-anthropic:main

  - type: dist-git
    url: /home/gmessmer/git/vllm-build/vllm-packages/
    packages:
      - python-safetensors:release-0.8
      - python-tokenizers:release-0.23
      - python-starlette:release-1.6
      - xnnpack:f44
      - python-torch:release-2.12
      - python-torchvision:release-0.27
      - python-torchaudio:release-2.11
      - python-torchdata:release-0.11
      - python-torchtext:release-0.17
      - python-torchdiffeq:release-0.2
      - python-torchsde:release-0.2
      - python-opencv-python-headless:main
      - python-partial-json-parser:main
      - python-pybase64:main
      - python-blake3:main
      - python-astor:main
      - python-depyf:release-0.20
      - python-openai-harmony:main
      - python-interegular:main
      - python-lm-format-enforcer:release-0.11
      - python-outlines-core:release-0.2
      - python-llguidance:release-1.7
      - python-model-hosting-container-standards:release-0.1
      - python-prometheus-fastapi-instrumentator:main
      - python-setuptools_scm:release-8.2
      - python-transformers:main
      - python-compressed-tensors:release-0.17
      - python-mistral-common:main
      - python-opentelemetry-semantic-conventions:main
      - python-opentelemetry-sdk:main
      - python-opentelemetry-semantic-conventions-ai:main
      - python-mcp-types:main
      - python-mcp:release-2.1
      - python-apache-tvm-ffi:release-0.1
      - python-xgrammar:release-0.2
      - python-peft:main
      - python-timm:main
      - python-tensorizer:release-2.10
      - python-fastsafetensors:main
      - python-conch-triton-kernels:release-1.2
      - python-llvmlite:release-0.47
      - python-numba:release-0.65
      - python-ml-dtypes:main
      - python-tilelang:release-0.1
      - protobuf:release-33
      - python-protobuf:release-6.33
      - python-proto-plus:release-1.26
      - grpc:release-1.78
      - libarrow:f44
      - python-googleapis-common-protos:release-1.75
      - python-opentelemetry-proto:main
      - python-opentelemetry-exporter-otlp-proto-common:main
      - python-opentelemetry-exporter-otlp-proto-grpc:main
      - python-opentelemetry-exporter-otlp-proto-http:main
      - python-opentelemetry-exporter-otlp:main
      - python-runai-model-streamer:main
      - python-amd-quark:main
      - python-vllm:main

install:
  type: container
  base_image: registry.fedoraproject.org/fedora:44
  tag: vllm:latest
  packages:
    - python-vllm

    Additional Illustrations

    A hypothetical project might have two stable release branches, for semantic release 1.0 and release 1.1. When Fedora 42 branched, release 1.0 was the “main” stable branch, so “f42” branched from release 1.0.3 and later merged release 1.0.4.

    The project published release 1.1.0 after f42 branched, and when that happened, a new branch was created for “release-1.1”. The branches “main” and “release-1” which had been following the 1.0 release series now follow the 1.1 release. When “f43” branched, the “main” branch was at 1.1.2.

    Because Fedora-release branches are de-coupled from the upstream-release branches, patches that are specific to Fedora can live in the Fedora branch, which allows automation to manage the upstream-release branches with fewer conflicts.

    We might also choose a different strategy for the “main” or “rawhide” branch. Today, “rawhide” doesn’t automatically follow new upstream releases. We might choose to preserve that behavior if the risk of new releases breaking Rawhide is too high. In that case, it would still be useful to represent upstream releases automatically to enable pipelines like the vLLM pipeline illustrated above, which require releases newer than any Fedora branch has merged.

    Diagram of dist-git branches with Fedora release branches

    Later, when upstream publishes release 1.2.0, a new “release-1.2” branch is created and “main” follows the new branch. When “f44” branches, it will branch from “rawhide” (/main). But even before any Fedora branch merges it, developers can consume the “release-1.2” branch for their own builds, outside of Fedora.

    This process allows application packagers to lead the distribution (probably publishing container images), rather than forcing them to build old releases of their own software to meet the constraints of dependencies in Fedora lagging behind upstream releases.

    De-coupling and automating the upstream-release branches allows the dist-git to function like a registry, helping developers publish metadata about their software immediately, without the delays required today to allow the other packages in Fedora to adapt. This gives application developers significantly more incentive to participate.

    At the same time, Fedora keeps its release branches, so it still retains distribution maintainer responsibility for the software the distribution publishes as RPM packages.

    Diagram of dist-git branches with Fedora release branches

    I’ll also note that Fedora doesn’t need to build any artifacts from the upstream-release branches. They just need to exist to enable application developers to build their own stacks, without being held back by what Fedora has managed to merge, and to allow them to build combinations of release streams that Fedora doesn’t, like PyTorch 2.12 with Python 3.13 and ROCm 7.

    Footnotes

    1. There is one “cheat” package in this stack. python-runai-model-streamer isn’t built from source, it’s just repackaging their binary wheel. This project uses the bazel build system which Fedora doesn’t ship and doesn’t have established guidelines. Getting bazel support in Fedora is an entire project all its own, so I’ve punted on building that package properly.

    The syslog-ng Insider 2026-09: Performance; Openssl; Containers; Learning;

    Posted by Peter Czanik on 2026-09-10 11:50:35 UTC

    Dear syslog-ng users,

    This is the 141st issue of syslog-ng Insider, a monthly newsletter that brings you syslog-ng-related news.

    New performance tuning possibilities in syslog-ng

    On April’s fool’s day, I shared that syslog-ng can reach 7 million EPS. This test lab result was in part possible thanks to a few performance enhancements coming to syslog-ng version 4.12. How 7 million EPS is possible? Before diving deeper, let me repeat it: 7 million EPS is just a lab testing result, not (yet) possible in the real world. However, the technologies enabling this are already available on the development branch of syslog-ng, or have been available for ages, just not tested or promoted enough.

    https://www.syslog-ng.com/community/b/blog/posts/new-performance-tuning-possibilities-in-syslog-ng

    Nightly syslog-ng containers based on Alma Linux

    For many years, the syslog-ng project provided container images based on Debian. Most of our users run syslog-ng on RHEL & compatibles, and have asked for an RPM-based container. So, nightly containers based on Alma Linux are now also available. A while ago, I prepared a small test project to run syslog-ng in an Alma Linux container: https://www.syslog-ng.com/community/b/blog/posts/experimental-syslog-ng-container-image-based-on-alma-linux However, that was only an experiment which I never updated. Fast forward to today: nightly syslog-ng containers based on the latest syslog-ng git snapshot package builds are now available on the Docker Hub!

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

    The status of OpenSSL 4.0 support in syslog-ng

    OpenSSL 4.0 was released just over a month ago. So, how is its support progressing in syslog-ng? Well, Git master already supports it, and the patch is easy to backport to earlier releases. At the same time, version 4.12 will support OpenSSL 4.0 out of the box.

    https://www.syslog-ng.com/community/b/blog/posts/the-status-of-openssl-4-0-support-in-syslog-ng

    Learning syslog-ng

    How can you learn syslog-ng? There are many possibilities, depending on your time and budget. Possibilities range from tutorial series through reading the documentation to instructor-led training. Find out which one is for you!

    https://www.syslog-ng.com/community/b/blog/posts/learning-syslog-ng

    syslog-ng logo

    Your feedback and news, or tips about the next issue are welcome. To read this newsletter online, visit: https://syslog-ng.com/blog/

    SystemIO conflicts are not firmware bugs

    Posted by Matthew Garrett on 2026-09-09 18:15:55 UTC

    I’m looking at something entirely unrelated, but tripped over some search results that made me realise that a lot of people still think getting errors like ACPI Warning: SystemIO range 0x0000000000001828-0x000000000000182F conflicts with OpRegion 0x0000000000001800-0x000000000000187F indicate a firmware bug. This is generally untrue. We need to dive a little into what ACPI is to clarify why.

    The Advanced Configuration and Power Interface1 specification defines a whole bunch of stuff, but what’s interesting to us here is the hardware abstraction it performs. While PCs are nominally a well-defined platform that’s really not true at the hardware level once you get beyond a certain level of complexity. When you suspend a system you want to power down the hardware in the correct order, for instance, and knowing what that order is requires you to know details about the specific motherboard design. The approach taken in the embedded world is to just bake that knowledge into the OS in some form, which is how we end up with Devicetree. ACPI takes an alternative approach - rather than provide that information as data that has to be consumed by OS drivers, it distributes it as code.

    The ACPI Source Language, or ASL, is a simple language that gets compiled into a bytecode that’s then interpreted by the OS at runtime. One of the features of this language is the ability to define “Operation Regions”, effectively structure definitions that describe access to underlying hardware. Let’s imagine a simple device with two exposed registers. The first is an index register - it describes which internal register we want to access. The second is a data register, where reading it gives us the value of the internal register whose address is currently in the index register, and writing to it modifies that register. An example operation region declaration would look something like

    1
2
3
4
5
6

    OperationRegion(OPR1, SystemIO, 0x400, 0x2)
Field(OPR1, ByteAcc, NoLock, Preserve)
{
  INDX, 8
  DATA, 8
}

    This defines an operation region called “OPR1” at IO port 0x400, 2 bytes long. Inside it are two 8-bit fields, INDX and DATA. These are to be accessed one at a time, do not need the ACPI interpreter to take a global lock when accessing them, and if a subset of the register is modified then the other values should be preserved (irrelevant in this case since the fields are only a byte wide). Now any references to INDX or DATA in this scope will trigger accesses to those registers. So, a method to read the value of register 0x03 would look something like:

    1
2
3
4

    Method (RD03) {
  INDX = 0x3
  Return (DATA)
}

    ie, set INDX to 3, and then read the value of DATA and return it. But! What if another ACPI method is running at the same time? Let’s say we have one that writes to register 0x05:

    1
2
3
4

    Method (WR05, 1) {
  INDX = 0x05
  DATA = Arg1
}

    What happens if RD03 executes while we’re part-way through WR05? INDX might get reset to 0x03, and now WR05 will modify register 0x03 instead of 0x05. Oh no! But we can avoid this - we declare a mutex (Mutex (MUTX, 0x00)), and update our methods to be something like:

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

    Method (RD03) {
  Acquire (MUTX, 0xFFFF)
  INDX = 0x3
  Local0 = DATA
  Release (MUTX)
  Return (Local0)
}

Method (WR05, 1) {
  Acquire (MUTX, 0xFFFF)
  INDX = 0x05
  DATA = Arg1
  Release (MUTX)
}

    Each method takes a lock (waiting up to 0xffff milliseconds and then erroring out if it doesn’t), and performs the access. There’s now no chance of a race. Phew!

    Now suppose someone writes a Linux driver for this piece of hardware. It accesses the hardware directly, with no knowledge of ACPI. What stops the driver from racing against one of the ACPI access methods? Nothing at all. Oh no! Again! This isn’t hypothetical, by the way - here’s a relatively harmless example, but back in the day we did trip over cases where temperature monitoring chips would be accessed by the firmware and Linux simultaneously and as a result you might end up thinking you’re reading a temperature when you’re actually reading a status flag, resulting in an impossibly high temperature and an immediate thermal shutdown.

    In this case, the kernel saves you from this (potentially hardware damaging) outcome by printing a message like ACPI Warning: SystemIO range 0x0000000000000400-0x000000000000401 conflicts with OpRegion 0x0000000000000400-0x0000000000000401 (OPR1), telling you that the kernel has detected that a driver is attempting to allocate IO ports 0x400-0x401, but that there’s an ACPI operation region called OPR1 that is claiming the same addresses. The kernel isn’t in a position to know what type of access the firmware might perform in that region, so assumes that it might be dangerous and blocks the driver from loading.

    But all is not lost! The kernel also prints some helpful advice, ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver. And ACPI tables will often actually have a definition that looks like this:

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

    Device (HDW1)
{
  Name (_HID, "VEND0001")
  OperationRegion(OPR1, SystemIO, 0x400, 0x2)
  Field(OPR1, ByteAcc, NoLock, Preserve)
  {
    INDX, 8
    DATA, 8
  }
  Mutex (MUTX, 0)
  Method (RD03) {
    Acquire (MUTX, 0xFFFF)
    INDX = 0x3
    Local0 = DATA
    Release (MUTX)
    Return (Local0)
  }

  Method (WR05, 1) {
    Acquire (MUTX, 0xFFFF)
    INDX = 0x05
    DATA = Arg1
    Release (MUTX)
  }
}

    which defines an ACPI device and associated methods. The _HID field defines the device type, and a Linux driver can be written that will be automatically loaded if a device with type VEND0001 is seen. That driver can then call ACPI methods associated with the device and access the resources in a way that matches the firmware’s expectations.

    (Interested in writing such a driver? I wrote a guide back in 2009)

    The firmware did absolutely nothing wrong here2, but trying to load the native driver will generate an error and the internet will tell you that PC firmware developers are incompetent3 and you should pass a kernel argument that overrides this behaviour and it never did them any harm, and it probably won’t do you any harm either but it might and you might never know why your system occasionally wedges or catches fire.

    1. The ACPI spec used to live at acpi.info, but sadly that seems to have vanished some time after UEFI took over stewardship of the spec ↩︎

    2. You might argue that the firmware should simply not do anything at runtime because it is not the firmware’s job to do that, and I do understand that and you can certainly boot with acpi=off if you want to and no ACPI code will be executed at runtime. Let me know how that goes. ↩︎

    3. I’m not going to present an opinion on that here, merely say that this provides no supporting evidence for that assertion ↩︎

    From August 31 to September 06

    Posted by Aurélien Bompard on 2026-09-09 08:53:00 UTC

    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

    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

    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

    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.

    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

    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

    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

    Orphaning packages

    Package updates

    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.

    From Livestream To Library: Publishing Flock To Fedora’s Session Recordings

    Posted by Fedora Magazine on 2026-09-09 08:00:00 UTC

    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.

    Recording Spreadsheets – Flock 2025

    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.

    Recording Spreadsheets – Flock 2026

    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.

    YouTube Playlist – Flock 2025

    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.

    Google Drive – Flock 2025

    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.

    Configuring Tracks – LosslessCut Application

    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.

    Configuring Outputs – LosslessCut Application

    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.

    Thumbnail Template – Flock 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.

    Thumbnail Proposal – Flock 2026

    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.

    YouTube Playlist – Flock 2026

    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…

    Google Drive – Flock 2026

    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.

    LosslessCut highlighting muxing exceptions

    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.

    Shounak’s suggested documentation changes

    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

    A Review of postmarketOS on the Fairphone Gen 6+

    Posted by Phoebe Harris on 2026-09-08 18:53:00 UTC

    Over the past 2 weeks, I've been daily-driving postmarketOS with phosh on a Fairphone Gen 6+ (From now on called FP6). I had previously been using a Fairphone 4 (FP4) with lineageOS, but I've had a good bit of experience with degoogled Android before that, including CalyxOS on the FP4 and /e/OS on a Samsung Galaxy S8. I'd like to document the parts I like about it, and expectedly, the parts that really aren't ready for use yet.

    I hadn't been planning on getting a newer Fairphone for a while (at least wait til Gen 7), but I left my FP4 in a Tesco and it got nicked. Oh well ;P

    What Went Well

    Networking and Personal Information Management

    GNOME's always had very strong online account features, and has the combination of not assuming that the user uses a particular ecosystem (see: /e/OS basically assumes that you have a Nextcloud). GNOME doesn't care if you use Nextcloud, Microsoft, or just something that exposes a webDAV and IMAP - it'll all appear in system apps all the same.

    Part of this seems to me to come from some of the specific benefits of a coordinated vision that Linux can benefit from in a way that's been mostly inaccessible to degoogled Android ROMs. While obviously Linux distributions are made of a lot of components by a lot of different projects, the UI layer is usually centralised under one project and one vision (GNOME, KDE, elementaryOS, etc). On the other hand, a degoogled Android ROM's UI features are going to be a mixture of AOSP, F-Droid, microG, Aurora store, bespoke apps, and so on.

    Compare, for instance, PIM in a degoogled ROM to that in Phosh. In Phosh, you sign in in GNOME Online Accounts, and you have access to mail (if using a GNOME mail client), contacts, calendars, the works. In LineageOS, I have to think about DAVx5, ICSx5, the Nextcloud app, and whatever calendar and contacts app my ROM is using. The difference in experience is night and day. /e/OS tries to paper over this but doesn't - I still find the same OS flows taking me to DAVx5/ICSx5 under the hood. In general, I find a lot of the time when Android ROMs try to integrate OS-level features they really just look like having an entry in settings redirect to an app - I see you, Seedvault hiding in LineageOS settings. In Linux, the whole stack belongs to us, and is centralised in single projects with a coherent vision and broad user-interface guidelines that allow third-party apps to feel like they fit in.

    Obviously this is a little limited by GNOME not really having a good mail app at the moment, but it looks like Stamp is getting really good. Plus, some of the ongoing work into further networking/PIM features in GNOME are really exciting - the upcoming local-first contacts portal and password autofill portal come to mind.

    Mapping

    Android has long had a bit of a maps problem. In general, the choice facing users has been to use some of the big nonfree mapping apps, like Google Maps or Magic Earth, or to forego important features like public transport routing. The open-source Android world is starting to catch up, with efforts such as an /e/OS maps app with transitous routing in alpha and work on integrating public transit into CoMaps ongoing, but GNOME Maps has public transport routing, not in alpha, right now, and has done for a while.

    The Hard Parts

    Hardware support

    Fairphones tend to be among the better-supported of pmOS devices, but the Fairphone 6 is a new phone (roughly a year old), and the hardware support really isn't there yet. Speakers don't work, microphone doesn't work, neither does fingerprint, NFC, or the camera. I had been betting on mobile data, SMS and bluetooth working (they're documented as working on the pmOS wiki), but I've had no luck. The system UI recognises that I have a SIM card, but I never connect properly, and BlueTooth has similar issues. With BlueTooth headphones out, that leaves me with basically no routes to play audio, and without being able to authenticate text messages, I can't use Signal, even with Linux-first clients like Flare. Basically, I have a computer that can connect to WiFi and has no audio.

    Dual-booting doesn't work particularly well either. You can install pmOS on an SD card and dual-boot it with /e/OS, but there's no ability to choose a boot partition at boot - you have to flash a new boot partition remotely each time.

    Waydroid

    Waydroid is a compatability layer that allows running Android apps on Linux systems. Theoretically, it should allow me to run the Android apps I need to run on my phone which don't have Linux clients - in particular, my Railcard, WhatsApp, my bank, etc.

    I've had no luck in getting it working - upon opening the app or invoking it from a CLI, it just causes the UI to flicker. I know other users have managed to get it working on FP6 hardware, but even then they've had Internet access issues.

    The screen flickering after opening Waydroid

    UI polish

    GNOME is a great desktop system, but Phosh and GNOME apps in many places don't feel polished. GNOME Apps benefit a lot from buttons having a lot of reactivity. A button takes a different appearance when the mouse is hovered over it, and a different appearance again when pressed

    Pressing the back button in a GNOME desktop

    On pmOS (Phosh + GNOME apps), this reactivity doesn't feel appreciable, meaning you don't get feedback on buttonpresses in a way that feels a bit choppy. I'm not sure pressing an app in the app list has any kind of tap feedback besides opening the app, for instance. Looking more closely, standard GTK UI buttons have feedback, but the visible press is less long on, for instance, back buttons, compared to Android.

    • Pressing the back button in phosh
    • Opening an app in phosh

    Many other gestures and interactions feel unpolished in a way that I don't have the UI skills to reliably identify.

    Copy-paste is also a bit of a mess. Different apps and system dialogues seem to have different avenues for copy-pasting. Some don't seem to be copy-pastable at all, and those differences are just across GNOME apps! In particular, I've found no way to paste a password into GNOME Online Accounts. Even just a paste button in the on-screen keyboard would provide a big improvement, but of course I'd really like to see a standard system text popup menu. I don't have the technical knowledge on Wayland and the XDG Desktop Portals to know what that looks like architecturally, but the current system isn't very good IMO.

    Misc

    Chatty isn't a very complete piece of software as it stands. Notably, it includes Matrix messaging features, but doesn't seem to be able to handle encrypted messaging at all. To an extent, non-Element Matrix clients lagging behind is pretty expected, but this feels like a pretty basic feature to not have working, especially for something installed out of the box.

    The UI allows setting a pin, and actively encourages it with a numpad password box. However, setting the password to something with letters still has the login screen bring up a numpad by default, creating a number PIN with a fairly normal amount of digits for a phone PIN will be rejected by the OS, and upon switching from the numpad to the keyboard in the login screen, you can't go back without reentering the login screen.

    Phosh gives you a popup asking about USB developer mode on the plugging in of any USB cable, even a dumb power cable.

    Conclusion

    With the mobile data, driver, and Waydroid issues unfortunately I don't think I can stick with postmarketOS for now. But I'm hopeful for the future! There's been a lot of movement on mainline drivers for FP6 recently (although from what I gather a lot of the work is vibecoded), and I think the big strides taken in the past ten years by the Linux desktop have proven that free software communities can create high-quality consumer software.

    Generally, as time's gone on the feasibility of free Android ROMs has been more and more difficult. Google's regularly slashed the update cadence of their publicly available security patches, and whereas once upon a time AOSP would have several high-quality apps in them, now new app development is mostly kept as nonfree Google additions. It remains to be seen whether the new sideloading lockdowns will strike a big blow to the degoogled Android ecosystem (remember - even if our degoogled ROMs don't lock down on sideloading, the loss of accessibility could damage the health of projects like F-Droid and NewPipe). In any case, I hope you don't think me too hasty in seeing this as a bit of a sinking ship. Mobile Linux matters.

    The success of free software initiatives have often depended on our ability to rise to crises. When Windows users railed against AI slop changes and the deprecation of Windows 10, we were able to step in with a high-quality operating system to offer. Now that European governments are realising the insanity of having most of their critical infrastructure rely on American companies, once again, Linux is ready to step in.

    Sometimes we fail - when Discord users railed against overbearing age attestation requirements, Matrix was not well placed to step in - it currently lacks basic features like screen sharing with audio in calls, or server roles. Hence, nothing changed.

    What about when the next crisis in the mobile ecosystem happens? When Android pushes a user-hostile update that the degoogled ROMs are unable to counter, will mobile Linux be able to step up?

    I hope the answer is yes, and I'm gonna throw some money towards postmarketOS. In a year, I'll write a second blog post assessing whether the following areas have improved:

    • Driver support (speakers, microphone, mobile data, BlueTooth, fingerprint, NFC, camera)
    • Ease of dual booting pmOS and Android.
    • Waydroid support
    • UI look and feel
    • Chatty polish

    Neuroscience AI assistant updates: scope, funding, ideas, and a name: Klea

    Posted by Ankur Sinha on 2026-09-08 16:16:56 UTC

    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.

    Screenshot showing Klea RAG's new interface with a query and result

    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.

    Screenshot showing Klea RAG's new interface's inspection pane showing different node outputs

    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.

    Loadouts For Genshin Impact v0.1.19 Released

    Posted by Akashdeep Dhar on 2026-09-07 18:30:15 UTC
    Loadouts For Genshin Impact v0.1.19 Released

    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

    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

    Installation command for Fedora Linux

    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.
    Loadouts For Genshin Impact v0.1.19 Released
    Loadouts For Genshin Impact v0.1.19 Released

    Heart of the Furnace - Workspace and Results

    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.
    Loadouts For Genshin Impact v0.1.19 Released
    Loadouts For Genshin Impact v0.1.19 Released

    Scarlet Proof - Workspace and Results

    Characters

    Two characters have debuted in this version release.

    Alyosha

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

    Loadouts For Genshin Impact v0.1.19 Released
    Loadouts For Genshin Impact v0.1.19 Released

    Alyosha - Workspace and Results

    Odette

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

    Loadouts For Genshin Impact v0.1.19 Released
    Loadouts For Genshin Impact v0.1.19 Released

    Odette - Workspace and Results

    Weapons

    Twelve weapons have debuted in this version release.

    Blade of Atonement

    Repentance and Redemption - Scales on ATK%.

    Loadouts For Genshin Impact v0.1.19 Released
    Blade of Atonement - Workspace

    Clash of Kings

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

    Loadouts For Genshin Impact v0.1.19 Released
    Clash of Kings - Workspace

    Covenant of Frost and Snow

    The Law's Equilibrium - Scales on DEF%.

    Loadouts For Genshin Impact v0.1.19 Released
    Covenant of Frost and Snow - Workspace

    Echoes of the Heart

    Echo of a Vow - Scales on ATK%.

    Loadouts For Genshin Impact v0.1.19 Released
    Echoes of the Heart - Workspace

    Emberwell

    Starfire Upon the Snowplains - Scales on Elemental Mastery.

    Loadouts For Genshin Impact v0.1.19 Released
    Emberwell - Workspace

    Exaiphanes Blade

    Traveler's Path - Scales on Crit Rate.

    Loadouts For Genshin Impact v0.1.19 Released
    Exaiphanes Blade - Workspace

    Forged by the Golden Melody

    Day and Night in Counterpoint - Scales on Crit Rate.

    Loadouts For Genshin Impact v0.1.19 Released
    Forged by the Golden Melody - Workspace

    Frostbreath

    A Cast Real Far - Scales on Energy Recharge.

    Loadouts For Genshin Impact v0.1.19 Released
    Frostbreath - Workspace

    Heretic's Molten Blade

    Lone Light's Blessing - Scales on Crit Rate.

    Loadouts For Genshin Impact v0.1.19 Released
    Heretic's Molten Blade - Workspace

    Jade Vista

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

    Loadouts For Genshin Impact v0.1.19 Released
    Jade Vista - Workspace

    Song of the Vigil

    Cadence of Days Gone By - Scales on Elemental Mastery.

    Loadouts For Genshin Impact v0.1.19 Released
    Song of the Vigil - Workspace

    Whitelake Frostfeather

    Snow Swan's Finale - Scales on Crit Rate.

    Loadouts For Genshin Impact v0.1.19 Released
    Whitelake Frostfeather - Workspace

    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.

    Rolling Wireless RW350R-GL / Fibocom FM350R-GL (5G module) on Linux

    Posted by Andreas Haerter on 2026-09-07 12:28:00 UTC

    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:

    Name Where you see it
    Rolling Wireless RW350R-GL Lenovo sales and order pages
    Fibocom FM350R-GL the actual design, and the FCC filing
    MediaTek T700, 5G Solution 5000 lspci output
    14c3:4d75 PCI ID, shared with the Fibocom FM350-GL
    2099:3552 PCI subsystem ID, Rolling Wireless
    mtk_t7xx kernel driver
    Dell DW5931e Dell’s name for the same family

    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.

    Framework Laptop 12 Arrives with Fedora Pre-installed

    Posted by Fedora Magazine on 2026-09-07 08:00:00 UTC

    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.

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

    Posted by Rob McBryde on 2026-09-05 18:48:01 UTC

    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:

    BenchmarkPop!_OS 22.04 LTSProject BluefinPerformance Gain
    Single-Core Score2,0652,264+9.64%
    Multi-Core Score11,38813,665+20.00%

    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>

    misc fedora bits: first week of sep 2026

    Posted by Kevin Fenzi on 2026-09-05 18:10:05 UTC
    Scrye into the crystal ball

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

    RHEL10 migrations: databases

    Next up on the migration train: databases. It turns out we already had one database server in staging moved to rhel10, but it was using the default postgresql 16 and since I am going to the trouble to migrate things to a new os, might as well move them to newer postgresql too.

    postgresql 18 makes data page checksums default. You can disable them at startup if you really want to, but they seem like a really good idea to enable. So, I took db-koji01.stg down and added checksums and it took around 45minutes. Not super great, but not nearly as bad as it could be.

    Then, the upgrade to 18 was super fast and painless.

    I did some work in our ansible repo to set up rhel10 hosts with postgresql18 to start with and created a db-fas02.stg to migrate that to.

    The rest of these servers will follow basically this pattern:

    • Setup a rhel10/postgresql18 02 vm for each server

    • Sync data from rhel9 one.

    • Stop rhel9 one (OUTAGE)

    • Sync data again from rhel9 one.

    • Enable data page checksums

    • Migrate from 16 to 18

    • Profit

    I hope to get the staging ones all done next week and find any issues, then we can look at scheduling an outage after Beta freeze to do all the production ones.

    Laptop Battery replacement

    My lenovo slim7x battery was getting pretty pathetic. It was 2 years old and it's max full capacity was something like 35% of design full and sometimes it was now refusing to charge without a reboot.

    So, I ordered a new battery and installed it this last week.

    This laptop is anoying to work on because, while there are screws on the bottom panel, it's also held on by clips. So you have to pry it off and it sounds like you are breaking it while doing so. Anoying.

    Also on this laptop they routed all the cables around the battery. The battery has cable guides all around it. So, to replace the battery you have to move all those cables carefully and slide the old battery out and new one in, along with unplugging the bluetooth and wifi antennas, and disconnecting/connecting the battery connector.

    I did manage to do it, but it took more time that I thought it would.

    While I had the machine open I swapped the windows drive I had back in and updated the firmware (which there's no way to do from linux). It was quite a pain. windows took quite a while to notice that it was not 2024 and that it should check what _current_ updates were available. Did manage it in the end. I don't know what effect the newer firmware has, everything still works the same as far as I can tell.

    Fedora 45 beta rc's

    We have started making rc's for beta. That sure reads weird, but if you are able, please do test and file bugs.

    Authentication issues

    There's one weird auth issue I am aware of. Thats where services with keytabs are sometimes getting permission denied. It seems to be somehow some differing config on two of our ipa servers. Thats being tracked in https://forge.fedoraproject.org/infra/tickets/issues/13539

    I am not aware of any other issues remaining. So, if you hit something, please do file a ticket and include enough information for us to try and fix it. ie, time/date, exactly what you were trying to login to, exactly what error message you got, etc.

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

    BTRFS boot failure and easy GUI methods for system recovery

    Posted by Fedora Magazine on 2026-09-04 20:54:40 UTC

    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

    how to use a partition manager to discover what file system that you are using

    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.

    ways to install btrfs-assistant using Fedora

    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:

    The btrfs-assistant user interface showing the range of system maintenance options

    Sub-Volumes

    Registration of existing sub-volumes is automatic:

    graphical viewing of btrfs sub-volumes using btrfs-assistant


    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:

    using live boot to view btrfs sub-volumes and snapper configs to setup automated snapshots

    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’:

    Setting up BTRFS Snapper configs

    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.

    snapper retention numbers need adjusting

    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:

    browse and restore with btrfs-assistant

    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.

    selecting btrfs maintenance schedules

    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:

    how to reboot into the uefi/bios from your operating system

    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.

    Gnome Disks interface and how to make a partition backup image

    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.

    btrfs-assistant restore proceedure

    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:

    installation of dndragora

    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.

    How I use LLM for my work

    Posted by Marcin Juszkiewicz on 2026-09-04 14:40:00 UTC

    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.

    Friday Links 26-28

    Posted by Christof Damian on 2026-09-03 22:00:00 UTC
    A black Sony Walkman music player on a dark leather surface, screen showing a podcast episode of The Europeans ready to play, with grey Sony in-ear headphones coiled around it

    A short one this week. The management reading list gave me some new ideas and the interview with Mr. T is great.

    Quote of the Week
    I’ve become absolutely convinced that the seminal difference between successful companies and mediocre or unsuccessful ones has little, if anything, to do with what they know or how smart they are; it has everything to do with how healthy they are.
    The Advantage
    Patrick M. Lencioni

    Leadership

    Good Culture is the Biggest Productivity Hack, Not AI - It relates to the quote above.

    Maintainer’s Guide to Hackfests

    Posted by Ben Cotton on 2026-09-02 12:00:00 UTC

    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.

    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.

    Using syslog-ng with Elasticsearch 9.5

    Posted by Peter Czanik on 2026-09-02 11:49:17 UTC

    Recently, I heard complaints within the syslog-ng community that using Elasticsearch is not that easy anymore. I installed Elasticsearch 9.5 with Kibana to verify these claims.

    Read more at https://www.syslog-ng.com/community/b/blog/posts/using-syslog-ng-with-elasticsearch-9-5

    syslog-ng logo

    Faster builds and better answers: GPU acceleration and model comparison for Fedora’s RAG assistants

    Posted by Francois Gonothi Toure on 2026-09-01 16:11:34 UTC

    An Outreachy internship note on the Fedora AI/ML editorial and packaging assistants

    CPU/GPU banner image created with Google Gemini’s Nano Banana

    As part of my Outreachy internship with the Fedora Project, I built two retrieval-augmented generation (RAG) assistants: one for the Fedora editorial guidelines (Community Blog and Magazine) and one for the Fedora packaging guidelines. Both share the same key step: building a vector store. The assistant reads the source documents, splits them into chunks, and turns each chunk into an embedding it can search later.

    For most of the internship, I ran these builds without a GPU. Once I had access to a GPU instance, I re-ran the same builds on the GPU and measured the difference. On both projects, the result was about the same: roughly a 13x speedup.

    What was measured

    For each project, I built the vector store twice, holding the work identical and changing only whether the GPU was used:

    • Same corpus per project, the same chunk size, and the same embedding model on both runs.
    • Identical output: the chunk count matched between the CPU and GPU runs, confirming both did the same work (8888 chunks for the editorial guide, 6137 for the packaging guide).

    A note on method: the two projects were measured slightly differently. For the editorial guide, both runs were on the GPU instance, with the GPU enabled for one and disabled for the other. For the packaging guide, the CPU run was on a local laptop, and the GPU run on the instance. So the packaging comparison is across two machines rather than one machine toggled. Either way, the question is the same: how much does proper GPU hardware speed up the build? The answer was consistent across both.

    The result

    Editorial guide assistant

    Observations made for the editorial-guide-ramalama on CPU/GPU

    Packaging guide assistant

    Observations made for the packaging-guide-ramalama on CPU/GPU
    Both builds ran about 13 times faster on the GPU

    Why the GPU helps here

    The slow part of these builds is embedding: turning each text chunk into a vector. That is a large number of small, similar matrix operations, exactly the kind of work a GPU does in parallel. On the CPU, the chunks are processed with far less parallelism, so the same work takes much longer. During the packaging build, I could watch the card working: utilization rose to around 64%, and power draw climbed from about 10 W at idle to roughly 120 W.

    One thing worth knowing

    Installing the GPU drivers was not enough on its own. The pipeline runs inside a container, and at first the container could not see the GPU, so it quietly fell back to the CPU. The fix was to configure GPU passthrough for the container runtime (generating a CDI configuration). Once that was in place, the same command used the GPU with no other changes. It is an easy step to miss, because nothing fails; the build just runs slowly.

    See it in action

    Want to watch the packaging assistant actually run? Here’s a full walkthrough of the pipeline, from staging the corpus to reviewing a spec file:

    https://gtfrans2re.fedorapeople.org/videos/packaging-guide-ramalama.mp4

    Takeaway

    For builds that happen often during development, cutting the editorial build from over an hour to under six minutes, and the packaging build from nineteen minutes to ninety seconds, changes how you work. You can rebuild the vector store as part of a normal iteration loop instead of planning around a long wait, and it makes larger corpora and larger models practical to experiment with, which is where the projects go next.

    What the GPU let us explore: larger models

    Fast builds were not the end of the story. Because the GPU made a full rebuild cheap, we could do something that would have been impractical on CPU: try a range of model sizes and see how each one actually behaves against the guidelines. We tested five models on both projects, keeping to the same model families for a fair comparison, plus one from a third family: Granite 3B and 8B, Gemma E4B and 12B, and a 14B Qwen model.

    A note on model versions: Model family alone does not tell the whole story; the generation matters too. The models here were granite-4.0-micro (3B) and granite-3.3 (8B), gemma-4 (E4B and 12B), and Qwen2.5 (14B). Worth keeping in mind: Qwen2.5 was released about two years before the others, and model quality has moved quickly in that time. So the 14B’s weaker showing is not simply a case of “bigger is worse”, it may also reflect its older generation. Newer small models often outperform older larger ones, which is part of why a mid-sized, current-generation model came out ahead here.

    The question was grounding: does a bigger model do a better job of answering from the retrieved guidelines, rather than falling back on what it happened to learn during training? The answer turned out to be more interesting than a simple yes.

    A mid-sized model grounded best; the largest did not.

    Retrieval carries the small models further than expected. For facts that live directly in the guidelines, like the exact SPDX license identifiers a package must use (MIT, GPL-2.0-only, Apache-2.0), every model got them right, including the smallest 3B. The retrieval step did the work, so size did not matter there.

    Where size and quality showed up. The differences appeared on harder questions. Asked whether a spec file still needs a %clean section (it does not, under current guidelines), the two Granite models gave the outdated answer they had seen often in training, while the Gemma and Qwen models correctly said it is no longer required. On the editorial side, the small Gemma E4B actually refused to answer from the guidelines, replying that it did not have access to them, even though they were right there in its retrieval corpus.

    Bigger is not automatically better. The clearest example: asked how to format the Release field in a spec file, the 14B Qwen model confidently invented a macro that does not exist, %{?asparagus:.ASPARAGUS}. It sounded authoritative and was entirely made up. The 12B Gemma model, by contrast, gave clean, decisive, grounded answers on both projects and comfortably fit the GPU with room to spare. It was the sweet spot: better grounded than the smaller models, and more reliable than the larger one.

    The takeaway on models: RAG grounding works, but the model still matters. It decides whether the retrieved guidelines actually get used, or get overridden by training habits or confabulation. For these two projects, a mid-sized model was the best balance of grounding quality and hardware fit, and none of this comparison would have been practical to run without the GPU.

    Written as part of my Outreachy internship with the Fedora Project. GPU hardware: an NVIDIA A10G (24 GB) instance running Fedora Linux 44. Packaging CPU baseline: local laptop [CPU: AMD EPYC 7R32, RAM: 32 GB].

    Call for Mentors for Outreachy (Dec 2026)

    Posted by Felipe Borges on 2026-09-01 12:59:08 UTC

    Once again, GNOME is considering participating in the Outreachy internship program. Outreachy provides internships to people subject to systemic bias and impacted by under-representation in the tech industry where they live.

    Outreachy internships are funded by the participating communities. While the GNOME Foundation has not yet finalized the budget for this cohort, having a strong list of proposed projects and available mentors helps the Board decide how many slots to fund.

    Project ideas will be selected based on available funding and their relevance to the overall goals of the GNOME project. Project selection will be handled by Matthias Clasen, Allan Day, and Sri Ramkrishna.

    If you are a GNOME developer/maintainer available for mentoring between December 2026 and March 2027, please submit a project proposal at gitlab.gnome.org/Teams/internship/project-ideas as soon as possible (by September 11).

    If you have any questions, you can contact the Internship Committee on Matrix or ask on Discourse.

    Don’t Forget: Unset Confidentiality on Private Issue Reports

    Posted by Michael Catanzaro on 2026-08-31 19:21:23 UTC

    It’s hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you’re done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you’re not planning to disclose the issue report within the next few months, it should probably already already be public.

    For GNOME, I disclose issues whenever a merge request has been created or a fix lands in the git repo, or 30 days after the issue was reported, whichever comes first. Your project might prefer to wait until the fix is released before disclosing, especially if you fear that a vulnerability might actually be exploited during the window between the fix and release. Whatever you choose, please don’t forget about it and leave the issue report confidential forever. That’s not fair to your project’s users. Even if not many people will take the time to look, users should at least have a chance to see reported issues.

    What do I want in a Linux distribution?

    Posted by Jonathan McDowell on 2026-08-31 17:20:15 UTC

    I’ve been a Debian user since 1999, and a Debian developer since 2000. Given recent events it’s worth thinking about why that that is, and why I haven’t switched to something else in the past quarter century.

    My first Linux distro was Slackware, off a CD in a book, some time in the mid 90s. After starting university I ran SUSE for a while, then moved to RedHat (both back before they had commercial variants significantly different to what was available freely). The main motivation for switching was package management; I was running a machine at home, and a machine at university. Keeping track of what was installed on each, and what versions, was getting annoying with Slackware. Most of the folk I knew were running RedHat, and I mostly played with SUSE because I’m contrary before realising it was different enough that I couldn’t easily make use of 3rd party RPMs.

    I came to Debian via friends in Cambridge, who spoke highly of it. The first Debian machine I installed was fourier, the initial host for Black Cat Networks, and I never looked back.

    (For additional context I should also point out I have contributed, in the distant past, to, and run, OpenWRT, OpenEmbedded, and FreeBSD.)

    I’d like to try and work out what is it I get from Debian that I’d need in anything else. Originally I tried to order the requirements in some sort of priority, but it’s sometimes hard to work out what I’d drop if I had to compromise somewhere, so it’s a somewhat loose ordering.

    Stable releases, with security support
    I run Linux in lots of places, from remote servers/VMs, to my house router, to my desktop/laptop. Some of those I don’t want to be updating regularly with new software releases, I need something I can be sure is going to keep working, but will get necessary security + critical updates. A rolling distro that provides security via the latest upstream release doesn’t provide that guarantee. Equally there need to be regular stable releases, or things become too stale. (The one time I considered moving away from Debian was during the 3 year Sarge / 3.1 release cycle. I think if things hadn’t improved I’d have jumped ship to Ubuntu at the time.)
    A good selection of packages
    One of the reasons I moved from RedHat to Debian was the wide range of packages available as part of the standard OS. Pulling it all into the distro helps with quality control, compared to random 3rd party packages. A centralised bug system and repository is a win too. Perhaps packages at all is something I should list, but I take it as a given if you’re running a distro. I need to know what I have installed on my machine, what version that software is, what files it owns, and what it depends on.
    Free Software
    This is important to me. I’ll make pragmatic compromises about software I run on my systems if it makes sense, but I want to start from a place that does not require anything non-free. I’ve run a company on Debian, and I’ve worked on numerous products that ran it under the hood. The DFSG give me confidence I can do that.
    Smooth upgrades
    Debian’s ability to upgrade a system smoothly is one of the reasons I first moved to it. The first upgrade I did was remotely on a machine sitting on a 2Mb/s leased line. I was nervous doing the reboot at the end, but it came back fine. At the time the equivalent procedure with RedHat involved rebooting into the OS installer to do the upgrade.
    I know things have moved on since then, and really it should all be scripted, and machines should be cattle not pets, but for personal use I run a small enough number of machines that having the upgrade path between releases is a must have.
    Community
    The original pull of the Debian community was the knowledge I could get involved, and upload packages that were missing that I was using. That’s how I first got involved, uploading things Black Cat used, which made life easier for us in the long run. I don’t have time to maintain all the software I use myself, and I don’t want to be beholden to a commercial entity to do so for me, so a distribution that allows me to help out where I can as part of the community seems to me to be the right way to do things.
    Architecture support
    Perhaps less important, especially when I started using Debian, but these days I have amd64, arm64, armhf, and riscv machines. Everything except for the risvc box is doing something useful, and would need replaced if I couldn’t keep running it, and I expect RISC-V to transition into that state in the next few years as the hardware improves.
    Binary packages
    I ran a FreeBSD desktop for some time. It might have been the way I was holding it, but binary package installs were generally not something reliable, especially after the initial install, and I ended up building things from ports from source quite often. That worked incredibly well (I used to think people who raved about Gentoo really should just go do it properly and use FreeBSD), but I don’t want to spend time compiling things, especially on some of my machines (my router should not need a compiler, for example).

    Ultimately I don’t want to have to actively think about the Linux distribution I use. Debian has mostly given me that; I know it will generally be suitable for most environments I want to use it in (embedded situations where OpenWRT or OpenEmbedded are better choices being the exception, but that’s less frequent these days), and I can rely on getting timely security updates (thanks to all those who work on that within Debian!). I’m not sure there’s currently an alternative that would suit my needs? I’d love to hear if there’s something I should look at, even if I’m not necessary making a move just yet!

    Modernizing Fingerprint Management in GNOME Settings

    Posted by Felipe Borges on 2026-08-31 09:57:31 UTC

    For a while now, the fingerprint management UI in GNOME Settings (gnome-control-center) has felt outdated. While it worked, the layout and enrollment flow hadn’t kept up with the rest of GNOME’s modern interface updates.

    I am happy that during the GNOME 51 development cycle we managed to address that. Allan Day, Marco Trevisan, and myself worked on modernizing the interface. There’s still more work to do in the UI and in fprintd, but what we will ship in 51 is already a great step forward.

    Historically, the fingerprint dialog in User Settings was stuck on a GTK3-style design. Even after being ported to GTK4, conceptually it remained unchanged. Beyond looking out of place alongside Libadwaita-based settings panels, it suffered from responsiveness and accessibility issues that made it difficult for some users to enroll their prints.

    Screenshot of the new fingerprint management dialog in GNOME Settings
    Screenshot of the Fingerprint Authentication dialog

    The new fingerprint management dialog uses a standard boxed list displaying your enrolled fingers. From here, each enrolled finger can be removed individually.

    Clicking the “Add Fingerprint” button starts the finger enrollment process. First, you choose one of the unused finger options to enroll. From there, an assistant guides you through the scanning process. As you place your finger on the reader, the UI detects the touch and provides feedback on whether it was read correctly. You continue touching the reader until enough samples have been collected (the exact number depends on your reader’s driver). Once the progress bar fills, your finger is ready for authentication.

    Screenshot of a fingerprint being enrolled
    Screenshot of a fingerprint enrollment

    This is only one of the improvements that GNOME 51 is bringing. As with everything in GNOME, we will continue gathering user feedback and making iterations over time. There are already more fingerprint features in the pipeline, such as renaming enrolled fingers and verifying individual prints. Stay tuned!

    From August 24 to August 30

    Posted by Aurélien Bompard on 2026-08-31 08:33:00 UTC

    Across the various Fedora groups, the primary focus is the progression of the Fedora 45 release, with teams actively navigating the Beta freeze, conducting Blocker Review meetings, and completing QA and feature testing. Concurrently, significant infrastructure and tooling transitions are a shared priority; multiple groups are gathering workflow requirements for an upcoming Red Hat Bugzilla replacement, finalizing the migration from the newly retired Pagure.io to the Forgejo-based Fedora Forge, and integrating modern build systems like Konflux. Package maintenance and policy refinement also dominate daily operations, characterized by widespread updates to packaging guidelines across ecosystems (including Python, NodeJS, and cryptography), coordinated responses to security advisories (notably RUSTSEC vulnerabilities), and the mass-orphaning of inactive packages. Finally, strategic structural alignments represent a common operational thread, highlighted by the EPEL 10 mass branching and repository restructuring, as well as ongoing proposals to unify CoreOS with Bootc technologies.

    Announcements

    Critical deadlines have arrived for Fedora 45 contributors: the "Complete" deadline for F45 Changes requires all tracker bugs to be updated to ON_QA, coinciding with the Fedora 45 Beta freeze, Bodhi updates-testing enablement, and Software String freeze. Additionally, contributors must meet a September 1 deadline to submit bug tracker workflows to help identify a replacement for Red Hat Bugzilla as its maintenance winds down. On the community engagement front, the Fedora Badges application has been completely revamped with a modern, fast single-page interface, and content creators can now utilize editorial-guide-ramalama, a new RAG-based local AI assistant designed to verify article drafts against Fedora's editorial guidelines before submission.

    For the broader Linux community, several new technical guides have been published. Users can learn how to monitor drive health using Performance Co-Pilot (PCP) to catch subtle warnings of SSD or NVMe failure before data loss occurs. Those interested in local AI development can explore a guide on running Ollama locally with Podman to keep host systems clean and isolated, as well as a tutorial on how to safely sandbox AI coding agents using microVMs to prevent unauthorized automated access to production clusters or local work environments.

    Council

    The Fedora Council met to discuss the Fedora Forge Usage Policy and the proposed Innovation Lifecycle (Sandbox). The Council achieved consensus on the Forge Usage Policy, clarifying CI resource access for spins and remixes, and establishing a notification-only process for new remixes.

    Additionally, extensive debate took place regarding the level of early technical oversight required for the Innovation Sandbox, prompting the scheduling of a dedicated follow-up workshop.

    Decisions

    • The Fedora Forge Usage Policy will be updated for version 5 to explicitly state that spins and remixes are permitted CI resources. Requests for infrastructure resources for new remixes must CC a Council member for visibility, but formal Council approval is not required.
    • The Fedora Forge Usage Policy will remain open for one final week of feedback; if there are no further edits, it will proceed to an official Council vote.
    • The Council will hold a dedicated, public video call on Thursday, September 3, 2026, at 14:00 UTC+1 to workshop the Innovation Lifecycle Proposal to resolve ongoing debates about FESCo's involvement.

    See the detailed report for the Council team.

    Learn more about the Council team.

    FESCo

    During this week, FESCo held a meeting to discuss ongoing system transitions and policy updates, including the rollout of 2FA for provenpackagers, the handling of binary executable content in node_modules, and the timeline for gathering requirements for Fedora's upcoming Bugzilla replacement. The committee also finalized a major policy change regarding where Fedora Changes discussions will take place moving forward.

    In ticketing and forum activity, FESCo formally approved the use of AWS-LC for cryptography in Rust packages, bringing clarity to package maintainers struggling with the ring crate. Additionally, several non-responsive maintainer tickets were processed, resulting in package handovers and the mass-orphaning of inactive maintainers' packages, while a draft for Crystal packaging guidelines was submitted for community review.

    Decisions

    • Approved the F46 Change: Changes Discussion Only On Devel List, making it effective immediately. Discussions regarding Changes will now happen solely on the devel mailing list and will no longer be simultaneously discussed on Discourse.
    • Approved the inclusion and use of the aws-lc-sys and aws-lc-rs crates for cryptography in Fedora to replace the ring crate wherever possible, via Ticket #3679. This exception will be documented in the Packaging Guidelines.
    • Agreed to close the re-review of the F45 Change: RelocateRpmRepoConfigsToUsr, as major known issues affecting rpm-ostree, anaconda, and container composes have been resolved or mitigated.
    • Approved extending the deadline for gathering Bugzilla replacement requirements to September 4th to accommodate additional feedback from teams, as discussed in Ticket #3664.
    • Approved mass-orphaning of packages for non-responsive maintainers cleber (Ticket #3659) and gui1ty (slated for Sep 4 per Ticket #3678), while approving the handover of packages for benzea (Ticket #3672) and prarit (Ticket #3665).

    See the detailed report for the FESCo team.

    Learn more about the FESCo team.

    Packaging Committee

    This week, the Packaging Committee's activity focused on updating and clarifying packaging guidelines across various ecosystems to prevent contributor confusion and accommodate structural changes. A new ticket was opened to document an exception for limited aws-lc use within the system-wide CryptoPolicies.

    In the NodeJS ecosystem, new guidelines for using different nodejs versions have been finalized to detail how packaged streams should be utilized after the upcoming metapackage change. Additionally, the Python packaging guidelines are being revised to explicitly state that using %pyproject_buildrequires automatically satisfies the mandatory python3-devel build requirement, making redundant declarations unnecessary.

    Decisions

    See the detailed report for the Packaging Committee team.

    Learn more about the Packaging Committee team.

    Mindshare

    This week, Mindshare focused heavily on in-person event representation, travel funding, and committee governance. The core theme connecting the active tickets is establishing a strong physical Fedora presence at regional open source conferences and ensuring proper internal representation on the Fedora Council.

    The committee received two new travel support requests: one to record on-site Fedora Podcast episodes and present a talk at Texas Linux Fest 2026, and another to host a Fedora sub-booth alongside Red Hat India at IndiaFOSS 2026. Meanwhile, action was requested on the open Fedora Council Representative Nomination ticket to clarify earlier voting miscommunications and finally select the Mindshare liaison for the Fedora Linux 44 cycle.

    See the detailed report for the Mindshare team.

    Learn more about the Mindshare team.

    Workstation / GNOME

    The Workstation / GNOME group reviewed progress on several upstream and integration initiatives this week. Key topics included resolving recent bug-reporting friction with the Showtime project, acknowledging the failure of the current Flatpak strategy regarding Flathub integration, and discussions around Bazaar as a potential GNOME Software replacement.

    Additionally, community members provided updates on restoring Google Drive integration for GNOME, noting that testing is temporarily delayed while developers adapt to recent upstream changes. Preparations are also underway for the Fedora 45 Blocker Review meetings, with a call for asynchronous QA voting.

    Decisions

    • The working group confirmed that the effort to filter the Fedora Flatpak repository remains formally blocked by the pending GNOME Software redesign, per the meeting summary.
    • It was decided that the integration of the Bazaar app store requires a new contributor to take over the review process, as the original contributor is no longer responding.
    • Neal Gompa will review the ticket regarding the replacement of xvfb-run with wl-headless-run for GNOME packages and close it if no further action is required.
    • Allan Day will chair the next working group meeting, with Matthias Clasen serving as secretary.

    See the detailed report for the Workstation / GNOME team.

    Learn more about the Workstation / GNOME team.

    KDE

    KDE Gear 26.08.0 is now available for testing on Fedora 44 and newer. While a minor bug regarding missing icons in Dolphin's "Details" mode was identified, an upstream patch has already been secured for the forthcoming 26.08.1 release. Additionally, the Fedora QA team has scheduled an upcoming Fedora 45 Blocker Review meeting to address proposed blockers and freeze exceptions for the upcoming Beta and Final releases.

    See the detailed report for the KDE team.

    Learn more about the KDE team.

    Server

    The Server group met on August 26 to discuss Fedora 45 release testing and Project Ansible support. For F45 testing, the team is actively verifying features and installations, though hardware limitations for ARM and RAID setups have caused minor bottlenecks, prompting targeted volunteer efforts. A minor, non-blocking bug regarding Kickstart was identified during the testing phase.

    On the Ansible support front, the working group verified that the Wildfly role functions properly when Java 25 is configured. The team agreed that the Wildfly and post-install modules are near completion and will serve as pilot projects, with beta user testing slated to begin in two to three weeks. In addition, the Fedora QA team announced Blocker Review meetings for Fedora 45.

    Decisions

    • The Server working group will use the post-install and Wildfly Ansible modules as pilot projects, with beta user testing slated to begin in two to three weeks. (Meeting Log)

    See the detailed report for the Server team.

    Learn more about the Server team.

    Infrastructure

    The Fedora Infrastructure team has officially entered the Fedora 45 Beta infrastructure freeze, which will remain in place until mid-September to ensure stability for the upcoming release. In major ecosystem news, Pagure.io has been officially retired as an active platform and transitioned into a read-only static archive for historical purposes. Concurrently, the team is heavily preparing the new Forgejo instance (Fedora Forge) to take over production Dist Git duties, including provisioning storage, refining access controls, and finalizing project board support.

    Ongoing maintenance focused heavily on RHEL 10 migrations, with Zabbix servers successfully upgraded and Mailman servers queued next. The team also addressed a severe spam attack on the fedora-devel mailing list by banning the offending user, cleaning the archives, and implementing new moderation headers. Finally, various monitoring improvements were discussed, including stabilizing database OOM kills and tuning OpenShift app load balancer metrics.

    Decisions

    • The Fedora 45 Beta infrastructure freeze is in effect from August 25 until approximately September 15. Frozen production hosts cannot be modified without sign-off from sysadmin-main or rel-eng.
    • Pagure.io has been officially turned off as an active service and converted into a read-only historical archive.
    • A freeze break was approved for the new-updates-sync script to ensure RHEL users receive the correct EPEL 10 epel-release-latest symlink and avoid dependency errors.
    • A generic internal guest account was enabled for Zabbix to allow the Copr team to easily forward status metrics to Grafana without complex SAML authentication.
    • A new FAS group, sysadmin-public-inbox, was created to manage the public-inbox OpenShift deployment.

    See the detailed report for the Infrastructure team.

    Learn more about the Infrastructure team.

    Release Engineering

    The Release Engineering team enacted the Fedora 45 Beta Freeze on August 25 and began tracking Beta release tasks. A significant amount of the week was spent navigating infrastructure hiccups, including a Koji hub DDoS that stalled builds and dropped mounts, F44 Flatpak compose timeouts, and Rawhide ostree compose failures. In a F45 mass branching retrospective, the team noted successes in automation but highlighted the need to strictly prevent massive, disruptive updates right before branching.

    Meanwhile, several infrastructure requests were addressed, including the setup of a temporary empty repository for F46 OpenH264 to bypass 404 errors until binaries are published. The new fedpkg request-unretirement tool saw active testing by maintainers, revealing some quirks regarding Rawhide branch unblocking.

    Decisions

    See the detailed report for the Release Engineering team.

    Learn more about the Release Engineering team.

    Quality

    The Quality group was highly active this week as Fedora 45 reached its Beta freeze and Bodhi enablement point. The GNOME 51 test day concluded successfully with 30 participants submitting 135 test results. Early manual validation testing for Fedora 45 was also completed, uncovering multiple bugs across different architectures.

    Additionally, the team evaluated proposed blockers in their Beta blocker review meeting, deciding on key anaconda-webui and kmscon bugs. The group is also urgently compiling requirements for the upcoming Red Hat Bugzilla replacement system, which are due by September 1st.

    Decisions

    • Accepted Fedora 45 Beta Blockers for an anaconda-webui review screen crash (Bug 2519654) and a kmscon bug that breaks console initial-setup on ARM minimal (Bug 2484542).
    • Accepted Fedora 45 Beta Freeze Exceptions to pull LLVM 23 into Fedora 45 (Bug 2506941), to address missing obsolete packages for Python 3.14 (Bug 2492124), and to fix an anaconda-webui dependency issue preventing soas livespin creation (Bug 2517903).
    • Declared User switching restart failure as an Accepted Final Blocker, but rejected it as a Beta Blocker (Bug 2501857).

    See the detailed report for the Quality team.

    Learn more about the Quality team.

    Design

    This week, the Design team saw continued progress on graphic design requests and repository maintenance, though some coordination activities were paused due to Madeline being on PTO. New artwork was submitted for the EPEL Steering Committee badge, and the migration of historical repositories to the new Forge organization was reviewed.

    See the detailed report for the Design team.

    Learn more about the Design team.

    Docs

    This week, the Fedora Docs team held a meeting to discuss ongoing projects, including the frontpage redesign and proposed updates to the Release Notes process. A major milestone was reached with the merging of a long-standing pull request that restructures the team documentation, successfully splitting the Docs Contributors Guide into its own module for better visibility.

    Additionally, the team evaluated ticket activity, opening a new discussion on archiving or removing End-of-Life (EOL) distribution pages and processing a membership request. The team is actively seeking community input on the frontpage redesign and continues to request help with manual wiki migrations.

    Decisions

    • The Release Notes process will be updated to include clear documentation questions in the Fedora Change template, which will directly affect all Fedora Change owners. (Meeting Log)
    • The Docs Contributors Guide has been moved into a separate module to allow placement on the Docs landing page, finalizing the team documentation restructuring. (Issue #55)
    • Docs group membership requests will be denied unless the applicant has already made demonstrable contributions to repositories within the Docs organization on Forge. (Issue #60)

    See the detailed report for the Docs team.

    Learn more about the Docs team.

    Internationalization

    The Internationalization group focused on optimizing translation resources and streamlining issue tracking. Key discussions included centralizing the issue tracker for localization-docs repositories by redirecting them via API to the main localization tracker, and removing archived documentation (sysadmin and install guides) from Weblate to save resources.

    Additionally, the team fielded requests regarding unsupported Fedora releases and an upstream KDE translation error. Both were closed and redirected to the appropriate channels (Fedora Docs and the upstream KDE translation team, respectively), clarifying the scope of the Fedora localization team's responsibilities.

    Decisions

    • Archived and unpublished documentation (Sysadmin Guide and Install Guide) will be removed from Weblate to free up resources, while keeping their underlying Git repositories.
    • Unsupported (EOL) Fedora releases will remain in Weblate as long as they are still published on Fedora Docs; requests to hide them must be directed to the Fedora Docs team.
    • Translation issues for upstream projects (such as KDE Plasma Vault) are out of scope for Fedora Localization and must be reported directly to upstream translation teams.

    See the detailed report for the Internationalization team.

    Learn more about the Internationalization team.

    EPEL

    This week, the EPEL group successfully completed the EPEL 10.3 mass branching, officially shifting standard development on the epel10 branch to target the upcoming EPEL 10.4 release. Packagers wanting to build specifically for EPEL 10.3 must now request and use a dedicated epel10.3 branch. The transition went smoothly, overcoming some infrastructure adjustments required for the new "10s" repository naming scheme.

    Simultaneously, the team deployed the first phase of the EPEL 10 "de-z-ification" initiative. CentOS 10 systems with the latest release package will now use the new epel-10s metalink pointing to 10.4, while RHEL changes will follow in the fall with the release of RHEL 10.3. The team also addressed a minor but impactful bug regarding symlink churn for the EPEL 10 release RPM, temporarily fixing it to prevent repository dependency errors for users.

    Decisions

    • Builds submitted to the default epel10 branch now target EPEL 10.4 following the completion of the EPEL 10.3 mass branching. Packagers who need to build against EPEL 10.3 specifically must request and use the epel10.3 branch.
    • The first phase of the EPEL 10 "de-z-ification" proposal was put into production. CentOS 10 systems now utilize the epel-10s metalinks and paths, which redirect to the epel-10.4 repository, to prevent package dependency issues on private mirrors. Details were announced on the discussion forum.
    • The MirrorManager mapping logic for EPEL 10 was adjusted to use explicit minor versions (e.g., epel-10.4) with redirects for prior minor versions, rather than keeping the existing mapping and setting up redirects for future ones. (Discussion Post)

    See the detailed report for the EPEL team.

    Learn more about the EPEL team.

    CentOS Hyperscale

    During the August 26, 2026 meeting (log), the CentOS Hyperscale SIG announced that the wprof tool has graduated from incubation and is now available in Fedora and EPEL 10. The SIG has rebased to 7.1 kernels and plans to transition to 7.2 shortly after Fedora does. In broader ecosystem news, AlmaLinux is actively considering building the Hyperscale kernel for its users, which sparked discussions on kernel signing limitations and potential expansion of Hyperscale packages into AlmaLinux's extra repositories.

    The group also discussed the progression of transactional Hyperscale updates, noting that core elements have been ported to dnf5. Work is actively proceeding on packaging these components, tracked via Bugzilla issues 2521657, 2521661, and 2521666. Additionally, a KDE proposal to improve enterprise technologies was highlighted for its strong alignment with Hyperscale's system snapshot capabilities.

    Decisions

    • The SIG decided to retain the EPEL 9 builds of wprof in the experimental hsx repository, despite its graduation to standard repositories for Fedora and EPEL 10.
    • Davide Cavalca and Neal Gompa will finalize and submit the delayed Hyperscale quarterly report this week.

    Learn more about the CentOS Hyperscale team.

    ELN

    During the August 25, 2026 meeting, the ELN SIG focused on infrastructure, sync processes, and tooling improvements. The group discussed options for building ELN and CentOS toolbox and container images, specifically weighing whether to migrate from Kiwi to image-builder for CentOS parity or to wait for future Konflux adoption; the decision was deferred for further investigation. The team also debated how to optimize the ELN Build Sync (EBS) timeout duration to prevent buildroot breakage during high-load events like mass rebuilds, with discussions moving to the tracker.

    Most significantly for the broader Fedora and Linux packaging ecosystem, the SIG reached a consensus to stop using the Rawhide GPG key for ELN. Instead, they will provision a dedicated ELN key starting with the F46/EL11 branching. This key will be rotated approximately every three years to align with RHEL branching, which should resolve the recurring signing-related disruptions that typically happen during the Fedora branching process.

    Decisions

    • The SIG agreed to provision a new, dedicated GPG key for ELN starting with the F46/EL11 branching, rather than continuing to use the shared Rawhide key. This key will be rotated roughly every 3 years (aligned with RHEL branchings) to avoid widespread signing-related breakages during Fedora branching. (Meeting log)

    Learn more about the ELN team.

    Atomic

    The Fedora Atomic group successfully added base and compose images for Fedora 45 in Konflux, while actively working to resolve build failures for IoT images alongside the IoT team. Ticket discussions highlighted a strong theme around improving the bootc image derivation process, focusing on trademark compliance and filesystem structure.

    Administratively, steps were taken to grant write access to new maintainers for the base-images repository on both GitLab and the Fedora Forge. Users also reported a critical bug causing emergency mode on non-BTRFS filesystems (ext4/XFS) following recent system updates, which is currently under investigation.

    Decisions

    • Sean Thrailkill and Hristo Marinov were formally approved for maintainer access to the base-images repository and the Fedora Forge.
    • A new Fedora Account System (FAS) group will be created for maintainers to safely isolate bot permissions on the Forge.
    • The IoT team will fix their Konflux image builds now that they are aware of the failures, and coordinate future strategy for CoreOS, bootc, and IoT images.
    • Ticket #125 will strictly track logos, release, and release notes packages for derived builds, with a separate ticket (#126) opened to track the /usr/local and /opt symlink issues.

    See the detailed report for the Atomic team.

    Learn more about the Atomic team.

    CoreOS

    During the week of August 24-30, 2026, the CoreOS group held one meeting to review pending action items, coordinate around the Fedora 45 (F45) release schedule, and discuss a major proposal to unify CoreOS and Image Mode/Bootc. Key discussions revolved around navigating the F45 beta freeze to implement zram/oomd enablement, and scheduling the F45 Test Day for September 21st.

    The team had a highly positive initial reaction to the Bootc unification proposal, viewing it as a natural progression that could reduce duplication of effort across Fedora variants. This initiative will be proposed to the Bootc community next week to evaluate feasibility and alignment.

    Decisions

    • Tentatively scheduled the Fedora CoreOS 45 Test Day for 2026-09-21 (tracked in CoreOS #934).
    • Agreed to prioritize completing the zram/oomd implementation for F45 and address any beta freeze exceptions afterward if necessary.

    See the detailed report for the CoreOS team.

    Learn more about the CoreOS team.

    ARM

    This week, the ARM group primarily discussed hardware compatibility and upcoming release blockers. A user reported a kernel error when attempting to boot an older Fedora 43 installation on a Raspberry Pi 5 Model B Rev 1.1. The issue was bypassed by upgrading to a Fedora 44 image, prompting maintainers to close the inquiry since Fedora 43 is no longer a focus.

    Additionally, QA announced the upcoming Fedora 45 Blocker Review Meeting scheduled for August 31, 2026. Community members were invited to participate in the triage of proposed blockers and freeze exceptions for the Beta and Final releases.

    Decisions

    See the detailed report for the ARM team.

    Learn more about the ARM team.

    Hummingbird

    This week, an update was shared in the Hummingbird Community Meeting - 20 August 2026 thread regarding a new project. Jorge Castro announced that a version of Bluefin built on Hummingbird technology is essentially finished and will serve as a full peer to Dakotaraptor. He emphasized his complete commitment and support for this variant, noting that initial code pushes to its new repository are expected shortly.

    Learn more about the Hummingbird team.

    AI & ML

    The AI & ML group met to discuss ongoing packaging efforts and long-term goals (meeting log). Work on PyTorch 2.13 has temporarily stalled in Rawhide and Fedora 45 due to a libstdc++ update that conflicts with ROCm, causing build breaks. Meanwhile, ROCm 10.0 (previously referred to as ROCm 8) was released on August 26. This major upgrade marks a shift in AMD's release pace and support model. The group is currently evaluating potential ABI breakage, though efforts are slightly hampered by libabigail crashing on debuginfo packages.

    The group also explored the feasibility of shipping "open weights" AI models (like Nvidia's Nemotron 3 or AMD's open models) directly in Fedora. The consensus is that training or rebuilding these models from scratch within Fedora's build system (Koji) is currently unrealistic due to extreme hardware requirements (e.g., 64x MI300 GPUs) and timeouts. Doing so would require dedicated infrastructure proposals and deep-pocketed sponsors to provide heavy cloud compute resources.

    Decisions

    • ROCm 10.0 packages will be staged and maintained in the ROCm packagers preview COPR until basic testing is completed and the scope of ABI changes is fully quantified.

    Learn more about the AI & ML team.

    Security

    This week, the Security SIG's primary focus was discussing a draft proposal for a new Fedora Privacy SIG, which originated from earlier conversations about maintaining the ff-disable-ai-ml package. The group debated the appropriate scope for such a SIG, noting that while security and privacy are closely related, a dedicated Privacy SIG might inadvertently attract ideological or political debates rather than technical contributions.

    To address these concerns and ensure good optics—particularly to avoid appearing antagonistic toward the AI/ML SIG—the group agreed to postpone any formal launch. Instead, members will take extra time to review the RFC and intend to focus initially on concrete, ad-hoc technical work, such as packaging clear privacy config toggles for users.

    Decisions

    • Deferred the formal creation and announcement of the proposed Privacy SIG to allow members more time to review the draft and refine its scope.
    • Agreed to focus on tangible, ad-hoc technical implementations (such as packaging user privacy toggles) to establish a technical foundation before officially spinning off a new SIG.

    See the detailed report for the Security team.

    Learn more about the Security team.

    Go

    During the Go SIG meeting, it was announced that Go 1.27.0 is now available in Rawhide. Maintainers will soon move this update into Fedora 45 and trigger a mass prebuild on COPR. The SIG is also preparing to retire Go 1.25 in Fedora 43 in favor of Go 1.26, aligning with upstream Kubernetes requirements which have dropped support for 1.25 across all supported releases.

    Additionally, the team discussed a new method for handling security vulnerability reports. A community member modified an upstream CRI-O script to generate govulncheck output in openvex format. This script makes it much faster to verify if a package is actually affected by specific CVEs without having to run manual checks for each one. The script will be shared publicly on platforms like GitHub or Forgejo to help maintainers triage Bugzilla tickets more efficiently.

    Decisions

    • Move Go 1.27.0 into Fedora 45 and perform a mass prebuild on COPR.
    • Open a ticket to retire Go 1.25 in Fedora 43 and transition to Go 1.26 to support recent Kubernetes releases.

    Learn more about the Go team.

    Perl

    This week's activity on the Perl mailing list consisted entirely of package maintenance pull request notifications from Michal Josef Špaček. Key updates centered around the perl-DBD-ODBC package, which was re-submitted for Fedora review, updated with a new EPEL10 package, and received miscellaneous updates. Additionally, the perl-Archive-Extract package received version 0.90 version bumps across multiple branches.

    Decisions

    Learn more about the Perl team.

    Python

    This week, the Python group discussed the behavior of %pyproject_patch_dependency when packaging multiple Python distribution packages in a single specfile. They agreed that its current behavior—filtering dependencies from all distributions—is sensible for most use cases but needs to be properly documented. An option to filter by a specific distribution name might be considered in the future.

    In addition, flit-core has been updated to version 4. A deprecated compatibility package, python3-flit-core3, was introduced for packages that still require older versions. However, maintainers are expected to eventually migrate their packages to flit-core 4+.

    Decisions

    Learn more about the Python team.

    Rust

    This week, the Rust group focused heavily on addressing various RUSTSEC security advisories and dealing with unmaintained crates across the ecosystem. Significant efforts were directed toward updating critical dependencies, notably the lru and git2 crates, to mitigate vulnerabilities, alongside planning migrations away from archived crates with unfixed soundness issues like smartstring, bitmaps, sized-chunks, and im-rc.

    A major theme of the week was coordinating package updates and rebuilds gracefully. Because of the large number of dependent packages in the Fedora ecosystem, temporary compatibility packages are being introduced (such as for git2), and the group finalized a strategy for handling security rebuilds for affected packages they do not directly co-maintain, prioritizing cross-team communication over unilateral action.

    Decisions

    • Rather than invoking provenpackager privileges to force rebuilds of applications affected by the cxx RUSTSEC advisory, the group will file targeted bugs against the applications, linking the advisory and advising maintainers to simply rebuild their packages (Issue #36).
    • A temporary rust-git2_0.20 compatibility package will be added to the repositories to prevent breaking a large number of dependent packages while they are being ported to git2 v0.21.0 (Issue #30).
    • The group will wait until lru v0.18 is available in the repositories before attempting to patch the bounds for dependent packages like pydantic (Issue #39).

    See the detailed report for the Rust team.

    Learn more about the Rust team.

    Other Discussions

    • Michael Scherer initiated a discussion on Dynamic users with sysusers and bootc/image mode, noting that sysusers.d in image mode can cause UID mismatches on upgrades, and proposed amending packaging guidelines to pair it with a tmpfiles.d fragment to properly chown files in /var.
    • Mattia Verga posted the latest report on Inactive packagers for the F45 release cycle, prompting a request from Miroslav Suchý to include plain text lists of usernames directly in the email rather than relying solely on the ticket tracker links.
    • Norbert Manthey proposed to Extend default compiler settings to harden applications by adding flags like -fno-strict-overflow and -ftrivial-auto-var-init=zero. Daniel P. Berrangé noted that while the latter eliminates vulnerabilities, it can cause non-trivial performance degradation (e.g., 9% in virtio-blk) that maintainers must address.
    • SY Wang raised an issue regarding No response from the main admin on a libxsmm pull request open for two months. Other users noted similar issues and advised following the formal nonresponsive maintainer policy via Bugzilla.
    • Tobias Girstmair asked for advice on Questions on packaging vim-classic so it can coexist with standard vim. Maxwell G and Simon de Vlieger suggested starting with renamed or suffixed binaries rather than using the alternatives system.
    • Aoife Moloney announced a DEADLINE: Please Submit your Bug Tracker Workflows by Sept 1, 2026 to collect workflow requirements for an eventual Red Hat Bugzilla replacement, though the tight deadline was questioned by Quality team members.
    • Chihurumnaya Ibiam reported a FTBFS/FTI Page Not Found issue in an auto-generated comment link, which Miro Hrončok promptly fixed while reminding contributors to report tooling issues directly to the releng ticket tracker.
    • Henryk Paluch noted that the Package Sponsorship page points to decommissioned pagure.io, and was directed to the new Fedora Forge tracker and an open pull request designed to fix the documentation.
    • Kevin Fenzi confirmed the spam wave is over, stating that the spammers were banned, the archives cleaned, and new header rules were added to block similar messages.
    • Orion Poplawski posted Help wanted with ansible mysql/mariadb collections, seeking a new maintainer for ansible.mysql as they are migrating to ansible.mariadb; Andreas Haupt volunteered to take it over.
    • Other discussions included an announcement of the upcoming F45 Blocker Review Meeting, and two PRs from Bojan Smojver to address a Failed F44 Flatpak compose holding back updates.

    Package updates

    Orphaning packages

    New contributor introductions

    • Charles Haithcock introduced himself as a former RHEL kernel troubleshooter who is now working on Fedora kernel bugs and hopes to become more entrenched in the community.
    • Bri Mo introduced himself as an applied AI/ML engineer and OSINT enthusiast running Silverblue 44 and container-first workflows with Podman.

    Contribution opportunities

    Testing and Quality Assurance: Community members looking for highly accessible ways to contribute can help streamline the release process by voting on proposed blocker bugs and freeze exceptions using the blockerbugs app (requested by Workstation/GNOME, KDE, Server, Release Engineering, and ARM). Testers are also needed to evaluate Google Drive integration in GNOME, the KDE Gear 26.08.0 release, ROCm 10.0 packages, and transactional updates. More involved QA tasks include investigating Atomic Desktop boot failures on non-BTRFS systems, benchmarking tuned-ppd performance, and writing test cases for upcoming Anaconda test days or CoreOS testing events.

    Design, Documentation, and Community Governance: Non-developers can make significant impacts by shaping project identity, documentation, and policies. Designers are invited to create an avatar for the Matrix Moderation Bot or submit artwork for the upcoming Fedora 46 Wallpaper call. Documentation volunteers can guide the Docs frontpage redesign (Issue #6, Issue #52), assist with Wiki cleanup (Issue #43), and modernize the Request for Resources process. Contributors are also encouraged to review and provide feedback on the Fedora Forge Usage Policy, the Innovation Lifecycle Proposal, Draft Crystal Packaging Guidelines, the Privacy SIG RFC, and the CoreOS Unification proposal. Additionally, bilingual users can report translation errors directly to upstream translation teams.

    Programming and Scripting: Software developers have opportunities to write automation tools and patch ecosystems. Scripting tasks include using the Forgejo API to redirect localization issue trackers, building tools to adjust NodeJS shebangs, and creating a programmatic fix for EPEL 10 symlink churn. UI/UX developers can tackle low-hanging fruit by adding a power-off option to the GNOME initial setup screen, building system snapshot integrations aligned with KDE's enterprise goals, or developing user-facing privacy toggles. Rust developers are urgently needed for security auditing and migrating Fedora packages away from unmaintained crates like smartstring (Issue #38) and updating git2 dependents.

    Packaging, Infrastructure, and Sysadmin: Contributors with packaging and system administration skills are highly sought after to adopt orphaned packages resulting from unresponsive maintainers, including PackageKit-Qt5, ansible.mysql, and Python utilities (sponsorship is available for adopters of packages like python-aexpect). Python packagers can also assist by migrating spec files to flit-core v4+. Infrastructure volunteers can help prepare for RHEL 10 by building missing EPEL packages needed to migrate Mailman servers, fix Ansible inventory macros, and update the Koji theme footer URI. Furthermore, packaging contributors can help create generic Fedora remix assets to ease trademark compliance for derived bootc builds.

    misc fedora bits: last week of aug 2026

    Posted by Kevin Fenzi on 2026-08-29 17:53:19 UTC
    Scrye into the crystal ball

    Time for another saturday weekly recap in longer form.

    RHEL10 migrations

    Bunch more progress of various machines over the last week or two, and we are down to:

    Nice to finish this off soon.

    Authentication woes... over?

    I am hopefull that we have solved the last of our auth issues late this week. There's a lot of moving parts in our authentication stack: ipa servers on the backend, noggin on the frontend (accounts.fedoraproject.org), ipsilon for identity provider (id.fedoraproject.org). All of these have had various issues recently, but we have worked through them and I did some tuning of ipsilon on thursday that seems to have really helped.

    If you are still seeing any issue, please add exactly what you were trying to login to/do and time/date to our tracking ticket. ( https://forge.fedoraproject.org/infra/tickets/issues/13482 )

    Fedora 45 Beta infrastructure freeze

    We are in beta freeze now, so hopefully that will keep things a bit quieter and we can catch up on work in staging and docs and other like things.

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

    ⚙️ PHP version 8.4.25 and 8.5.10

    Posted by Remi Collet on 2026-08-28 04:51:00 UTC

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

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

    ℹ️ These versions are also available as Software Collections in the remi-safe repository.

    ℹ️ The packages are available for x86_64 and aarch64.

    ℹ️ There is no security fix this month, so no update for versions 8.2.33 and 8.3.33.

    ⚠️ PHP version 8.1 has reached its end of life and is no longer maintained by the PHP project.

    Version announcements:

    ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

    Replacement of default PHP by version 8.5 installation (simplest):

    On Enterprise Linux (dnf 4)

    dnf module switch-to php:remi-8.5/common

    On Fedora (dnf 5)

    dnf module reset php
dnf module enable php:remi-8.5
dnf update

    Parallel installation of version 8.5 as Software Collection

    yum install php85

    Replacement of default PHP by version 8.4 installation (simplest):

    On Enterprise Linux (dnf 4)

    dnf module switch-to php:remi-8.4/common

    On Fedora (dnf 5)

    dnf module reset php
dnf module enable php:remi-8.4
dnf update

    Parallel installation of version 8.4 as Software Collection

    yum install php84

    And soon in the official updates:

    ⚠️ To be noticed :

    • EL-10 RPMs are built using RHEL-10.2
    • EL-9 RPMs are built using RHEL-9.8
    • EL-8 RPMs are built using RHEL-8.10
    • intl extension now uses libicu74 (version 74.2)
    • mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
    • oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
    • A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

    ℹ️ Information:

    Base packages (php)

    Software Collections (php83 / php84 / php85)

    🛡️ PHP version 8.2.33, 8.3.33, 8.4.24, and 8.5.9

    Posted by Remi Collet on 2026-07-31 05:05:00 UTC

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

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

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

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

    ℹ️ These versions are also available as Software Collections in the remi-safe repository.

    ℹ️ The packages are available for x86_64 and aarch64.

    ⚠️ PHP version 8.1 has reached its end of life and is no longer maintained by the PHP project.

    🛡️ These Versions fix 3 security bugs (CVE-2026-7260, CVE-2026-17543, CVE-2026-17544), so the update is strongly recommended.

    Version announcements:

    ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

    Replacement of default PHP by version 8.5 installation (simplest):

    On Enterprise Linux (dnf 4)

    dnf module switch-to php:remi-8.5/common

    On Fedora (dnf 5)

    dnf module reset php
dnf module enable php:remi-8.5
dnf update

    Parallel installation of version 8.5 as Software Collection

    yum install php85

    Replacement of default PHP by version 8.4 installation (simplest):

    On Enterprise Linux (dnf 4)

    dnf module switch-to php:remi-8.4/common

    On Fedora (dnf 5)

    dnf module reset php
dnf module enable php:remi-8.4
dnf update

    Parallel installation of version 8.4 as Software Collection

    yum install php84

    And soon in the official updates:

    ⚠️ To be noticed :

    • EL-10 RPMs are built using RHEL-10.2
    • EL-9 RPMs are built using RHEL-9.8
    • EL-8 RPMs are built using RHEL-8.10
    • intl extension now uses libicu74 (version 74.2)
    • mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
    • oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
    • A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

    ℹ️ Information:

    Base packages (php)

    Software Collections (php83 / php84 / php85)

    Friday Links 26-27

    Posted by Christof Damian on 2026-08-27 22:00:00 UTC
    A black Sony Walkman music player lying on a wooden bench, screen showing a track playing, with a grey headphone cable plugged in

    I skipped a week again. Some good podcasts this week, have a listen to the ones about The Pragmatic Programmer and the one about performance. For some fun, play Snek and watch the relaxing visualisation of train movements.

    Quote of the Week
    You look at where you’re going and where you are and it never makes sense, but then you look back at where you’ve been and a pattern seems to emerge. And if you project forward from that pattern, then sometimes you can come up with something.
    Zen and the Art of Motorcycle Maintenance
    Robert M. Pirsig

    Leadership

    Headed for the Exit: the Great Engineering Leader Career Break - I can definitely relate. I would say that this doesn’t affect only leaders.

    Change in Timeline to “Some Changes to GNOME Security Tracking”

    Posted by Michael Catanzaro on 2026-08-27 14:56:33 UTC

    In Some Changes to GNOME Security Tracking, I reported:

    I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

    This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

    Syslog-ng end of August news, and about scaling back Java support

    Posted by Peter Czanik on 2026-08-27 11:02:53 UTC

    Most of August, I was on vacation, but now I’m back and I try catching up on the events of the past weeks, just like my colleagues do. Currently, we are fixing issues and reviewing contributions, but we also discussed scaling back our efforts on Java support.

    While most of the team was away on vacation, the number of syslog-ng contributions suddenly grew. We support both autotools and cmake, and while differences are narrowing, there are still some minor problems to fix. There are pull requests related to cmake, the syslog-ng disk buffer and more. Check https://github.com/syslog-ng/syslog-ng/pulls?q=is%3Apr+ for a full list of pull requests we are working on.

    We also received some new issues. One of them was related to a memory leak when syslog-ng is reloaded. While we fixed several problems, Java was not among them. In fact, we rather disabled packaging Java destination support.

    To explain this decision: Java support was introduced back when several destinations had no native C drivers and were only implemented in Java. However, Elasticsearch works fine using a wrapper around the http() destination. Kafka now also has a native C driver. And as for HDFS: well, it is dead, and its code will be removed from syslog-ng soon. A few months ago, I also wrote about disabling Java support in my packages. Now the same is happening with Debian / Ubuntu / RHEL packages available from https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-java-destination-disabled At the same time, we also decided not to work on a Java-related memory leak problem, unless we are notified that someone is actually using the Java destination with a self-developed driver. We were aware of such projects 3-4 years ago, but not anymore.

    But are there any benefits of not packaging Java, you might ask? Well, in the Debian / Ubuntu world, many users install the syslog-ng package, which is an umbrella package installing all syslog-ng sub-modules and their dependencies. But even without an umbrella package, I have seen similar solutions from RPM users. Removing the unused Java package from the mix reduces both RAM and HDD usage, which benefits everyone.

    syslog-ng logo

    Originally published at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-end-of-august-news-and-about-scaling-back-java-support

    Removing inactive maintainers

    Posted by Ben Cotton on 2026-08-26 12:00:00 UTC

    In open source projects, we tend to grant privileges far more often than we remove them. This is understandable, but risky. First, keeping inactive people on the maintainer list means someone may go to them with a question and be frustrated when they don’t get an answer. More importantly, it presents a security risk. Compromised accounts remain a common attack vector, and it’s much easier to escape notice if the account owner isn’t using the account. It behooves the project to keep the maintainer (or other privileged role) list tidy.

    There are a few reasons that trimming the maintainer list doesn’t happen. First, it’s boring, tedious work. Who wants to do that? Second, it’s complicated work. What does it mean to be “inactive”? Third, it can lead to hurt feelings. People who earn privileges absorb that role into their identity and they don’t want to let it go. This is a case where the perfect quickly becomes the enemy of the good (or okay-ish). Let’s look at each of the reasons in turn.

    Overcoming the objections

    Project and community management tasks often end up on the “avoid: no fun” pile. They only seem like no fun because they are. But “fun” and “important for the project” aren’t the same. Changing the air filter in my furnace isn’t fun, but it’s important for the health and safety of my family. Ideally, the inactive maintainer process is automated and runs regularly, but building that automation takes work. So if you go through the list and identify inactive maintainers once or twice a year, that’s better than nothing.

    “Inactive” can mean a lot of things. Does one activity in a six month period count? Does the activity have to be “sustained”? You can define it in the way that’s most convenient to you. The goal isn’t to be rigorous and precise, it’s just some spring cleaning. You can start by just asking yourself “have I seen So-and-so around lately?” If the answer is “yes”, then they’re active. Again, it would be nice if you could automate it. You don’t need to wait for that.

    The feelings objection is the hardest one. We’re all friends here and we don’t want to hurt our friends’ feelings. Unlike the other two, you can’t really half-ass this one, so you need a policy that treats people with kindness. Let’s move on to that.

    Creating an inactive maintainers policy

    Here are some features of a good inactive maintainers policy:

    • Define “inactive” unambiguously. “We will remove maintainers who have not been active in N months, where ‘active’ means having done X, Y, Z.” Six or twelve months is probably a good place to start. Be sure to include as many activities as you can reasonably determine. Think about what’s important to keep that status: commits, issues opened/closed/commented/reviewed, pull requests, mailing list posts, and so on.
    • Define “inactive” generously. For the most part, the bigger concern is “is this person still in control of their account?” not “is this person earning enough points to keep their privileges?” So if someone’s activity isn’t what you’d want for them to initially earn maintainer status, that’s probably okay.
    • Check for inactive maintainers at a set time. If you have calendar-based releases, check at a given point in the release cycle. Right after the release is a good starting point.
    • Automate what you can. The time spent really does pay off pretty quickly. Fedora is a large and complicated project, so evaluating activity requires checking half a dozen services. Mattia Verga wrote a script that handles the checks and creates issues in a repo to track the inactive packagers.
    • Don’t remove anyone without notice. This is a big part of the “don’t hurt your friends’ feelings” requirement. Give people a chance to respond. Some will respond by being more active. Some will respond by saying “yeah, I no longer have the time and/or interest, so go ahead and drop me.” Some won’t respond at all. If someone wants to remain, let them.
    • Conspicuously acknowledge the people you’re removing. Add people as a “maintainer emeritus”. Mention them in a blog post, release notes, or other vehicle for public praise.
    • Allow easy reinstatement. If someone lapses and later wants to return, let them. Don’t make them go through the whole process again. It’s much easier to let a role go if you know you can easily get it back later.
    • Leave some privileges for people on emeritus status. Keeping their name on a list of historical maintainers, letting them keep a project email address, giving them voting privileges on certain issues, and other privileges will help people who are inactive still feel valued in the project.

    It will take a few tries to get the policy just right. Don’t be afraid to try it.

    This post’s featured photo by Jan Canty on Unsplash.

    The post Removing inactive maintainers appeared first on Duck Alignment Academy.

    🎲 PHP version 8.4.25RC1 and 8.5.10RC1

    Posted by Remi Collet on 2026-08-14 03:53:00 UTC

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

    RPMs of PHP version 8.5.10RC1 are available

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

    RPMs of PHP version 8.4.25RC1 are available

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

    ℹ️ The packages are available for x86_64 and aarch64.

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

    ℹ️ Installation: follow the wizard instructions.

    ℹ️ Announcements:

    Parallel installation of version 8.5 as Software Collection:

    yum --enablerepo=remi-test install php85

    Parallel installation of version 8.4 as Software Collection:

    yum --enablerepo=remi-test install php84

    Update of system version 8.5:

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

    Update of system version 8.4:

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

    ℹ️ Notice:

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

    Software Collections (php84, php85)

    Base packages (php)

    Streaming Online Radio with Shortwave on GNOME

    Posted by Christiano Anderson on 2026-08-26 05:30:59 UTC

    As an expat living in Germany, online radio has become a good daily companion. I enjoy listening to news from my home country (and connect to my mother tongue), practice German language or just discovering music and stories from a random place around the globe.

    I found a GNOME app that is a genuine gem: Shortwave, which can be installed via Flathub.

    Shortwave is an online radio app for GNOME that has a great and clean design, cool features and a built-in search that makes finding radio stations around the world effortless. Just search, tune and listen, super easy.

    Hooking an old magicJack adapter to modern Asterisk

    Posted by Matthew Garrett on 2026-08-26 04:04:17 UTC

    I’m on a VPN setup with several friends that, obviously, includes a VoIP network. I also have an old magicJack adapter and a deep and abiding need to use hardware in ways I should not. There was obvious synergy here.

    Plugging in the magicJack gives a USB vendor id of 0x06e6, which belonged to a company called TigerJet who made a range of chips for hooking up phones to computers, either via USB or PCI. Some more digging suggested that it was a 580 part, and someone had conveniently uploaded some reference code and datasheets, so figuring out how to talk to the chip wasn’t terribly difficult. Once configured it simply sends HID events whenever a user hits a phone key or changes the hook state, and otherwise exposes a USB audio device that can be spoken to using the stock kernel driver. It also has the ability to generate dial tone and assert ring signal, giving a full traditional phone experience.

    So you’d think this would be a super easy project, but I’d made things harder for myself by deciding I wanted to tie directly into Asterisk rather than just smashing an existing SIP stack onto the device. Asterisk uses channels to talk to devices, and channels end up as compiled C code that Asterisk can load dynamically. I didn’t want to have to deal with the pain of compiling stuff and matching ABIs and everything so writing a new channel from scratch was unappealing. Fortunately, the websocket channel is available in recent versions of Asterisk and provides a convenient way to get audio in and out, but that still leaves the job of handling incoming and outgoing calls. That’s handled with the Asterisk Rest Interface, which can initiate a call or respond to an incoming one and bridge various channels together to produce a bidirectional audio stream. There’s a convenient async Python library that handles the low level protocol.

    Code for all this is here1, and works for my use case, but I should really abstract out the asterisk side and the magicJack side to make it easier to adapt to other devices. That’s a job for later, though. For now, you get this:

    1. This has also been an excuse for me to figure out how to make Tangled work, which I’ll write about at some later point. But self-hosted git repo with a convenient collaboration plane! ↩︎

    © 2016 Red Hat, Inc. and others. Please send any comments or corrections to the websites team.

    The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content.

    Your words are your own, duh. Nothing here represents Fedora™, Red Hat, Inc, or pretty much anything else. If you think it does then you are badly misled