fidzu : Fedora

01 Oct 2026 8:00pm GMT

24 Sep 2026 7:26pm GMT

There are a number of facts that we accept as generally true of software that, considered together, support the conclusion that applications must be given the ability to select a specific release series for their dependencies.

First, we understand that software is typically versioned, and that a sequence of releases has a beginning and and end.

Furthermore, we understand that applications use shared libraries and other types of dependencies, which share the same basic characteristics. Shared libraries are also versioned, with a finite maintenance window.

In addition to those characteristics, an application's dependencies share one more characteristic, which is that the dependencies were released before the application.

Dependencies aren't meaningfully different from applications. They may also have dependencies, and when they do, those dependencies will typically have been released earlier, in turn.

And, like applications, dependencies typically follow stable release practices. So, for example, at any given time, the developers of a hypothetical "libEtc" may be supporting multiple releases.

Which brings us to build system requirements. At a given point in time, there may be applications that rely specifically on libEtc's 1.2 release series. Even if the 1.3 series is intended to be compatible, there might be changes in undefined behavior which are not compatible with that application.

At the same time, there may be applications that require libEtc's 2.0 release series.

In some cases, incompatible versions of a single component can be installed in parallel, using distinct path prefixes or distinct file names in the same prefixes. But that's not always the case. Some languages don't make parallel installation simple or idiomatic. Even fewer do so for parallel installation of components that are intended to be backward compatible upgrades, like libEtc 1.2 and 1.3.

For those reasons, many applications will bundle the specific versions of components against which they have been tested, and with which they are known to be compatible. Bundling is not merely easiest, but necessary in many cases.

Applications might bundle their dependencies in a shared prefix (i.e. "/opt/…" in FHS), or they may bundle them by shipping as a container image (including a Flatpak image). But in order to support the build process for those applications, a build system must supply the versions they need, which means that a build system must not flatten component release streams at build time.

24 Sep 2026 12:00am GMT

23 Sep 2026 10:52am GMT

The Anaconda installer in Fedora 45 will introduce a new option for storage configuration: Stratis, a modern solution for local storage management.

Stratis isn't a completely new technology, it uses existing tools and technologies like device mapper, LUKS, and XFS and integrates them into an easy to use package. The idea is to provide modern storage features while hiding the often complex logic behind them. Adding support to the installer brings these features even closer to Fedora users.

There are only two basic structures or layers you need to know when working with Stratis: pools and filesystems. Pools represent an abstract layer on top of existing block devices (disks, partitions, RAID arrays etc.). A pool can consist of one or more devices (for systems with multiple disks, for example). Features like encryption or over-provisioning are also configured on the pool level. Multiple filesystems can be created on the pool. These are devices that will serve as your root or home volumes. Some additional features supported by Stratis include snapshots, caching, and for encrypted pools, multiple unlocking methods like TPM or Clevis/Tang. Caching and encryption without a passphrase are not currently supported by Anaconda, but these can be easily enabled after the installation.

Management of Stratis devices can be done using the stratis command. For more information, check our older, but still valid, article Getting started with Stratis or the Stratis project how-to.

Installation using Web UI

The new web-based user interface for the Anaconda installer currently doesn't allow selecting which type of storage technology will be used for the automated and guided partitioning options. The storage layout you will get depends on the Fedora variant you choose to install. But if you want to use Stratis, you still have an option in the graphical installation. Any storage layout can be created manually using the Cockpit storage module, which is integrated into the installer. To enter it, simply select the If none of the options above apply… option on the Installation Destination step.

The Cockpit storage module supports a wide variety of storage configurations and Stratis is one of the supported technologies. Do not forget that with manual partitioning, you need to create all required partitions so first create partitions required for booting (/boot and /boot/efi or biosboot, based on your system configuration). After that, simply create a new Stratis pool from the menu.

Creating stratis pool

After selecting a name for the pool and the disk (or disks) it will be placed on, you can decide whether to enable encryption and over-provisioning for the pool. Over-provisioning allows allocation of more space for the filesystems created on the pool. Similarly to how LVM thin provisioning and Btrfs work. With over-provisioning enabled, there is no need to worry about running out of space in root with still plenty of free space in /home. It also allows greater flexibility when using snapshots. On the other hand, you actually need to be aware that you don't really have terabytes of space and you need to make sure you won't actually run out of space on your disk. Both encryption and over-provisioning can also be enabled or disabled after the installation.

Creating stratis filesystems

With the new pool created, you now need to add some filesystems to it. You'll most likely want the standard two separate filesystems for your / and /home. But you can also create a separate filesystem for your /var, for example.

If you enable over-provisioning on your pool, you can also decide to not specify sizes for the filesystems and use the 1 TiB default size with over-provisioning or set a size limit for the filesystem to prevent it from automatically growing if you ever run out of space.

Using the configured layout

With all the filesystems created, you can Return to installation. Anaconda will check the created devices to make sure all requirements are met and return you to the Installation destination page where a new Use configured storage option will be preselected with the devices that were just created.

That is the storage part of the installation done. You can double-check on the Review and install page that everything is correctly set and start the installation.

Installation using kickstart

For advanced users who wish to use automated installations, full kickstart support for Stratis is also available. Both automatic and manual partitioning are available via kickstart.

Automatic partitioning is simple: the existing autopart command can be used with -type=stratis to create the default Stratis storage layout fully automatically. A storage section in kickstart, for setting up an encrypted Stratis layout, could look like this:

zerombr
clearpart --all --initlabel
autopart --type=stratis --encrypted --passphrase="passphrase"

Manual partitioning requires building the entire storage layout manually from bottom up. Two new Stratis kickstart commands were added: stratispool for creating and managing Stratis pools and stratisfs for creating and managing Stratis filesystems. Usage of these commands and most of the options are similar to how kickstart partitioning works with LVM. An example of a more advanced Stratis layout can be found below.

reqpart
part /boot --fstype=ext4 --size=500
part stratis.01 --size=1 --grow --ondisk=vda
part stratis.02 --size=1 --grow --ondisk=vdb
stratispool fedora stratis.01 stratis.02
stratisfs / --name=root --poolname=fedora --size=5000 --grow
stratisfs /home --name=home --poolname=fedora --size=1 --grow

Here we are creating a pool called fedora on top of two disks, vda and vdb, with two filesystems. One called root for / and a second called home for /home. The -grow tells the installer to use all available free space when creating the devices. For more details about the commands see the kickstart documentation.

Conlusion

The newly introduced Stratis support in Anaconda offers an easy way to take advantage of the modern storage features offered by Stratis. With the Web UI support available through Cockpit storage, you can now easily use Stratis on your system. We plan to simplify the process even more in future releases and enable even more advanced Stratis features.

If you run into any issues or have feedback, both the Anaconda and Stratis teams would love to hear from you.

23 Sep 2026 8:00am GMT

23 Sep 2026 6:00am GMT

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

⚠️ Warning: this is a pre-release version not ready for production use.

1. Installation

Packages are available in the valkey:remi-9.1 module stream.

1.1. Using dnf4 on Enterprise Linux

# dnf install https://rpms.remirepo.net/enterprise/remi-release-<ver>.rpm
# dnf module switch-to valkey:remi-9.2/common

1.2. Using dnf5 on Fedora

# dnf install https://rpms.remirepo.net/fedora/remi-release-<ver>.rpm
# dnf module reset  valkey
# dnf module enable valkey:remi-9.2
# dnf install valkey

The valkey-compat-redis compatibility package is not available in this stream. If you need the Redis commands, you can install the redis package.

2. Modules

Some optional modules are also available:

• valkey-bloom (Fedora and EL ≥ 9)
• valkey-json
• valkey-ldap (Fedora and EL ≥ 9)
• valkey-lua (always available)
• valkey-rdma
• valkey-tls (always available)

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

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

3. Future

Valkey also provides a set of modules, which may be submitted for the Fedora official repository.

ℹ️ Notices:

• Enterprise Linux 9.8 and 10.2 have Valkey 8.0 in their repository
• Enterprise Linux 9.9 and 10.3 will have Valkey 8.1, already in CentOS Stream
• Fedora 43 has Valkey 8.1
• Fedora 44 has Valkey 9.0
• Fedora 45 will have Valkey 9.1
• Fedora 46 will have Valkey 9.2

4. Statistics

valkey

22 Sep 2026 6:50am GMT

Across the Fedora project, community groups are heavily focused on three overarching initiatives this week. First, following the successful launch of the Fedora 45 Beta, teams spanning Release Engineering, Quality, Infrastructure, and various desktop variants (like GNOME and KDE) are actively organizing test weeks, managing freeze exceptions, triaging blocker bugs, and rolling out a broad reduction in release-blocking legacy storage criteria in preparation for the Fedora 45 Final release. Second, a massive cross-group strategic effort has kicked off to unify the CoreOS working group and the Atomic Initiative; these teams are establishing centralized communication channels, Forgejo boards, and Architectural Decision Records (ADRs) to develop a shared base image for IoT, desktop, and server deliverables. Finally, nearly every Special Interest Group and committee is actively debating consent policies for automated LLM data collection used in weekly community reports, with many teams specifically opting their Matrix chat channels out of the summaries to preserve informal, welcoming spaces for newcomers. Alongside these major efforts, developers are collectively managing the oo7-daemon secrets service transition, executing mass package orphanings for non-responsive maintainers, and handling systemic version bumps for core packages like LLVM and libxml2.

Announcements

The highly anticipated Fedora 45 Beta has been officially released, as detailed across the main discussion topic, a community cross-post, the announce mailing list, and the devel-announce mailing list. Early adopters upgrading via rpm-ostree with RPM Fusion repositories should anticipate some manual workaround requirements, and users have reported temporary download delays while mirrors synchronize. In tandem, the Fedora Linux Asahi Remix 45 Beta is now available, bringing the latest changes to Apple Silicon hardware. In other general news, a recent guide outlines BTRFS boot failure and GUI methods for system recovery using live ISOs, while a post-event report from Data Con LA 2026 highlights a highly successful joint booth with openSUSE showcasing offline local AI, which will help shape a new Small Events Standard Operating Procedure (SOP) for the community.

For contributors looking for active engagement opportunities, the QA team is hosting the CoreOS 45 Test Week starting September 21, calling for community help to verify the upcoming release before it hits stable streams. Additionally, Fedora Podcast 060 announced a major leadership transition: Shaun McCance is stepping in as the new Fedora Community Architect as Justin Wheeler transitions into an AI Alignment role. The podcast team is also actively seeking a volunteer producer to assist behind the scenes with episode scheduling and guest management.

Council

This week, the Council discussed the kickoff for the unification of the CoreOS working group and the Atomic Initiative. The initiative aims to create a shared base image supporting various downstream needs (IoT, desktops, servers, automotive). The team established a dual meeting cadence, a unified Matrix channel, and a new Forgejo board for tracking. Additionally, the Council concluded their evaluation of a temporary private issues process for Fedora Forge and fixed a minor formatting bug in their ticket template.

The Council confirmed that the new temporary workaround for filing private issues on Fedora Forge satisfies their requirements. They also noted that issue locking can be utilized for public-read, restricted-comment scenarios. With these processes validated, the related ticket was closed.

Decisions

• As part of the CoreOS/Atomic Initiative Unification Kickoff, the group decided to centralize communication in the Matrix channel #bootc:fedoraproject.org, track tasks on a new Forgejo board, and use an Architectural Decision Record (ADR) repository for complex technical debates (such as Ignition vs. cloud-init).
• The Council agreed that the proposed private issues process workaround adequately satisfies their requirements for handling sensitive matters on Fedora Forge and closed the ticket as completed.

Contribution opportunities

• Stakeholders of the CoreOS and Atomic Initiatives (especially those involved with IoT and Atomic Desktops) are encouraged to brainstorm ideas, blockers, and priorities in the Etherpad shared in the unification thread.
• Community members interested in the CoreOS/Atomic unification are invited to join the upcoming video call (details and links to be posted in the forum thread).

Learn more about the Council team.

FESCo

This week, FESCo focused on finalizing updates for Fedora 45 ahead of the final freeze and managing non-responsive maintainers. Key actions included approving a major late-stage security update for libxml2 as an Updates Policy Exception, enforcing deadlines for the LLVM 23 update, and limiting the oo7 Secrets Service Provider transition to exclude KDE for this cycle.

Additionally, a massive wave of package orphanings was initiated due to a non-responsive maintainer, though several developers have already stepped up to adopt critical packages. A severe bug regarding kmscon breaking display managers by holding DRM master was also identified and proposed as a release blocker.

Decisions

• The oo7 transition is in progress and will be completed for all deliverables except KDE variants, which are deferred to a future Change.
• The LLVM 23 update must be pushed to stable by Friday, and maintainers must address test failures.
• Approved an Updates Policy Exception to upgrade libxml2 to 2.15.4 in Fedora 45 to address multiple critical CVEs.
• Approved the non-responsive maintainer process for lkundrak, reassigning python-anytree and scheduling over 70 other packages for orphaning.
• Approved the non-responsive maintainer process for mcbeeffx (low-memory-monitor, drpm), moving toward orphaning.

Contribution opportunities

• Multiple packages are slated to be orphaned following the non-responsive maintainer process for lkundrak. While critical packages like NetworkManager have been adopted, dozens of smaller packages (e.g., various perl-*, rubygem-*, and erlang-* libraries) need new maintainers.
• The packages low-memory-monitor and drpm are being orphaned following the non-responsive maintainer process for mcbeeffx and need a new maintainer.
• A community member is looking for co-maintainers and someone to sponsor adoption of the mcelog package in Ticket #3665.

Learn more about the FESCo team.

Packaging Committee

The Packaging Committee focused heavily this week on simplifying the snapshot versioning guidelines after an incorrect package versioning incident broke an upgrade path for bluez and caused inappropriately waived openQA test failures (discussed in Ticket #1569). The committee recognized that having six different acceptable formats for snapshot versions causes confusion and leads to mistakes that break user upgrades.

During their weekly meeting, the committee decided to begin simplifying these rules. They agreed to completely drop the legacy "snapshot-in-release" format from the main guidelines and move it to a historical reference page. Additionally, Ticket #1570 was opened to discuss standardizing on a single "snapshot-in-version" format going forward. The committee also noted its support for potential policy changes that would require QA team approval to waive certain critical openQA tests, such as version regression checks.

Decisions

• Remove the legacy "snapshot-in-release" format from the main packaging guidelines and move it to a historical reference page.
• Formally begin the process of simplifying the "snapshot-in-version" guidelines down to a single standard format.
• Support potential policy changes that would prevent standard provenpackagers from unilaterally waiving specific critical openQA tests (such as "update is older than installed package" tests).

Learn more about the Packaging Committee team.

Mindshare

This week, Mindshare and CommOps focused heavily on upcoming events, particularly organizing the Fedora 45 Release Party, while also navigating significant internal governance challenges. The Mindshare Committee is dealing with a troubling decline in meeting attendance and ticket curation speed, prompting a dedicated effort to diagnose and correct the lack of participation.

Meanwhile, multiple event support requests for Q3 and Q4 were triaged, with approvals moving forward for Texas Linux Fest and Software Freedom Day Bukidnon. Alongside event planning, community discussions touched on the project's stance regarding LLM/gen-AI models and proposed policies around AI summarization of community Matrix channels.

Decisions

• @jflory7 was appointed F45 Party Wrangler, @shaunm as Promotion & Content lead, and @amoloney as Speaker Management lead for the F45 Release Party (CommOps Meeting).
• Akashdeep (@t0xic0der) will remain the Mindshare representative to the Fedora Council for this cycle, delaying a transition to the next cycle (Ticket #131).
• The committee approved funding and support for Texas Linux Fest 2026 and Software Freedom Day Bukidnon 2026.
• A formal ticket was opened to diagnose and address the degrading activity and attendance within the Mindshare Committee (Ticket #153).

Contribution opportunities

• Volunteers are needed to fill the Design and Production & Video lead roles for the upcoming Fedora 45 Release Party (CommOps Ticket #143).
• CommOps is seeking a new representative to sit on the Mindshare Committee for the F45-F46 cycle (CommOps Ticket #145).
• Presenters are encouraged to submit 10-minute talks (such as a Data WG presentation) for the F45 Release Party.
• Mindshare needs committee members to actively vote on pending event tickets to alleviate severe processing delays (Ticket #153).

Learn more about the Mindshare team.

Fedora Join

This week, the Fedora Join group focused on communication strategies, newcomer privacy, and refining the contributor onboarding experience. A notable discussion involved evaluating how the group's public data is summarized by automated tools; the team opted to exclude their Matrix channel from LLM-generated weekly reports to maintain a relaxed, informal space crucial for welcoming newcomers.

Additionally, the group is working on improving contribution pathways. This includes defining a new ticket status to track users who successfully route their contributions directly to upstream projects, and gathering feedback for the Docs team to highlight both technical and non-technical contribution opportunities on the Fedora Docs frontpage. A proposal to establish regular synchronous meetings was also evaluated but remains on hold pending greater member interest.

Decisions

• The group agreed to allow automated LLM-based data collection for their issue tracker but explicitly rejected collecting data from their Matrix channel to preserve a safe, informal chat environment for new joiners (#351).
• A new status tag (S: User contributes upstream) is being adopted for WelcomeToFedora tickets to celebrate and track prospective Fedora contributors who end up contributing directly to upstream projects (#350).

Contribution opportunities

• The Fedora Docs team is seeking ideas and feedback on a new "Contribution" section for the Docs homepage. They are looking for suggestions on which topics, SIGs, and teams (especially non-technical ones) should be highlighted in order to best attract new contributors (#349).

Learn more about the Fedora Join team.

Workstation / GNOME

During this week, the Workstation / GNOME group discussed changes to default packages, release blocking criteria, and upcoming Fedora 45 features. Key topics included the ongoing migration to the new oo7-daemon for secret management, which encountered integration issues in the F45 beta, and discussions surrounding third-party repository policies. The group also evaluated multiple user proposals regarding default packages and installer behavior.

Notable outcomes from these discussions include the Fedora Quality team reducing the list of release-blocking storage interfaces to exclude outdated hardware, and the working group voting to approve the 1Password third-party repository while deciding to retain gamemode in the default Workstation installation.

Decisions

• Implemented a reduction in the release-blocking storage interfaces during installation, formally removing PATA, SCSI, Firmware RAID, Hardware RAID, Fibre Channel, and FCoE from the blocker criteria (Criteria change proposal).
• Voted to approve adding the 1Password repository to the approved third-party repositories, pending verification that it has appropriate AppStream repodata (Ticket #529, Meeting summary).
• Rejected the proposal to remove gamemode from Workstation, deciding to keep it installed by default unless concrete performance data proves it to be detrimental (Ticket #526, Meeting summary).

Contribution opportunities

• Vote on proposed F45 blockers and freeze exceptions directly through the blockerbugs app prior to review meetings to help shorten the meetings.
• Volunteer to author the "What's New in Fedora Workstation for F45" Fedora Magazine article. The deadline for the pitch is October 6, 2026. The team is particularly interested in highlighting non-GNOME features, such as notable kernel changes.
• Contribute actual performance data or propose functionality equivalents in tuned if you wish to advocate for the removal of gamemode.

Learn more about the Workstation / GNOME team.

KDE

This week, the KDE group focused on core system components, beta testing, and future desktop defaults. A significant update for the broader Linux community is the complete removal of the X11 launcher in the newly available KDE Plasma 6.8 Beta. Additionally, the QA team has officially reduced the list of release-blocking storage interfaces for the Fedora installer, deprecating older technologies like PATA, Hardware/Firmware RAID, and Fibre Channel from blocker status.

On the desktop side, discussions are ongoing regarding replacing kwallet with the Rust-based oo7-daemon, though this change is officially deferred for KDE due to integration hurdles. There was also a community proposal to make Collabora the default office suite instead of LibreOffice, but it requires substantial packaging work before formal consideration. Finally, an issue was raised regarding system freezes under heavy memory pressure on Fedora Kinoite, where systemd-oomd fails to trigger appropriately.

Decisions

• The list of release-blocking storage interfaces during installation has been formally reduced. PATA, parallel SCSI, Firmware RAID, Hardware RAID, Fibre Channel, and FCoE are no longer release-blocking, while SATA, NVMe, SAS, and iSCSI remain blockers.
• The transition from kwallet to oo7-daemon is officially deferred for KDE due to unresolved integration issues, meaning KDE variants will not require oo7 immediately.
• The X11 launcher has been completely removed in the KDE Plasma 6.8 Beta.

Contribution opportunities

• Test the newly available KDE Plasma 6.8 Beta via COPR on Fedora 44 or 45, bearing in mind that it may be unstable.
• A maintainer is needed to package Collabora as an RPM in Fedora (starting with a COPR repository) to make it eligible for future Change Proposals regarding the default office suite.
• Contributors familiar with KDE integrations are needed to help resolve migration and implementation issues for replacing kwallet with the oo7-daemon.
• Help is requested to investigate and tweak systemd-oomd configurations to prevent system freezes under extreme memory pressure in interactive Plasma Wayland sessions (Fedora Kinoite).

Learn more about the KDE team.

Server

The Fedora Server Working Group finalized a significant change to the Fedora 45 release criteria, agreeing to remove release-blocking status for several outdated or untestable storage interfaces (including PATA, parallel SCSI, and Hardware RAID) during installation. These hardware interfaces will now be handled on a case-by-case basis. Meanwhile, testing for the Fedora 45 Beta is nearly complete, though a severe, unresolved regression remains regarding LVM partition types for KVM guest and ARM images.

In addition, the group made substantial structural progress on its Ansible support project, deciding to transition their playbooks and roles into a formal Ansible Collection. They have officially claimed the fedoraserver namespace on Ansible Galaxy and are actively preparing to release their core setup utilities under the fedoraserver.general collection, with plans to also provide it as a Copr RPM.

Decisions

• The Server WG approved a criteria change to remove release-blocking status for older storage interfaces (PATA, parallel SCSI, Firmware/Hardware RAID, Fibre Channel, and FCoE) during Fedora 45 installation. Issues will now be handled on a case-by-case basis (Forum Topic).
• The Fedora Server Ansible support tooling will be restructured and published as a collection on Ansible Galaxy under the newly claimed fedoraserver namespace, starting with the fedoraserver.general collection (Ticket #265).
• The Ansible collection will also be packaged as an RPM and distributed via a Fedora Copr repository (Ticket #267).

Contribution opportunities

• Test the nearly feature-complete post-install Ansible role; instructions and code updates are available for review in the Ansible-support repository PRs.
• Review the updated Fedora 45 documentation articles: "Adding Virtualization Support" and "Creating a virtual machine using Fedora Server Edition disk image".
• Assist with outstanding F45 Beta testing, specifically verifying if the NFS connection issue between F44 and F45 persists.

Learn more about the Server team.

Infrastructure

Fedora 45 Beta was successfully released on September 15, and the associated infrastructure freeze was lifted the following day. The next freeze for the F45 Final release is scheduled to begin on October 6. In preparation for the final release, a significant planned outage for mass updates, reboots, firmware upgrades, and database migrations is scheduled for October 1 at 21:00 UTC, which is expected to last approximately 5 hours.

Routine operations this week handled several service hiccups, including intermittent 503 errors on Koji caused by httpd crashes, and a PostgreSQL OOM crash affecting Bodhi and src.fedoraproject.org due to heavy scraper traffic. The team also expanded disk space on several key servers and began reinstalling specific x86 builders due to BTRFS inode exhaustion.

Decisions

• The F45 Beta infrastructure freeze is officially over, and the F45 Final freeze is scheduled to start on 2026-10-06.
• A major planned outage for mass updates, firmware upgrades, and database migrations is scheduled for 2026-10-01 at 21:00 UTC, expected to last approximately 5 hours.
• The team agreed to allow LLM data collection from their Matrix channels and issue trackers to support weekly community reports.
• The team decided not to create a teemtee dist-git group counterpart, opting to keep the status quo as the group does not fit standard packaging group conventions.

Contribution opportunities

• Help is requested to build approximately 70 packages in EPEL10 to migrate the mailman servers to RHEL10.
• A PR review is requested on datagrepper to fix CI test failures and clear out the final pull request before migrating the repository.
• New contributors Sarah Laura Wangari and Karii recently joined and are looking to learn and contribute via the fi-apprentice group.

Learn more about the Infrastructure team.

Release Engineering

Fedora 45 Beta was successfully released this week. This process involved resolving staging path issues, signing the IoT Beta compose, generating release torrents, and processing Bodhi stable pushes for F45 blockers and freeze exceptions.

In infrastructure news, the team resolved a recurring issue that caused Rawhide ostree builds to fail due to missing commits, tracing it to a race condition with the fedora-ostree-pruner job. Additionally, pungi and koji-image-builder were updated on the production compose hosts and builders to prepare for the boot.iso modernization change proposal.

Decisions

• Bug 2530897 (F45 grub boot fails with 'invalid magic number') was accepted as a Final Blocker.
• Bug 2531850, Bug 2524990, Bug 2529069, and Bug 2533000 were accepted as Final Freeze Exceptions.
• The team agreed to allow the #releng Matrix channel to be included in data collection for the weekly LLM-powered Fedora activity reports (Ticket #13525).

Contribution opportunities

• Help is needed to update the release SOPs to include instructions on running the sign_iot.sh script and the expected timing for torrent generation (Meeting log).
• The branching SOP needs to be updated to ensure the new release is added to koji-gc, preventing signed RPMs from being inadvertently cleaned up during branching (Ticket #13534).

Learn more about the Release Engineering team.

Quality

The Quality team successfully approved and shipped the Fedora 45 Beta (Beta-1.3) this week, officially kicking off the Fedora 45 Final phase. The team held its regular meeting and a blocker review meeting, accepting one Final Blocker and four Final Freeze Exceptions. A major update to the release criteria was also finalized: the proposal to reduce the list of release-blocking storage interfaces was officially implemented, removing legacy and untestable interfaces like PATA, SCSI, and hardware/firmware RAID from the blocking criteria.

Test days were a major focus this week: the KDE Plasma 6.7 test week is ongoing, the CoreOS F45 test week is scheduled for September 21-25, and an Anaconda F45 features test week is planned for September 28 to October 2. Behind the scenes, the team continued working on CI infrastructure, including planning the migration of tests away from Jenkins, fixing a bug in the installability test pipeline, and tweaking rpmlint configurations.

Decisions

• Accepted Bug 2530897 (grub boot fails with invalid magic number on FW RAID) as a Final Blocker.
• Rejected Bug 2533000 (Reboot and poweroff no longer work in console for regular users) as a Final Blocker, but accepted it as a Final Freeze Exception.
• Accepted Bug 2531850, Bug 2524990, and Bug 2529069 as Final Freeze Exceptions.
• Reduced the list of release-blocking storage interfaces during installation: PATA, parallel SCSI, Firmware RAID, Hardware RAID, Fibre Channel, and FCoE are no longer release-blocking. SATA, NVMe, SAS, and iSCSI remain release-blocking (Criteria change proposal).
• Decided to downgrade rpmlint spelling errors to warnings and add common technical terms to the allowlist, rather than turning the check off globally (Ticket #591).
• Decided against collecting the Quality Matrix channel for the LLM-powered weekly reports to preserve the informal nature of the chat (Ticket #940).

Contribution opportunities

• Participate in the KDE Plasma 6.7 Test Day from September 14 to 20.
• Participate in the Fedora CoreOS 45 Test Week from September 21 to 25.
• Prepare to participate in the Anaconda F45 features test week planned for September 28 to October 2.
• Test for graphical corruption on Intel laptops running kernel 6.19 and report back on the forum thread.

Learn more about the Quality team.

Websites and Apps

This week, the Websites and Apps team heavily focused on optimizing website performance by migrating beta download pages from client-side JavaScript execution to static Server-Side Rendering (SSR). This change, successfully rolled out for several pages including Spins and Labs, significantly improves initial page load times. In addition, the team addressed routing issues, such as fixing a broken redirect for the Kinoite sub-site.

Other discussions included a forum proposal to build a web-based interactive package dependency visualizer to help users understand why certain dependencies (like openh264) are pulled in by dnf. The team also approved the inclusion of their communication channels in the LLM-powered weekly project reports.

Decisions

• Transitioned the beta download pages (such as Spins, Labs, and /misc) from client-side JavaScript toggles (?beta) to static server-side rendered routes (/beta) to dramatically reduce page load times (implemented via static (SSR) beta download pages?).
• Decided not to expose "Bootable Containers" download artifacts on the website unless explicitly requested by the Silverblue or Workstation teams.
• Fixed a broken redirect for kinoite.fedoraproject.org to properly point to the Atomic Desktops Kinoite page.
• Agreed to allow LLM data collection for the Websites and Apps group to assist with weekly reporting, and added the Fedora CMS repository to the tracked sources (Collection of this group's data for a LLM-powered weekly report).

Contribution opportunities

• Help migrate remaining download pages away from client-side JavaScript to static server-side rendering (SSR) to improve page load times across the Fedora website.
• Contribute to building a web-based interactive dependency tree visualizer for Fedora packages (potentially using sigma.js) to help users trace why specific packages are pulled in during dnf installs.

Learn more about the Websites and Apps team.

Design

The Design team successfully launched the new How to Join and FAQ pages as part of the Fedora Design Docs Revamp project, and completed their review of design repositories migrated from Pagure. While the weekly meeting in the Design Matrix Room was canceled due to low attendance, async collaboration continued on various tickets.

The EPEL Steering Committee officially approved their new member badge designed by the team. Meanwhile, new work has kicked off, including a high-priority request for F45 Virtual Release Party graphics and ongoing user experience research for Project Resistor. The team is actively welcoming community contributions for the upcoming F46 Wallpaper and a custom avatar for the Matrix Moderation Bot.

Decisions

• The EPEL Steering Committee officially voted in favor of accepting the new EPEL member badge design created by the Design team (Ticket #60).

Contribution opportunities

• Any contributor is welcome to lead or collaborate on promotional graphics and visual assets for the F45 Virtual Release Party (Event Banners, Streaming Assets, Badge Art). The deadline is October 16.
• Anyone in the Fedora community is encouraged to contribute sketches and visuals for the F46 Wallpaper by September 28.
• The team is looking for a community member to design a new avatar for the Matrix Moderation Bot (e.g., a police hat with the Fedora logo).
• Team members are asked to provide their input on whether they consent to their Matrix chat being collected for LLM-powered weekly reports.

Learn more about the Design team.

Docs

This week, the Docs group focused heavily on modernizing site infrastructure and improving community engagement and discoverability. Key themes across the four active tickets included making the documentation more accessible to both human contributors and artificial intelligence, as well as enhancing the reliability of the site's automated builds.

Notable progress was made on planning a modern design for the Docs homepage, which aims to introduce clear, high-contrast calls to action for new contributors. In parallel, the team debated providing summaries of their Matrix channel to This Week in Fedora via an LLM bot, and discussed adding llms.txt discovery indexes to help AI agents parse the site efficiently. Furthermore, a simple monitoring solution was deployed to catch stalled documentation builds.

Decisions

• The Docs Team Initiative Leads decided that the new homepage design will feature clear invitations for users to become contributors, specifically introducing a high-contrast ribbon banner on every page and dedicated buttons near the navigation header.
• The team decided to defer a final ruling regarding the Matrix channel bot for This Week in Fedora to the September 22 meeting to allow more time for community feedback.
• A simple monitoring solution based on timestamps was implemented and merged to track staging and production build delays, while the team continues to evaluate a more comprehensive Zabbix setup.

Contribution opportunities

• Contributors are invited to experiment with prototypes for the Docs homepage redesign before official prototypes are drafted in late September/early October.
• Help is welcome to evaluate, configure, or assist with setting up Zabbix for infrastructure monitoring as a more robust alternative to the current timestamp-based workflow.

Learn more about the Docs team.

Internationalization

This week, the Internationalization group received a ticket regarding data collection for the LLM-powered "This Week in Fedora" weekly report. The author outlined the planned data sources, which include the i18n, trans, and trans-announce mailing lists, the issue tracker, and Matrix meeting channels. Per a decision made last week, general chat messages in #l10n and #i18n will be excluded. The author is currently seeking confirmation on these sources and asking if any additional platforms (such as RSS feeds) should be included in the collection.

Learn more about the Internationalization team.

Legal

The Legal team continued to discuss the Copr hosting question regarding packages that build against proprietary software, specifically the NVIDIA CUDA toolkit. Maintainers requested clarification on whether compiled artifacts could be distributed under open-source licenses if they do not directly bundle the proprietary library.

However, respondents in a follow-up thread cautioned against this approach. They noted that compiling against proprietary C/C++ headers often inadvertently embeds proprietary functional code into the resulting binary. Due to the unfeasibility of auditing headers at every version update to ensure no proprietary code is included, it was suggested that such software should be packaged in third-party repositories like RPMFusion rather than Fedora proper or Copr.

Learn more about the Legal team.

EPEL

This week, the EPEL group expedited an ffmpeg update in EPEL 9 to resolve Qt 6 build issues stemming from the LLVM 22 update in CentOS Stream 9. Several administrative cleanups were also announced, including the sunsetting of the defunct epel-packagers-sig mailing list and the planned retirement of the unused rust-libz-rs-sys package.

Additionally, the EPEL Steering Committee approved a new badge design for its members and evaluated a proposal for LLM-powered data collection of group activities. The committee decided to opt out of data collection for their main Matrix channel while deferring the decision on other sources to a future meeting. Development work also continued with updates to mock-core-configs for CentOS Stream and AlmaLinux Kitten EPEL 10 chroots.

Decisions

• An update for ffmpeg, ffmpeg5, and dependent packages will be pushed to epel9 via a side tag sooner than originally planned to fix qt6 build issues.
• The epel-packagers-sig mailing list has been sunset and configured to reject and discard emails due to inactivity and spam.
• The new EPEL Steering Committee Badge graphics were officially approved by committee vote.
• The steering committee voted to reject the collection of data from the main #epel:fedoraproject.org Matrix channel for LLM-powered weekly summaries (Issue 373).

Contribution opportunities

• A maintainer is sought for the rust-libz-rs-sys package in EPEL 9 and EPEL 10. The package is currently an unused leaf package and will be retired in two weeks if no one steps forward.

Learn more about the EPEL team.

ELN

The ELN SIG held a meeting this week. The group announced that the Content Resolver is now based on dnf5, making it significantly faster and allowing for more frequent updates. They also reported that recent weekend composes failed due to llvm and libxml2 soname bumps, but the issues were resolved by building compatibility versions.

In addition, attendees noted ongoing upstream discussions regarding the unification of Bootc and CoreOS, and will monitor for any implications for ELN. Finally, the group issued a reminder that with the Fedora 45 feature freeze now past, any changes targeted at RHEL 11 must land in Rawhide as soon as possible.

Decisions

• Community members are reminded that since the Fedora 45 feature freeze has passed, any work targeted at RHEL 11 must land in Rawhide ASAP.

Learn more about the ELN team.

Atomic

The primary focus of the Atomic group this week was the kickoff of the unification between the CoreOS working group and the Atomic Initiative. This strategic shift aims to create a shared base image supporting various downstream needs (such as IoT, desktops, and servers) while establishing unified community structures, including shared meetings, issue trackers, and a single Forgejo board. Central to this effort is the immediate goal of building a Minimum Viable Project (MVP) for an initial unified bootable image, while complex architectural debates-such as whether to support both Ignition and cloud-init-are being moved to an Architectural Decision Record (ADR) repository.

In addition to the unification efforts, the community engaged in a lively discussion regarding the Anaconda installer's handling of EFI System Partitions (ESPs) in multi-boot scenarios, weighing the benefits of dedicated ESPs against firmware limitations. Technical work across the trackers included addressing missing /run/ostree-booted checks for composefs backend compatibility, improving trademark compliance workflows for derivative bootc images, and removing redundant packages from Silverblue. Finally, the group evaluated modifying their data collection permissions for LLM-powered weekly reports, opting to exclude Matrix chat channels from future summaries.

Decisions

• The group decided to reorganize its meeting cadence, maintaining a tactical Wednesday chat meeting for CoreOS maintenance and moving forward-looking unification discussions to a TBD video call on Tuesdays.
• A new Forgejo board has been adopted to track unification work, and an Architectural Decision Record (ADR) repository was established to manage complex technical proposals like cloud-init vs ignition support.
• Communication for the unified initiative will be centralized by renaming and repurposing the existing Matrix channel #bootc:fedoraproject.org.
• The group decided to exclude the #atomic-desktops Matrix channel and the atomic mailing list from being collected by the LLM-powered 'This Week in Fedora' report, restricting data collection to Discourse posts and tracker issues.
• Work prioritization for the unification initiative will follow a 'Doacracy' model, meaning contributors are empowered to work on what they prioritize, though some baseline tasks may be requested first to unblock subsequent efforts.
• The redundant totem-video-thumbnailer package is being removed from the Silverblue image in favor of the newer gst-thumbnailers.

Contribution opportunities

• Contributors are invited to participate in the CoreOS/Atomic Initiative unification planning, including providing input via the Architectural Decision Records (ADR) on foundational technical choices.
• Feedback and stakeholders from IoT and Atomic Desktops are explicitly requested for the unification brainstorm via this Etherpad.
• Help is needed to establish a reliable reproducer for Issue #130 regarding systemd-oomd failing to kill runaway processes before the KDE Plasma desktop completely freezes on Fedora Kinoite 44.

Learn more about the Atomic team.

CoreOS

This week, the Fedora CoreOS team focused heavily on preparing for the Fedora 45 CoreOS Test Week (September 21-25) and rolling out the rebased next stream to Fedora Linux 45. The F45 beta brings features like native Butane support in Ignition and chunked container images for better layer reuse, while preparations are well underway to address incoming bug reports and document major changes.

Additionally, the community formally kicked off the CoreOS and Atomic Initiative Unification working group to discuss merging their outputs and community structures, starting with base image alignment. To resolve ongoing boot partition space constraints, the team also made the strategic decision to drop all Device Tree Blobs (DTBs) on aarch64 builds for F45.

Decisions

• The team agreed to remove all Device Tree Blobs (DTBs) on aarch64 builds starting in F45 to resolve ongoing boot partition space constraints. This change is being fast-tracked before the F45 Test Week to allow for early ecosystem testing (Meeting log, Issue #2222).
• The CoreOS/Atomic Initiative Unification working group decided to establish a unified communication channel by repurposing the #bootc:fedoraproject.org Matrix channel and will track architectural decisions in a new Forgejo board (Forum post).

Contribution opportunities

• Fedora 45 CoreOS Test Week (Sept 21-25): Community members are invited to help test the F45 beta release. A live virtual session will take place on Sept 21. Details are available on the Fedora Wiki and discussion post.
• CoreOS/Atomic Unification Feedback: Interested stakeholders (especially from IoT and Atomic Desktops) are asked to provide their input on blockers, priorities, and stakeholder mapping in the brainstorming Etherpad.
• Meeting Scheduling: Contributors interested in participating in the Unification working group can share their availability for future meetings via Timeful.

Learn more about the CoreOS team.

IoT

The Fedora IoT Working Group focused on reviewing Koji composes and OpenQA test results for Fedora IoT 44, 45, and 46, which all generally look good despite a few expected minor issues. In notable news for the broader community, the Fedora IoT 45 Beta has been officially released. Additionally, the group's CI pipeline is now running green following recent fixes, and routine cleanup of older issues took place.

Decisions

• Closed Issue #136 regarding F-44 image passwords, as the maintainers could no longer reproduce the bug.

Learn more about the IoT team.

ARM

This week, the Fedora ARM group focused on troubleshooting Wi-Fi regressions on the Raspberry Pi 5, specifically regarding WPA3 support and the latest brcmfmac firmware. The group was also invited to the upcoming Fedora 45 Blocker Review meeting and received a request for consent regarding the automated collection of their communications for an LLM-generated weekly community report.

Contribution opportunities

• Vote on proposed blockers and freeze exceptions for Fedora 45 Final prior to the review meeting to speed up the process.
• Provide feedback on whether the group consents to having their Matrix chat history and mailing list data collected for automated "This Week in Fedora" weekly summaries.

Learn more about the ARM team.

Hummingbird

This week, the Hummingbird group focused on the proposed unification of the CoreOS working group and the Atomic Initiative. To ensure all stakeholders could participate in the unification kickoff discussions, the regular Hummingbird community meeting scheduled for September 17 was canceled (URL). The unification effort aims to build a shared base image for IoT, desktop, server, and automotive use cases, and the community has begun defining the Minimum Viable Project (MVP) and restructuring their communication channels (URL).

Decisions

• The regular Hummingbird community meeting for September 17 was canceled to avoid overlap with the unification discussions (URL).
• Communication for the CoreOS and Atomic unification initiative will be centralized by repurposing the #bootc:fedoraproject.org Matrix channel (URL).
• The unification group will adopt a two-track meeting cadence: tactical chat-based meetings on Wednesdays and a future-focused video call on a day to be determined (URL).
• Work and architectural decisions will be tracked on a new Forgejo board using "decide:" tags, alongside a newly created Architectural Decision Record (ADR) repository (URL).

Contribution opportunities

• Stakeholders, especially from IoT, Atomic Desktops, and CoreOS, are invited to share ideas, blockers, and priorities regarding the CoreOS/Atomic unification in the project's Etherpad before the next meeting (URL).
• Community members interested in the technical direction of the base image are encouraged to join the newly designated #bootc:fedoraproject.org Matrix channel and participate in upcoming asynchronous Architectural Decision Record (ADR) discussions (URL).

Learn more about the Hummingbird team.

Kernel

Aurelien Bompard reached out to the Kernel group to discuss data collection for an LLM-powered weekly report called "This Week in Fedora." The goal of the report is to summarize group activities, foster newcomer participation, and highlight requests for help. He is requesting the group's consent to collect public data from their mailing list and Discourse tags, as well as their public Matrix channel.

Learn more about the Kernel team.

AI & ML

The AI & ML group engaged in a robust discussion this week regarding the alignment of various LLM and generative AI models with Fedora's open-source values, specifically weighing raw AI performance against software freedom. This was sparked by a proposal to set up an "Olmo" 32B-Instruct Fedora playground and expanded into a broader forum debate about whether Fedora needs to standardize on a model for potential centralized inference infrastructure.

In other activity, a prototype of newly proposed build tools was successfully utilized to package vLLM on Fedora. Additionally, the group discussed including their Matrix channel data in the automated "This Week in Fedora" LLM-generated reports. While some concerns about chat privacy were raised, the group is leaning toward a trial inclusion provided there is clear signage and communication in the room.

Contribution opportunities

• Share your perspective on which LLM models best align with Fedora's principles and whether the project should focus on fully-open models versus performant open-weight alternatives.

Learn more about the AI & ML team.

RISC-V

This week, the RISC-V group focused heavily on preparing for upcoming Fedora releases and evaluating future architectural baselines. The Fedora 45 rebuild is largely complete with key kernel updates landed, and massive rebuilding for Fedora 46 is now underway. The team is also actively investigating bootstrapping Fedora ELN (Enterprise Linux Next) for RISC-V, which will provide downstream distributions with vital configuration previews.

Additionally, discussions began on transitioning the Fedora architecture baseline from RV64GC to RVA23. The group plans to keep the existing ABI while defaulting the toolchain (GCC/LLVM) to RVA23 to maintain compatibility. Finally, the group successfully coordinated with upstream LLVM to address failing test suites and submitted a proposal to host the RISC-V microconference at FOSDEM.

Decisions

• The group decided to opt out of having their public Matrix channel logs collected for LLM-generated weekly reports, limiting data collection to Discourse, meeting logs, and the issue tracker. (Collection of this group's data for a LLM-powered weekly report)
• The transition to the RVA23 baseline will retain the current ABI (which does not enable vector registers by default in the calling convention) to ensure compatibility between existing and new binaries. (Investigate the switch to RVA23 baseline)

Learn more about the RISC-V team.

Security

The Security SIG cancelled their September 17 meeting, postponing discussions on allowing LLM data collection for weekly reports to September 24. A major focus this week was addressing the poor quality of CVE reports swamping Bugzilla and causing maintainer fatigue. Red Hat Product Security provided an in-depth look at their transition to a new koji-sbom scanning pipeline, which relies strictly on RPM metadata rather than source code analysis, significantly reducing false positives for unshipped code, interpreters, and dynamically linked libraries.

Contribution opportunities

• The SIG is seeking community input on how to handle EPEL CVE bugs in Bugzilla: Should they continue to be collapsed into a single epel-all tracker, or should a separate tracker be filed for each specific EPEL version (8, 9, 10) that actually ships the affected package? Join the discussion on Issue #23.
• Maintainers are asked to review the Vulnerability Reporting Contact ticket to confirm if it can be officially closed.

Learn more about the Security team.

NeuroFedora

The NeuroFedora Special Interest Group reviewed a recent orphaned packages report this week and adopted several dependencies to keep them maintained in the distribution. To reduce unnecessary maintenance burdens, the team decided to drop some leaf packages and break a test-dependency chain, allowing a few test-related packages to be gracefully retired. Additionally, group members expressed support for having NeuroFedora's public data collected and summarized for the "This Week in Fedora" automated weekly report.

Decisions

• Adopted multiple orphaned packages to maintain them in Fedora, including python-pyqt-feedback-flow, python-trx-python, python-annarchy, textdistance, and units-llnl.
• Decided to break the test-dependency chain from python-xnat to allow retiring python-xnat4tests and python-medimages4tests.
• Approved the collection of the group's public communication data for the This Week in Fedora LLM-powered weekly report.

Contribution opportunities

• Contributors interested in maintaining the openneuro-py CLI tool for Fedora are welcome to take over the python-openneuro package, which is otherwise slated for retirement.

Learn more about the NeuroFedora team.

Go

A ticket was opened to discuss the collection of the Go group's data for "This Week in Fedora," an LLM-powered weekly report. The author confirmed that while the #golang chat channel will not be collected based on prior feedback, they plan to collect data from the golang and go-sig mailing lists, the issue tracker, and Matrix meeting channels. Feedback is requested from the group to approve these sources and identify any additional platforms to track.

Decisions

• It was noted in Issue #69 that the group previously decided against allowing the collection of messages from the #golang chat channel for the weekly report.

Contribution opportunities

• The author of Issue #69 is seeking feedback on whether it is acceptable to collect activity from the golang and go-sig mailing lists, the issue tracker, and Matrix meeting channels for the "This Week in Fedora" report. They are also asking if the group has other sources, such as RSS feeds, that they would like included in the collection.

Learn more about the Go team.

Perl

This week, the Perl group focused entirely on routine package maintenance, including version updates, test corrections, and compliance fixes. All 15 mailing-list posts were automated notifications representing pull requests that were successfully opened and merged by package maintainers.

Key updates involved version bumps for perl-CPAN (2.41), perl-Dist-Zilla (6.039), and perl-LWP-MediaTypes (6.05). Furthermore, maintainers addressed test stability in perl-Dist-Zilla and ensured proper open-source documentation by adding missing license files to perl-Net-DAVTalk and perl-Net-CalDAVTalk.

Decisions

• Updated perl-CPAN to version 2.41 to resolve bug ticket rhbz#2533611 (PR #5).
• Updated perl-Dist-Zilla to version 6.039 (PR #13).
• Updated perl-LWP-MediaTypes to version 6.05 (PR #3).
• Added missing LICENSE files to the perl-Net-DAVTalk and perl-Net-CalDAVTalk packages to ensure proper compliance (e.g., PR #10).

Learn more about the Perl team.

Python

This week, the Python SIG welcomed a new contributor, Renato Loureiro, a UK-based student and Python developer who plans to help package and maintain Python applications. Additionally, Aurelien Bompard requested permission to include the group's public communications (mailing lists, Discourse, and the Matrix channel) in the LLM-generated "This Week in Fedora" report. A group member responded favorably, agreeing that summarizing public sources is acceptable.

Decisions

• The group tentatively agreed that the "This Week in Fedora" automated report may collect and summarize data from the Python SIG's public sources, including the Matrix channel, provided it avoids extensively quoting fleeting messages.

Learn more about the Python team.

Rust

The Rust group had 2 tickets this week, focusing on legacy package deprecation and community communication policies.

Members initiated a major cleanup of outdated Rust bindings for GLib and GTK4, specifically targeting the unmaintained gtk-rs-core v0.20 and gtk4-rs v0.9 packages. Tracking bugs have been filed for affected downstream applications, and third-party libraries will require updates to matching versions before the old compatibility packages can be completely removed. Additionally, the group concluded a vote on whether their communication channels could be collected for an LLM-powered weekly report. The SIG reached a consensus to allow the ingestion of mailing lists, Discourse posts, and ticket trackers, but opted out of including their Matrix chat channel history due to its casual and ephemeral nature. Detailed discussions can be found in the package cleanup ticket and the LLM data collection ticket.

Decisions

• Initiated the deprecation of unmaintained gtk-rs-core v0.20 and gtk4-rs v0.9 packages, requiring maintainers of downstream applications and third-party libraries to update their bindings. (Ticket)
• Approved the collection of data from the Rust mailing lists, Discourse, and ticket trackers for the LLM-powered "This Week in Fedora" weekly report. (Ticket)
• Declined the collection of Matrix channel history for the weekly report to preserve the casual and ephemeral nature of the chat. (Ticket)

Contribution opportunities

• Maintainers of applications depending on gtk-rs-core v0.20 or gtk4-rs v0.9 (e.g., envision, gnome-commander, gnome-user-share, libibpuz, rust-tiny-dfr, wildcard) are requested to update their applications to newer bindings so the legacy packages can be retired. (Tracking Ticket)
• Assistance is needed to update third-party libraries like rust-delicious-adwaita, rust-relm4, and rust-vte4 to match the updated GTK/GLib binding versions. (Tracking Ticket)

Learn more about the Rust team.

Other Discussions

• JC introduced btrfs-patrol, a new snapshot and rollback tool designed specifically for Fedora's default btrfs layout, triggering a discussion on handling kernel modules and updates that led to hardening releases and new recovery features being added.
• Ellie started a discussion about the potential risks of AI-generated code in the Linux kernel, with participants noting that many developers remain quietly skeptical about the cognitive impact and sustainability of LLMs despite recent remarks from leadership.
• Norihiro Nakaoka reported that over 2,300 Fedora/EPEL security tracking bugs became private and broke downstream CVE mapping tools, which Alasdair Kergon later confirmed was an accidental spam flag that would be reverted.
• Aoife Moloney submitted a Change Proposal to enable Shadow Stack protection by default for x86_64 applications in Fedora 45, prompting developers to analyze specific build failures and discuss debugging methods for the new hardware-enforced security features.
• Christopher highlighted that GMail will soon remove the ability to send emails from @fedoraproject.org addresses, while other members shared examples of strict DMARC/SPF/DKIM policies causing Google to reject even valid mailing list messages.
• Michal Schorm shared a list of roughly 3,400 leaf packages that could drop i686 support because they are only used in the buildroot, gaining support from maintainers looking to safely prune the legacy architecture.
• Miroslav Suchý asked developers to donate a minute of their time to test Fedora 44 to 45 upgrades using a dry-run distro-sync, which successfully uncovered broken dependency chains for packages like openh264, protobuf, and ceph.
• Gordon Messmer proposed integrating got-audit as a generic Fedora test to detect ELF namespace tampering in systemd service units, successfully updating the tool with debugging assistance from Florian Weimer.
• Norbert Manthey from Amazon proposed extending default compiler settings to harden applications, sparking a debate with GCC maintainers over the potential performance penalties and breakage of valid C++ code.
• Martin Gansser asked for help processing a stuck review request, discovering that the original reviewer had lost packager privileges before another maintainer stepped in to help.
• Other discussions this week included fedora-review crashing on Fedora 45, an inquiry about Mangohud seeming unmaintained, a request for a meshoptimizer review swap, a new contributor seeking sponsorship for their first package, a question about sources files still using the plain md5sum format, delays with F45 beta images on mirrors, the scheduling of the Fedora 45 Blocker Review Meeting, reports that kmscon is broken, a proposal for splitting perf out of the kernel packaging, a patch submission for teamd on the libteam list, and a notification of a pushed devel branch on the glibc list.

Package updates

• ffmpeg upgrade from 8.1 to 9.0
• update of libxml2 and mini mass rebuild in rawhide and for F45
• OCaml 5.1.1 rebuild
• OpenVDB 13.1.0 SONAME change and coordinated rebuilds
• abseil-cpp 20260817.0 coming to F46/Rawhide
• pnpm version updates to 11 and 12
• Updating opencascade to 8.x

New contributor introductions

• Damian Daniel
• Albert Esteve
• Angelo Theodorakis

All contribution opportunities

For community members with Quality Assurance & Testing skills, there are numerous highly accessible ways to contribute to upcoming releases. Volunteers can participate in formal test events like the KDE Plasma 6.7 Test Day, the Fedora 45 CoreOS Test Week (with discussions on the forum), and the Anaconda F45 features test week. Testers are also needed to evaluate the unstable KDE Plasma 6.8 Beta, check for graphical corruption on Intel laptops running kernel 6.19, establish reproducers for systemd-oomd freezes on Fedora Kinoite, and verify F44 to F45 dry-run distro-sync upgrades. Additionally, users can contribute performance data for tuned or expedite meetings by voting on proposed blockers for Workstation and ARM.

Contributors with Software Development & Package Maintenance skills are urgently needed to adopt orphaned packages, including low-memory-monitor, drpm, mcelog, rust-libz-rs-sys, python-openneuro, and numerous small perl-*, rubygem-*, and erlang-* libraries. Developers can also help by packaging Collabora for a future Change Proposal, updating Rust applications to newer GTK/GLib bindings (Ticket #40), or assisting Infrastructure by building ~70 EPEL10 packages and reviewing datagrepper pull requests. Web developers are invited to migrate download pages to Server-Side Rendering or build an interactive dependency tree visualizer, while experienced packagers are encouraged to assist with stalled package reviews and sponsor new contributors.

Those with Design, Writing, & Event Production skills can make a significant impact without deep technical expertise. Creatives can generate promotional graphics for the F45 Virtual Release Party, submit sketches for the F46 Wallpaper, or design a new avatar for the Matrix Moderation Bot. Writers can author the "What's New in Fedora Workstation for F45" article, update release engineering SOPs for torrents and script timing (Meeting log and Ticket #13534), or review Server documentation. Event organizers and speakers are encouraged to take on the Production & Video lead roles for the F45 Release Party (Ticket #143) or submit 10-minute talks.

Finally, anyone capable of providing General Feedback & Strategic Discussion is strongly encouraged to help shape project direction. A major ongoing effort is the CoreOS/Atomic Initiative unification; stakeholders are asked to brainstorm in this Etherpad, join the kickoff discussions, review foundational Architectural Decision Records, and share meeting availability. Broad community input is also needed to decide which LLM models best align with Fedora's principles, how to organize EPEL CVE bug trackers, and which groups to highlight on the new Docs Contribution page.

21 Sep 2026 9:06am GMT

Earlier tonight, my desktop fired a notification: upstream had tagged a new release for one of the packages I maintain in Fedora Copr. My background auditor had caught the new release tag from an Atom feed, compared it against my local RPM spec, and alerted me.

Yet nothing was committed. Nothing was pushed. No build had queued.

Why? Because my auditor script was just that-an auditor. It was built strictly to notify, not to act. But when I sat down to fix it, I asked myself a question that every systems engineer wrestling with AI agents needs to confront: How much of this workflow should actually touch an LLM?

+-----------------------------------------------------------+
|                  Deterministic Spine                      |
|                                                           |
| [Pull Remote] -> [Fetch Archive] -> [Update Spec/Config]  |
|                                            |              |
|                                            v              |
|                                  [Compile / Lint Gate]    |
+--------------------------------------------+--------------+
                                             |
                            +----------------+----------------+
                            |                                 |
                         [Success]                         [Failure]
                            |                                 |
                            v                                 v
                  [Commit & Push Remote]            +-------------------+
                                                    | Forensic Tripwire |
                                                    | - Capture Logs    |
                                                    | - Capture Diffs   |
                                                    +---------+---------+
                                                              |
                                                              v
                                                    +-------------------+
                                                    | AI Agent Dispatch |
                                                    | (Isolated Unit)   |
                                                    +---------+---------+
                                                              |
                                                    [Diagnose & Remediate]
                                                              |
                                                              v
                                                    [Re-enter Det. Gate]
                                                    (Circuit Breaker: max 2)

# Triggered asynchronously via systemd-run --user
fedora-copr-update.bash --watch obscura 0.2.3

# Inside fail_and_dispatch()
systemd-run --user \
   --unit="agy-copr-fix-${PKG}-${TIMESTAMP}" \
   --description="Antigravity Interlock Auto-Fix for ${PKG}" \
   agy \
      --add-dir "${PKG_DIR}" \
      --dangerously-skip-permissions \
      --mode accept-edits \
      --effort high \
      --print \
      --prompt "${DIAGNOSTIC_PAYLOAD}"

21 Sep 2026 2:55am GMT

A somewhat busy week for me, so lets get into it..

19 Sep 2026 9:21pm GMT

Intro

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

The Famous Last Words

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

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

Defective Detective

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

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

More Hands, Quick Hands

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

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

Where Are Those Templates?

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

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

Lay of the Land

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

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

No Audio? No Problemo!

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

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

Outro

One of the (rather unarguably) best ways to fix a problem is to first face the problem itself before rolling up your sleeves to resolve it. What I initially thought would be a very atomic and less influential contribution method ended up touching 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.

This article was originally posted on Fedora Magazine on 09th September 2026.

17 Sep 2026 6:30pm GMT

On Saturday, August 22, 2026, the Fedora Project joined forces with openSUSE at Data Con LA 2026, hosted on the campus of California State University, Long Beach (CSULB).

Now in its 14th year, Data Con LA is Southern California's largest gathering of data professionals, students, and practitioners covering data science, AI/ML, and data engineering. While Data Con LA is not a traditional Linux-centric conference, our presence offered a unique, hands-on opportunity to engage a fresh audience of prospective contributors, test our event planning workflows, and showcase Fedora Workstation in action.

As part of our ongoing work to standardize the Fedora Ambassador event pipeline, this report reflects on our operational outcomes, what worked well, and key lessons learned for future event organizers.

1. A Standout Win: "A House with Many Rooms" (Co-Hosting with openSUSE)

Our standout operational victory at Data Con LA was co-locating and sharing table space side-by-side with openSUSE advocates (coordinated with Patrick Finie / mir and Drew Adams).

Rather than maintaining isolated tables, we embraced the philosophy of "A House with Many Rooms." This cross-community collaboration was an immediate force multiplier:

• Shared Energy & Presence: Combining our presence effectively doubled our footprint and visual appeal, turning our shared booth area into a high-energy focal point in the expo area.
• Seamless Staffing & Rotations: Having four volunteers across both distributions allowed for seamless shift rotations during peak traffic and lunch breaks, completely preventing booth fatigue.
• Cross-Promotion: When attendees visited our table, we engaged them collaboratively by directing people to open source solutions across distros based on their specific technical needs and interests.

For future community organizers planning small-to-medium booths, establishing a shared booth with allied open source projects is an operational model we strongly recommend.

2. Demographics & Lead Engagement

Over the course of the day, our booth engaged approximately 100 visitors (110% of our initial goal), with peak traffic occurring during the post-keynote morning rush (9:30 AM - 11:00 AM) and lunch transitions (12:30 PM - 2:00 PM).

The attendee demographic offered valuable insights into the broader tech ecosystem:

• Student & Alumni Presence: The majority of visitors were CSU Long Beach undergraduate and graduate students, alumni, and local data practitioners.
• First Encounters with Linux: Roughly 10% of attendees were active Linux users; for the remaining 90%, Data Con LA was their first direct introduction to Linux and Fedora.
• Lead Qualification Breakdown:
  • Hot Leads (30): Inquired specifically about Fedora, visited the website, and expressed interest in installing Fedora Workstation or exploring the Join SIG.
  • Warm Leads (20): Asked for links to documentation, Fedora Discussion forums, Matrix channels, or local user groups (such as SGV LUG in Pasadena and SFV LUG in Northridge).
  • General Engagements (10+): Discussed general data industry trends, tech careers, or university studies.

3. The Technical Showcase: Local AI on Fedora Asahi Remix

To connect directly with the conference's AI/ML focus, we showcased a fully offline, containerized local AI demonstration running on an Apple Silicon laptop.

The Setup

• Hardware: 2020 Apple M1 MacBook Air (8 GB RAM) dual-booting macOS.
• Operating System: Fedora Asahi Remix (Fedora 44 release) running GNOME on Wayland.
• Software Stack: Fedora-native Podman containers running Ollama alongside Open WebUI, exposing a private, ChatGPT-style web interface at localhost.
• Model: llama3.2:1b (sized appropriately for the laptop's 8 GB memory ceiling).

Why It Resonated

This demonstration served as a major crowd-pleaser across two distinct attendee groups:

1. Data Professionals & Privacy: Attendees expressed fatigue with commercial operating systems that enforce invasive telemetry and proprietary cloud AI features. Highlighting how Fedora enables private, offline LLM inference with zero data leakage resonated powerfully.
2. Students on a Budget: CSULB students loved seeing how Linux can revive older, restricted hardware to deliver a capable, subscription-free AI workspace without requiring expensive cloud API tokens.

4. Advice & Lessons for Future Event Owners

If you are planning to organize a small event (under $150) or booth presence in the next six months, here are four practical takeaways from our experience:

1. Design 100% Offline Demos: Campus and conference Wi-Fi networks are notoriously unreliable, firewalled, or slow. Designing our demo to run entirely inside local Podman containers without requiring an internet connection kept our booth fully functional all day without friction.
2. Account for Outdoor Environmental Factors: Our booth was located in an outdoor expo space. During the afternoon peak heat, direct sunlight caused our demo laptop to heat up, requiring us to tuck it under banners in the shade. Recommendation: Always confirm booth coverage in advance, and pack brimmed hats, pop-up shade, or cooling accessories if outdoor placement is unavoidable.
3. The Power of the Daily User Perspective: You do not need to be a kernel developer or upstream maintainer to staff a Fedora booth. Sharing how you use Fedora day-to-day for work, study, or home projects alleviates "imposter syndrome" and provides relatable, authentic guidance that newcomers appreciate.
4. Keep Swag Requests Lean on Short Timelines: Because our event planning window was short, we kept our Forgejo Mindshare swag request focused strictly on high-impact essentials: stickers, case badges, and pens. Podman and Fedora logo stickers drew in decision-makers and students alike.

5. Next Steps & Wrap-Up

We would like to thank Patrick Finie, Drew Adams, and the openSUSE community for partnering with us, as well as the CSULB organizers for putting together a fantastic event.

Following Data Con LA, our team of Ambassadors Perry Rivera and Rob McBryde are incorporating these lessons directly into the new Small Events Standard Operating Procedure (SOP) and preparing for upcoming community participation at SCaLE. Our intention is to share and publish this information in the Fedora Docs website so that other event owners in the Fedora community may benefit from common wisdom from others who have done this work before.

• Want to get involved? Connect with us on Fedora Discussion or drop by the #ambassadors:fedoraproject.org Matrix channel!

The post Fedora at Data Con LA 2026: Open Source & Local AI appeared first on Fedora Community Blog.

17 Sep 2026 12:00pm GMT

This isn't an "actions speak louder than words" sort of post, although I suppose they're related thoughts. It's more about the idea that whatever you support trumps what you intended to support. It's more of an XKCD #1172 post.

On a mailing list I'm on, there was recently a thread about NOAA preparing to retire a satellite-based data transmission service called NOAAport. One person wrote:

But what I think people are missing is NOAAPort was never truly designed to serve anyone outside of NOAA. It is a service by NOAA, for NOAA, that we were lucky enough to be able to tap into because it was clear-air transmission.

Another participant responded:

Whatever its original design motivation, NOAA has knowingly operated NOAAPORT for decades as a primary public dissemination mechanism. Entire academic, commercial, emergency-management, broadcast, and value-added ecosystems were built around that availability with NOAA's knowledge and participation. After decades, its actual role matters significantly more than the original design intent.

This is an important lesson for maintaining an open source project. Whether it's a feature in the software or a service you provide, once it's there, people will expect it to remain there.

If you say a particular feature or configuration is unsupported, but then you start supporting it, it's now supported. You're allowed to change your mind, of course. You can start out not intending to support something and then later decide to do it. But if you claim you're not and you do, then you are.

This means that if you decide you're not going to support something, then you have to continue to say "no" to it whenever it comes up. Saying "no" is one of the harder things we have to do, so it's good to remind ourselves sometimes.

This post's featured photo by Maayan Nemanov on Unsplash.

The post What you do matters more than what you intended appeared first on Duck Alignment Academy.

17 Sep 2026 12:00pm GMT

17 Sep 2026 11:50am GMT

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!

16 Sep 2026 8:00am GMT

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:

• (CVE-2026-91837) network-manager-iodine: Option confusion reaches iodine's pre-drop root shell
• (CVE-2026-91838) network-manager-sstp profile data reaches root pppd pty shell
• (CVE-2026-91839) NetworkManager-fortisslvpn credential newline injection permits local root code execution
• (CVE-2026-91840) NetworkManager-vpnc: Top-level VPN username newline injection reaches a root password helper
• (CVE-2026-91841) NetworkManager-vpnc: Incomplete fix of CVE-2018-10900

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.

15 Sep 2026 4:26pm GMT