Fedora People

Rajeesh KV: ICFK 2026: Calligraphy Festival

2026-10-12T11:58:38+00:00

This year’s edition of International Calligraphy Festival Keralam was yet another great experience, consisting of workshops, demonstrations and talks surrounding calligraphy & typography, much like the last time. Eminent calligraphers of about a dozen scripts shared their expertise and experience.

Pictures of a sample collection of the calligraphy works at the exhibition below.

For my talk, I presented the historical evolution of Malayalam script from rock inscriptions to the digital age, and how the vigilant volunteer community reclaimed the script with its rich conjuncts and conjoined reph/matra shapes, and made all the foundational digital technologies openly available for public good.

The video recording of the talk is available.

Many type designers, companies and enthusiasts were also at the 4-day programme, enabling lot of productive hallway talks as well. A recurring question was the usage of Open Font License, which I hope to have helped to clarify.

The most useful feedback after the talk came from a good friend, who pointed that my slides didn’t do enough justice to the body of work we’ve done (particularly as open-source); and helped me walk through some possible improvements. I did make some of those changes, and the slides (created using TeX) are made available.

rajeesh-kachatathapa-2026 Download

Miroslav Vadkerti: Keeping secrets out of my AI agents

2026-10-12T00:00:00+00:00

Guillaume Kulakowski: SeedboxSync v4.3 : Bootstrap, UI repensé, widget Homepage et correctifs majeurs

2026-10-11T16:26:41+00:00

Guillaume Kulakowski: Migration vers Fedora 45 Bêta : mon retour d’expérience sur mon laptop Asus

2026-10-10T13:33:57+00:00

Akashdeep Dhar: Maintainer Summit - IndiaFOSS 2026

2026-10-09T18:30:25+00:00

Theme

Experience

Marking the second Indian FOSS event for me, day zero of IndiaFOSS 2026 by FOSSUnited Organization had the Maintainer Summit planned for it. This had a separate registration apart from the main conference and hence had a smaller footfall at Samagata Foundation. As the invitation email required us attendees to be at the venue at 0900am Indian Standard Time sharp, I decided to get a head start to beat the Bengaluru traffic on Friday, 25th September 2026. As I had my hotel check-in later on that day, I also had to make a brief stop at SRS Springs And Spa Hotel to leave my luggage before finally making it to the event venue. Leaving on an Uber ride at around 0730am Indian Standard Time from Yelahanka Crossing, I surprisingly witnessed much lighter morning traffic than I expected while heading from the outskirts into the metaphoric heart of Bengaluru city.

Simply put, I seemed to have greatly overestimated the traffic situation. Or maybe it was the Friday morning doing wonders. I was able to reach the first stop by around 0815am Indian Standard Time, giving me roughly 45 minutes to cover the next distance. Leaving my check-in luggage with the trusty receptionist of SRS Springs and Spa Hotel, I chatted with the fellow members on the event's official Telegram group until I reached my stop. I was almost certain that I was one of the first folks to make it to Samagata Foundation, after being helped by Ansh Arora in navigating the sprawling center. While Rajan Shah assured me of his availability, he also mentioned that he would join later with Veer Kumar Patil, Shivraj Patil, Deepesh Nair, and Gaurav Kamathe. That not only meant that I was on my own there but also that I had a great opportunity to make some new Fedora friends too!

Manifest A

With the attendees slowly rolling in and leaving their stickers on the swag desk, I made it a point to hand out the Fedora Project round badge / magnet combo to folks I had conversations with. This helped me manage the limited swag inventory wisely while keeping me on my toes to seek out new conversations to be a part of. Many of these FOSS friends were either already aware of the Fedora Project and or were using Fedora Linux, which made it a lot easier for me to seek out possible contributors among the prolific crowd of FOSS maintainers. One such chat that made a lasting, mutually beneficial impact was with the Tangled Project members, who wanted to learn about my progress with the migration from Pagure to Forgejo within the Fedora Project community. We shared our frustrations with the various Git hosting services while we waited for the event organizers to arrive there.

While Forgejo was a fork of Gitea, which itself was a fork of Gogs, Tangled seemed to be built from the ground up and was an interesting external case study to learn features from as we were contributing to the Forgejo upstream. With various other chats on knowledge, localization, programming and community with maintainers, I also ran into people who recognized me instantly from my previous adventures earlier that year in DevConf.IN 2026 and FOSSAsia 2026. As an elected Fedora Mindshare representative who was also a part of the Fedora Council then, this sign meant that our efforts with establishing regional community presence in the APAC region were clearly working. All we had to do was continue doing just that in order to help the adoption of Fedora Linux among users and awareness of the Fedora Project among enthusiasts in a region which was largely ignored until 2025–2026.

Manifest B

Ansh kicked off the unconference-styled Maintainer Summit's event proceedings with his opening note as we gathered at the whiteboard with our sticky notes to propose things that we wanted to discuss. We had varying degrees of success with the instruments like the sticky notes and markers, but it was hilarious to see just how many maintainers it took to redo the entire board with thumbtacks and a stick board. After proposing Contributor Retention in FOSS Communities, I decided to hang back and help out the fellow organizers. In our passing chats, I could not help but notice a healthy skepticism about using generative tooling along with an overriding enthusiasm for where the technology was headed. I, however, did find myself being psychologically alienated from chats that were bordering on virtue signaling about the general utilization of artificial intelligence-based technologies.

In the times when conversations on artificial intelligence were just unavoidable, I wanted to spend more effort exploring how the technology could be evolved more instead of debating its usage prescriptions. I loved just how the event attendees were a healthy mix of technical individuals and non-technical enthusiasts, both of them desiring to understand the core requirements of the other persona. For the first part, I decided to join the contemporary Git Hosting discussion chaired by the Tangled Project contributing maintainers, along with Veer Kumar and Gaurav, who had arrived at the event venue by then. It felt great to meet up with them at yet another APAC conference, along with Rajan, Deepesh and Shivraj, after our last meetings at DevConf.IN 2026 and FOSSAsia 2026, especially with Rajan also standing for the FOSSUnited Organization governing body elections at that time.

Manifest C

Joining in the maintainer discussions around semantic diffs in various Git hosting services and the general need for workflow evolution, I was genuinely surprised to see just how other maintainers faced the same problems that the Fedora Project had been facing for many years. We passed around a smartphone (to act as a mic) in our small groups as we took turns with what we had to say. As the review system had more or less remained the same for a decade now, I stressed how crucial it had become for the various Git hosting services to use generative tooling to provide semantic diffs in order to help streamline collaboration among maintainers and contributors. We reflected upon and agreed on how the wider accessibility of generative tooling had already made it increasingly difficult for fellow maintainers to review large volumes of codebase changes within reasonable turnaround times.

As time passed by, I was surprised to see just how much my proposed topic on Contributor Retention in FOSS Communities amassed supporting sticky notes. All the support my topic ended up getting moved us from a corner area to the center of the conference. Since it was scheduled for 1200pm Indian Standard Time, Rajan and I briefly joined the discussion on India's Digital Personal Data Protection Act and how it compared with Europe's General Data Protection Regulation Act. Apart from the comparisons, we also delved deeper into the maintainer's responsibilities with data protection and how the policy required general awareness for effective enforcement. Touching on the related topics of Europe's Cyber Resilience Act and the United States' Federal Risk and Authorization Management Program, we also distinguished between the roles of software authors and service administrators.

Manifest D

Exploring the frequent Aadhaar data leaks, we reflected on just how important it is for citizens to hold the policymakers accountable for these. While a CRA analogue for India would take a while to come into being, we discussed the best practices for FOSS maintainers to ensure preliminary data safety at their ends on an architectural level. Various case studies were brought up where data security and policy validation were seen as a chore rather than a fundamental responsibility—an observation that I vocally protested about, as a similar attitude towards privacy is what empowers bad actors to discover loopholes in a security policy. Finishing off with this discussion paved the way for the one added by me, and I soon found myself arranging the chairs while preparing for the attendees to arrive. Even when we started off with just five folks, we quickly ballooned to over twenty in no time.

With almost one-third of the unconference population at our discussion, I started off the discussion at around 1215pm Indian Standard Time. We went around the attendees—both technical and managerial in nature—to explore their onboarding experiences from their communities. I was interested to know how the interactions with first-time newcoming contributors went and what made them feel like staying back in a community after their first contribution activity was completed. Gaurav gracefully allowed his iPhone to be used as a mic, and amidst various experiences, I shared a demo of how we incentivized contributions in the Fedora Project with the use of the Fedora Badges platform. As a solution that scaled pretty well across various-sized FOSS communities, they appreciated how this solution could help immensely when shipping swag or attending events could be very difficult.

Manifest E

I appreciated how grounded the conversation was, with people realizing that most of the time, people simply appreciate it if their activities are reviewed in time and not left in a metaphoric limbo. While artificial intelligence-based generative tools ensured that the entry barrier was lowered, to the point that even bad actors went on with spamming activities, we also reflected on just how it was hurting the fellow maintainers. Even Ansh could not help joining in on the chat with his experiences while we were waiting for lunch, and at around 0115pm Indian Standard Time, we were finally done with the first half of the day. Joining a queue a little later with my Red Hat friends, I got myself some plain and simple Indian meal with chapatis, pulses, rice, vegetables and sweets. I loved how the healthy lunch represented the Indian hospitality of the unconference event, much akin to FOSSAsia 2026's food.

Hanging out with the likes of Darsh Shah and Shrirang Kahale during lunch, Deepesh showcased his solar-powered self-hosting homelab. We were pleasantly surprised to learn how Shrirang ran eight GNU/Linux mirrors across the country, all while being in his second year of engineering study. With the Red Hat friends leaving at around 0230pm Indian Standard Time after the mealtime discussions, I hung back to see which chats I wanted to be a part of. After briefly joining the one run by the FOSS maintainers from the Wikimedia Foundation, I had a fairly good and engaging discussion around the usage of artificial intelligence for the starter template before ensuring a human review. My analogue to the healthy skepticism was to utilize generative tooling to fill metaphoric potholes on a figurative road created by humans, and avoid doing things the other way around, if possible.

Manifest F

Plagued by the experiences of LLMs basing their output on citations and resources that most likely do not exist, we reflected on the potential stress on reviewers using human time and effort on them. Observing the growing virtue-signaling around artificial intelligence technologies again, I silently resigned myself to calling it a day at around 0400pm Indian Standard Time. Shrirang and I had some Samosas, and after bidding farewell to Poruri Sai Rahul and Ansh, we decided to depart on an Uber ride waiting for us. As much as I wanted to stay back until the evening for the full-course Maintainer Summit event experience, I knew I had other important things to take care of. Not only did I have to check into the hotel after collecting my luggage from the reception, but I also had to prepare for the first day of IndiaFOSS 2026 to represent the Fedora Project alongside our fellow Red Hat associates.

Remi Collet: 🎲 PHP version 8.4.27RC1 and 8.5.12RC1

2026-10-09T05:00:00+00:00

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.12RC1 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.27RC1 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.12RC1 is in Fedora rawhide for QA
Version 8.6.0RC3 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)

Remi Collet: 🎲 PHP on the road to the 8.6.0 release

2026-09-30T06:08:00+00:00

Version 8.6.0 Release Candidate 2 has been released. It's now entering the stabilisation phase for the developers, and the test phase for the users.

RPMs are available in the php:remi-8.6 stream for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) and as Software Collection in the remi-safe repository (or remi for Fedora)

⚠️ The repository provides development versions which are not suitable for production usage.

Also read: PHP 8.6 as Software Collection

ℹ️ Installation : follow the Wizard instructions.

Replacement of default PHP by version 8.6 installation, module way (simplest way):

Using dnf 4 on Enterprise Linux

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

Using dnf 5 on Fedora

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

Parallel installation of version 8.6 as Software Collection (recommended for tests):

dnf install php86

⚠️ To be noticed :

EL-10 RPMs are built using RHEL-10.2
EL9 rpm are build using RHEL-9.8
EL8 rpm are build using RHEL-8.10
lot of extensions are also available, see the PHP extension RPM status page and PHP version 8.6 tracker
follow the comments on this page for update until final version
will be proposed as a Fedora 46 change

ℹ️ Information, read:

Base packages (php)

Software Collections (php86)

Christof Damian: Friday Links 26-31

2026-10-08T22:00:00+00:00

Kamil Páral: Heroes of Fedora Quality for Q3 2026

2026-10-08T13:28:54+00:00

The third quarter of 2026 is over, and so in this post we’d like to highlight the top Fedora Quality contributors who helped us maintain the quality bar for Fedora during this time period. Fedora wouldn’t be a high-quality distribution without its community. Every single person who helped us detect and resolve issues, or verify that things work as expected, deserves our gratitude, thank you!

If you haven’t participated yet in testing Fedora, perhaps you’d like to give it a try? We gladly welcome everyone. Please look at our Fedora Quality homepage.

Testing proposed updates

When software packages are updated in Fedora (bringing bug fixes and new features), they are not released to end users immediately. They first go to the updates-testing repository, where they undergo automated testing, and also await manual feedback from human testers. This feedback can be provided through Bodhi, either by using its web interface or CLI tools, see instructions. Alerting package maintainers by posting a negative feedback with a problem description can stop the update from reaching general audience and causing issues to all our users. Testing proposed updates is a simple, yet vital process for keeping Fedora releases of high quality during their whole lifecycle. It is used both for already stable and in-development Fedora releases.

Test period: Q3 2026 (2026-07-01 – 2026-09-30)
Contributors: 414
Updates commented¹: 8077

Name	Updates commented
Geraldo S. Simião Kutz (geraldosimiao)	1526
Ephraim Kaov (ephmo)	1370
Derek Enz (derekenz)	1332
Filipe Rosset (filiperosset)	772
besser82	423
bojan	260
Ian Laurie (nixuser)	210
Eugene Mah (imabug)	163
anotheruser	154
Colin Thomson (g6avk)	111
Joe Ant (maketopsite)	92
Adam Williamson (adamwill)	82
markec	78
Wasser Mai (wasser19641)	69
František Zatloukal (frantisekz)	61
Lukáš Růžička (lruzicka)	50
Benjamin Beasley (music)	48
brett h (bretth)	33
Fabio Valentini (decathorpe)	31
Kamil Páral (kparal)	28
Nils Philippsen (nphilipp)	27
Neal Gompa (ngompa)	24
Alex Gurenko (agurenko)	24
Steve Cossette (farchord)	21
itrymybest80	21
Neeraj Kumar (rai510)	17
xvitaly	16
Gilbert Fernandes (gilbert-fernandes)	16
Peter Robinson (pbrobinson)	16
Juha Uotila (inffy)	14
Arek Rasialdo (frosth)	14
John Howard (johnh99)	14
Michel Lind (salimma)	14
Gilles Duboscq (gilwooden)	14
M K (marok)	13
Patty Berge (thetick)	13
Simon de Vlieger (supakeen)	12
Petr Pisar (ppisar)	12
Aditya Kumar (adityakr)	11
Carl George (carlwgeorge)	11
Irina Gulina (igulina)	11
Gordon Lühders (gordon26)	11
lakhsa	11
Shawn Dunn (sfaulken)	10
Christopher Klooz (py0xc3)	10
Travis Swanson (alphamale)	10
Zdeněk Žamberský (zzambers)	10
Eden Uhde (edenariel)	10
…and also 366 other testers who commented on less than 10 updates each, but submitted 777 comments combined!

¹ If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.

Test days participation

Test Days are events which are partly focused on testing Changes planned for an upcoming Fedora release, but they also regularly test important areas of the Fedora distribution, like upgrades, internationalization, graphical drivers, desktop environments, kernel updates, and others. The upcoming and past events can be seen in our Testdays app.

Test period: Q3 2026 (2026-07-01 – 2026-09-30)
Contributors: 67
Test cases executed: 598

Name	Test cases executed
tagoh	36
derekenz	28
ephmo	28
mcrha	23
pnemade	22
smjagtap	22
adriend	22
clnetbox	21
romeo-55	20
pschindl	19
toodz89	19
psklenar	17
modehnal	16
oholy	15
axelzenzu	14
pacorro2000	14
lruzicka	14
vcholasta	14
developer1	13
feborges	12
romangherta	12
vhumpa	12
jgrulich	12
mtadault	11
luya	9
geraldosimiao	9
bohdan_milar	7
lpavan	7
ersen	7
pyadav	7
jandemus	7
abdallahleandro	7
panayang	7
vlcekpavel93	6
nielsenb	6
imabug	6
tharadash	6
guiltydoggy	6
jgroman	6
kengou	5
kanru	5
rvykydal	5

…and also 25 other testers who executed less than 5 test cases each, but submitted 44 test results combined!

We sincerely thank all contributors!

Are you also interested to help? Please look at our Fedora Quality homepage.

Fedora Magazine: Podman Test Week: Help test the Rust-based conmon v3

2026-10-07T16:25:50+00:00

The Podman and Fedora Quality teams are organizing a test week from Monday, October 12, through Sunday, October 18, 2026. We want your help testing conmon v3, the Rust-based container monitor used with Podman. If you use Podman, try the same containers and commands with conmon v3 and report any differences.

Why we’re testing conmon v3

Conmon is the small process that keeps watching a container after the Podman command that started it has finished. Podman uses an OCI runtime such as crun or runc to start the container; conmon attaches to its input and output, provides the connection for podman attach, collects logs, and records its exit status.

Conmon v3 replaces the C implementation with a Rust version. This helps prevent common memory errors in safe code. It also gives the logging backends a shared interface, making them easier to extend and test.

We already run Podman’s system tests against conmon v3. Now we’d like help checking development containers, interactive sessions, and Quadlet services on other people’s setups.

Getting started

We’ve prepared a test week wiki page with setup instructions, links to the test cases, and information on reporting results. Start there to check the Fedora and package requirements, then use a test machine or VM with no important data.

Install the new monitor with this command:

sudo dnf install conmon-v3

To select it system-wide, create /etc/containers/containers.conf.d/99-conmon-v3.conf with the following content:

 [engine]
 conmon_path = ["/usr/bin/conmon-v3"]

Run podman info and check that the conmon path is /usr/bin/conmon-v3 and its version starts with 3. If you use both rootless and rootful Podman, check sudo podman info as well. User configuration can override the system setting.

Start new test containers after making this change. Containers that are already running retain their existing monitor.

To switch back after testing, remove the drop-in. New containers will then use your previous configuration.

What to test

Here are the areas we’d particularly like you to check:

Open an interactive shell, resize the terminal, and detach and attach again.
Run podman exec, including interactive commands, and check the output and exit status.
Check file and journald logs with large output and lines without a final newline.
Start, stop, and restart containers, including services managed by Quadlet or systemd.
Try rootless or rootful Podman, and crun or runc where available.

Watch for hangs, missing output, incorrect exit statuses, unexpected CPU usage, or behaviour that differs from conmon v2. The wiki links to the test cases, which include the conmon-specific checks.

Results and help

Record your results in the test day application. Please record successful tests too. They tell us which setups have been checked.

Report conmon problems in the conmon v3 issue tracker. For other Podman issues, follow the bug-reporting instructions on the wiki page. Include your Fedora version, relevant package versions, reproduction steps, relevant logs, and the output of this command:

podman info --debug

Link the bug report when submitting your test result.

For help with testing or reporting a problem, join us on Matrix in #podman:fedoraproject.org.

This article was co-written by Petr Sklenar and Jan Kaluza.

Note about AI usage: : The core technical content and claims are completely our own. Claude (Anthropic) was used only as an editing tool to enhance grammar and readability.

Peter Czanik: Using syslog-ng with OpenSearch 3.9

2026-10-06T14:07:57+00:00

Guillaume Kulakowski: Maîtriser mes données de poids : la synchronisation sur mesure

2026-10-05T18:24:59+00:00

Aurélien Bompard: From September 28 to October 04

2026-10-05T09:38:00+00:00

Across the Fedora ecosystem this week, groups are heavily focused on stabilizing the upcoming Fedora 45 release, with teams like Quality, Release Engineering, and Workstation actively coordinating blocker reviews, test weeks, and freeze exceptions. Another major common thread is the ongoing modernization of project infrastructure, particularly the transition toward Forgejo—guided by the Council's newly approved Fedora Forge Usage Policy—and the strategic workflow planning for Red Hat's upcoming Bugzilla sunset, which is actively impacting discussions within EPEL and Design. Finally, navigating the integration of Artificial Intelligence has become a prominent focal point; the newly rebranded Fedora AI Working Group is establishing formal AI assistance disclosure policies, while several groups including Fedora Join, Diversity & Inclusion, and CoreOS are actively debating data privacy and opt-in boundaries regarding the collection of their communications for this report.

Announcements

The Fedora QA team is calling for community participation in the Anaconda F45 features Test Week, running through October 2, 2026. This is a highly focused opportunity for contributors to help shape the upcoming Fedora 45 installer by testing significant new capabilities, ensuring a smooth transition and avoiding disruptive surprises upon release. Key features needing real-world virtual or bare-metal testing include the modern WebUI for Atomic Desktops, browser-based remote installation support, and integrated Stratis storage configuration.

In broader ecosystem news, the Fedora Project recently supported a highly successful Software Freedom Day Bukidnon 2026 in the Philippines, bringing together students, educators, and professionals to celebrate open-source innovation with sessions ranging from automotive Linux to running local AI models. Meanwhile, on the technical discussion front, contributors are actively sharing best practices for installing the Navidrome music server on Fedora using Podman. Recent forum activity highlights how to optimize the setup using native systemd container files, rootless user namespaces, and automatic SELinux context tagging, providing a more robust, Fedora-native alternative to standard Docker configurations.

Council

During this period, the Council primarily focused on establishing clear governance for core project infrastructure and ensuring the continuity of Fedora's external partnerships. A key theme across both tickets was formalizing responsibilities and defining clear boundaries for project resources to maintain a sustainable ecosystem for all contributors.

Notably, the group concluded voting on the comprehensive usage policy for the Fedora Forge and successfully coordinated a transition plan for Fedora's ongoing representation in the global Digital Public Goods Alliance (DPGA).

Decisions

Approved the new Fedora Forge Usage Policy by an 8-0 vote. This significantly affects the broader community by restricting the Forgejo instance strictly to Fedora-related work rather than serving as a general-purpose host. The policy mandates FAS authentication, establishes a soft repository size limit of 500MB, enforces a 10-minute timeout for shared CI runners, and outlines a formal exception process for ecosystem upstreams.
Decided (by a 9-0 vote) to transition the responsibility of representing Fedora in the Digital Public Goods Alliance (DPGA) away from the Fedora Community Architect role. The Council agreed to formally request that the Fedora Mindshare Committee assume this long-term relationship, while immediate 2026 renewal tasks will be handled by current members. Documented in Issue 576.

Learn more about the Council team.

FESCo

This week, FESCo held one meeting but did not reach quorum, deferring formal votes. The committee briefly discussed the Forge Usage Policy and the process for appointing a new member. In the issue trackers, FESCo debated Koji build performance expectations for secondary architectures, analyzed requirements for the upcoming Bugzilla replacement, and tracked incomplete Fedora 45 Changes. Additionally, three new Change proposals (Crystal Language, Thin LTO Build Flag, and Libical4) were opened for voting, and community members discussed a proposal to preserve Git-derived modification timestamps for source packages.

Decisions

Processed a non-responsive maintainer ticket, transferring ownership of actively maintained packages to new volunteers and orphaning the remainder.
Authorized the retirement of the NetworkManager-vpnc and NetworkManager-fortisslvpn packages, intentionally using Obsoletes in the main NetworkManager package to forcefully uninstall them from user systems due to a critical privilege escalation vulnerability.
Resolved the issue of kmscon breaking certain display managers after a workaround was pushed to stable for lightdm, noting that similar issues in other display managers should be handled as normal bugs.
Confirmed the completion of the 'Filter Fedora Flatpaks for Atomic Desktop v2' Change and formally retargeted the 'Disable Vendor Change by Default' Change to Fedora 46.

Learn more about the FESCo team.

Packaging Committee

During its weekly meeting, the Packaging Committee processed multiple routine documentation updates and engaged in a lengthy discussion regarding a major simplification of snapshot versioning. Several minor updates concerning Emacs packaging and documentation restructuring were successfully merged.

The most significant ongoing topic is issue #1570, which proposes standardizing snapshot versioning to a single <number>.<revision> format to reduce complexities that have historically caused upgrade path breakages for packagers. While initial meeting votes favored the simplification, formal voting is continuing on the ticket to ensure the required committee majority is met.

Decisions

Adopted a new fast-track rule allowing trivial or non-controversial pull requests to be merged before the next meeting if they receive two FPC member approvals.
Approved and merged issue #1573 to move legacy complex versioning instructions into a separate versioning appendix page, streamlining the main versioning guidelines.
Approved and merged issue #1574 to clarify that references to Emacs compilation in the guidelines specifically mean byte compilation.
Approved and merged issue #1575 to reflect that the Pure GTK Emacs build is now provided by the emacs-pgtk package.
Closed issue #1576 regarding the deprecation of the Group tag.

Learn more about the Packaging Committee team.

Mindshare

This week, Mindshare celebrated successful community events, reviewing reports and finalizing logistics for IndiaFOSS 2026, Data Con LA 2026, and Software Freedom Day Bukidnon 2026. Driven by the success of APAC events, the committee resolved to create a dedicated event box stationed at the Red Hat Pune office to streamline regional swag distribution and significantly reduce international shipping costs for local organizers.

Governance and activity levels were also a major focus, prompted by Ticket #153. To address recent delays in ticket triage and ongoing vacant representative seats (such as Comm Ops and Marketing), the committee discussed modifying its rules to formally reallocate representation to more active sub-teams, ensuring consistent and timely support for contributors and organizers across the broader Linux community.

Decisions

Agreed to establish a new Fedora event box based in the Red Hat Pune office to better serve the APAC region without the prohibitive costs of international shipping from the US or EU. (Mindshare Meeting)
Initiated a process to review and potentially change Mindshare representation rules, aiming to replace statically designated seats (like Comm Ops and Marketing) with flexible seats assigned annually to the most active community subgroups. (Mindshare Meeting)

Contribution opportunities

Mindshare is seeking contributors to get involved with AI, documentation, and moderation efforts, providing opportunities for active individuals to eventually step into committee representative roles. (Ticket #153)
Local event organizers in the Philippines (such as those behind SFD Bukidnon) are actively looking for resident Fedora Ambassadors to partner with for future open-source events. (Ticket #146)

Learn more about the Mindshare team.

Fedora Join

This week, the Fedora Join group welcomed two new contributors who introduced themselves via the forum and the mailing list, expressing interest in Docs, Python, and infrastructure. In the issue tracker, the group actively collaborated on shaping the new contributor experience by providing feedback for the Fedora Docs front page.

Additionally, the group approved the collection of their public activity for this report, explicitly exempting their Matrix chat to preserve a relaxed environment for newcomers. Work also began on auditing and updating the Fedora Apps directory.

Decisions

The group decided to permit the collection of their mailing list, Discourse, and issue tracker data for the This Week in Fedora report, but explicitly excluded the Join Matrix channel from being scraped in order to protect it as an informal, friendly space for new members.

Contribution opportunities

The Fedora Docs team is seeking time-sensitive feedback on adding a "Contribution" section to the Docs homepage. They are looking for ideas on which topics, SIGs, and non-technical contributions to highlight to attract newcomers.
Exploratory work has started to update apps.fedoraproject.org. While a contributor has been assigned, the issue highlights ongoing infrastructure needs such as reviewing current web apps, finding unlisted services, and updating software stacks.

Learn more about the Fedora Join team.

Ambassadors

Planning for FOSDEM 2027 has officially begun, with Justin Wheeler and Daniel Mellado acting as event co-owners for Fedora. Applications for a Fedora stand and the Distributions DevRoom have already been submitted. Additionally, organizers are currently negotiating a single, larger hotel block for Fedora and CentOS contributors at the DoubleTree by Hilton Brussels City.

Decisions

Applications for a Fedora stand and the Distributions DevRoom at FOSDEM 2027 have been officially submitted.
A single, shared hotel block at the DoubleTree by Hilton Brussels City is being negotiated for Fedora and CentOS contributors attending FOSDEM 2027.

Contribution opportunities

Contributors planning to attend FOSDEM 2027 are encouraged to monitor the mailing list and wiki for upcoming details on booking rooms within the Fedora and CentOS hotel block.
Community members with questions or ideas about the event are invited to engage with the organizers by replying directly to the mailing list thread.

Learn more about the Ambassadors team.

Diversity & Inclusion

This week, the Diversity & Inclusion team resolved a discussion regarding the automated collection of group data for this weekly report. The team evaluated which communication platforms should be included in the data ingestion.

They concluded that while indexing asynchronous platforms like Discourse and the issue tracker is acceptable, the Matrix chat room should be excluded. This decision was made to ensure the chat remains a safe space for discussing sensitive and evolving topics without the risk of incomplete thoughts being broadcasted broadly.

Learn more about the Diversity & Inclusion team.

Workstation / GNOME

This week, the Workstation / GNOME group prepared for the upcoming Fedora 45 release by organizing Blocker Review Meetings to evaluate blocker bugs and freeze exceptions. On the issue tracker, members discussed a proposal to add LiveFaceSwap Desktop to Fedora's third-party software repositories and reviewed a request to include the group's communication channels in this weekly report.

Additionally, the group continued discussions on the need to automatically update the appstream-data package to ensure modern software store GUIs like GNOME Software and KDE Discover have up-to-date metadata. A community member volunteered to look into the current manual data update process to help move the automation effort forward.

Contribution opportunities

Review and vote on proposed blocker bugs and freeze exceptions for the Fedora 45 release using the blockerbugs app prior to the weekly review meetings.

Learn more about the Workstation / GNOME team.

KDE

During the week, the KDE SIG focused on refining the default Fedora KDE Plasma installation and resolving release blockers. A major effort is underway to reduce the default installation footprint by transitioning Akonadi's default backend from MySQL to SQLite. Additionally, the group is modernizing the default application set by swapping out the K3b optical mastering tool in favor of Fedora Media Writer.

The team also investigated and implemented a workaround for a Fedora Kinoite login bug triggered during OS rebases, securing the fix in time for the Fedora 44 Beta. Routine Fedora 45 Blocker Review meetings were scheduled to evaluate and vote on outstanding final blockers and freeze exceptions.

Decisions

Initiated a transition to replace k3b with Fedora Media Writer as the default image writer in the desktop comps (issue #729).
Merged a change to the akonadi-server package alternatives priorities so new installations default to SQLite, while safely preserving the MySQL backend for existing users to avoid disruption (issue #730).
Implemented and deployed a systemd service workaround for missing /etc/shadow entries during Kinoite rebases to unblock the Fedora 44 Beta (issue #684).

Contribution opportunities

Community members are encouraged to vote on proposed blockers and freeze exceptions in the blockerbugs app prior to the weekly Fedora 45 Blocker Review Meetings.
Testing and feedback are needed for developing an automated migration path or user alert strategy for existing Akonadi MySQL users transitioning to SQLite (issue #730).
Developers can contribute to the long-term structural fix for user provisioning in atomic desktops by helping the project move away from nss-altfiles (issue #684).

Learn more about the KDE team.

Server

The Server Working Group focused heavily on Fedora 45 release testing and advancing the Ansible support project this week. Testing of the F45 20261003 build yielded successful results across various installation methods, while a critical blocker involving the Server KVM image and initial-setup hanging on the serial console was diagnosed and resolved via a patch to the systemd service.

In addition, the group continued to refine its Ansible support strategy. Members are finalizing continuous integration for the fedoraserver.general Ansible collection and are preparing to package it for Fedora once published on Ansible Galaxy. The group also discussed outreach strategies for upcoming conferences, such as FOSDEM and the Ohio Linux Fest, and prepared for the upcoming F45 Blocker Review meetings.

Decisions

Decided to restore the quiet-console.conf drop-in lines for initial-setup.service to resolve the Server KVM image boot issue on serial consoles (Ticket #216).
Agreed to develop a "turnkey solution" to simplify Ansible usage for end-users, consisting of a core fedoraserver.general collection to be published on Ansible Galaxy and a secondary management wrapper package (Ticket #194).
Decided that Fedora 45 RC testing must be divided among working group members and completed within 1–2 days of a test release's availability (Meeting 2026-09-30).
Decided to follow the US schedule for the upcoming winter time switch for meeting times (Meeting 2026-09-30).

Contribution opportunities

Emmanuel Seyman requested testing for the experimental Wildfly RPMs available in their Copr repository before submitting them to Fedora proper (Meeting 2026-09-30).
The group is seeking volunteers to help test the upcoming Fedora 45 Release Candidates, specifically requesting assistance with the default partitioning and remote install tests (Meeting 2026-09-30).

Learn more about the Server team.

Infrastructure

The Infrastructure group focused heavily on system maintenance this week, successfully executing a major planned outage to apply package updates, perform firmware upgrades, enable SecureBoot on x86 bare-metal hosts, and migrate several backend databases (including Koji and Datanommer). The team also actively troubleshot various access and system issues, such as clarifying that hardware security keys (ed25519-sk) will fail against legacy RHEL 8 systems, and resolving a configuration error that caused 403 errors on www.fedoraproject.org due to aggressive anti-scraper rules.

Additionally, the Forgejo migration continues to make progress, with MultiVM runnerhost support implemented on the distgit-staging environment. The team is also beginning a formal investigation to document workflow impacts and tooling requirements ahead of Red Hat's planned Bugzilla sunset and the proposed move to Forgejo.

Decisions

The team confirmed that hardware-backed SSH keys (id_ed25519_sk) will remain unsupported on pkgs.fedoraproject.org. The server runs RHEL 8, which lacks the required OpenSSH 8.2+ package, and the team decided not to risk uplifting the OS or maintaining a custom OpenSSH fork prior to the upcoming Forgejo migration.
Scraper-blocking rules that inadvertently returned 403 errors on www.fedoraproject.org have been narrowed in scope to only protect the wiki. This ensures regular users routed by search engines can view the site normally, and the www alias will now redirect 301 to the apex domain.
The sysadmin-eln group has been granted permissions to execute the elnbuildsync.yml Ansible playbook on batcave, empowering the ELN team to trigger deployments without requiring manual intervention from Infrastructure team members.

Learn more about the Infrastructure team.

Release Engineering

The Release Engineering team focused heavily on stabilizing Fedora 45 ahead of its release, holding multiple blocker review meetings to evaluate and vote on blocker bugs and freeze exceptions. Alongside release preparations, the team addressed several Fedora 46 Rawhide compose breakages, resolving issues related to SELinux policy mismatches during offline labeling, oversized images on aarch64, and missing packages in the f46 tag. Additionally, a new community discussion was opened proposing the preservation of meaningful, per-file modification times for Git-derived source packages (such as linux-firmware) to improve traceability for users.

Decisions

Accepted as a Final Blocker: Bug 2541402 - systemd-imds-early-network.service fails at boot with AVC denials.
Accepted as a Final Blocker: Bug 2537341 - oo7-portal not installed by default after upgrading to F45.
Accepted as a Final Freeze Exception: Bug 2536815 - dnf command not available in kickstart, f45 netboot installer (rejected as a hard blocker).
Accepted as a Final Freeze Exception: Bug 2530897 - F45 grub boot fails with "invalid magic number" when installed to FW RAID multiple times from the GTK installer.
Added Fedora-Server-NetworkInstaller and Fedora-Everything-NetworkInstaller to the f46 tag to fix broken Rawhide composes.
Processed non-responsive maintainers lkundrak and gui1ty, effectively orphaning their unmaintained packages.
Blocked and retired the Charliecloud repository for F46 onward to prevent it from triggering FTBFS errors during mass rebuilds.

Contribution opportunities

Maintainers and community members are invited to provide input on a proposal to preserve meaningful per-file mtimes for Git-derived sources (such as linux-firmware), specifically regarding implementation methods and whether to use Git author or committer dates.
Release Engineering assessment and coordination is requested on the F46 Change: LMDB 1.0 transition ticket to plan side-tag merging and potential rollback procedures before F46 branching.

Learn more about the Release Engineering team.

Quality

The Quality team is heavily focused on Fedora 45 Final release validation and blocker bug reviews. Testing activities are in full swing, with the CoreOS test days concluding and the Anaconda installer features test days (covering WebUI, Remote WebUI, and Stratis support) currently running. Additionally, the team successfully exported the results for the KDE Plasma 6.7 test days and is preparing for upcoming test days focusing on Podman Conmon-v3 and GRUB EFI for Confidential Computing.

In addition to release preparations, the team contributed their workflow requirements for the upcoming Bugzilla sunset and proposed transition to Forgejo, highlighting critical needs like Bodhi integration, anonymous access, and cross-component search capabilities. There is also an ongoing community discussion regarding a proposal to preserve meaningful per-file modification timestamps (mtimes) for Git-derived sources, which could significantly improve the inspectability of packages like linux-firmware.

Decisions

It was decided to downgrade rpmlint spelling errors to warnings rather than turning them off globally across all packages (Ticket #591).
Accepted Bug 2541402 as a Final Blocker due to systemd-imds-early-network.service AVC denials, noting that disabling the service by default would be an acceptable resolution (Blocker Review).
Rejected Bug 2538553 (Czech keyboard layouts) as a final blocker due to the high risk of regressions and because the behavior only triggers on custom configurations rather than the default installer path (Blocker Review).
Rejected Bug 2536815 (dnf not available in kickstart environment) as a Final Blocker, but accepted it as a Freeze Exception (Blocker Review).
The _check_install_source test will no longer look for /tmp/syslog on network installers following the migration to image-builder (Ticket #948).
The Podman Conmon-v3 test day is postponed by one week to 2026-10-12 to allow time for adjustments to a Podman PR (Ticket #941).

Contribution opportunities

Testers are encouraged to participate in the Anaconda installer test days to evaluate WebUI for Atomic desktops, Remote WebUI, and Stratis support.
Community feedback is sought on the proposal to preserve Git-derived per-file mtimes in RPM packages.
A reviewer is needed for a pull request to fmf-tests to update Azure consumer cloud test results to the wiki (requested during the Quality Meeting).
Help is requested to manually test SAS controllers and disks for F45 or to collaborate with the Server SIG for future automated testing (Ticket #946).

Learn more about the Quality team.

Websites and Apps

The Websites and Apps team implemented a clearer visual distinction on the Fedora download pages to highlight release-blocking deliverables. Star icons are now displayed next to images that have passed basic functionality tests performed by the Quality team, helping users identify the most stable and recommended installation options.

Other activities this week included identifying outdated references to Zanata on the Flock Call for Proposals template which need to be removed to avoid unnecessary work for translators. The team also fielded infrastructure meeting reminders and greeted new contributors offering UI/UX and web development help in the Websites chat.

Decisions

A design change is now live on the Fedora download pages adding a star icon and a "Learn More" footnote to all release-blocking deliverables to clarify which images have guaranteed testing from the Fedora Quality team.

Contribution opportunities

Contributors can help clean up outdated CMS templates (such as old Zanata references in the Call for Proposals page) to prevent translators from doing unnecessary work on disabled or obsolete text.
New contributors looking to help with redesigns, UI/UX, bug fixes, or documentation are encouraged to read the room details in the Fedora Websites chat to discover current website projects and needs.

Learn more about the Websites and Apps team.

Design

This week, the Design team focused on creating initial concepts and technical specifications for the new CDUX logo, which will feature a duck incorporating UI elements and the Bezier tool. The team also began planning visual assets for the upcoming F45 Virtual Release Party and committed to providing a higher-resolution SVG Fedora logo for the fedora-logos package. This fix will address pixelation issues on the GDM login screen that occur when fractional scaling is enabled in Fedora 41 and later.

In the Design Matrix chat, team members discussed logo approval for Microsoft Ignite stickers and exchanged ideas with GNOME engagement members regarding Penpot automations and AI-assisted workflows. Finally, congratulations are in order for Emma, who recently began a part-time Masters in Service Design!

Decisions

The Design team is no longer taking Fedora Badge requests in their main ticket queue; these must now be logged directly in the badges queue, which is currently facing a lack of dedicated designers. (Ticket #86)
The official EPEL Steering Committee badge design was approved by the committee, finalized, and successfully published to the badges system. (Ticket #60)
The team approved the inclusion of their public Matrix chat data for the collection of these weekly reports. (Ticket #83)
The team confirmed they have no workflow dependencies on Bugzilla and are completely unaffected by its upcoming sunset, as they exclusively use Forgejo. (Ticket #88)
The upcoming CDUX logo will be designed using simple black line art and solid colors without gradients to guarantee easy CMYK color conversion and sticker production. (Meeting Notes)

Contribution opportunities

Anyone in the Fedora community is welcome and encouraged to contribute sketches and visuals inspired by the mindmap for the upcoming F46 Wallpaper.
The Fedora Community Operations team is seeking design support and visual assets (thumbnails, Matrix room icons, Restream backgrounds) for the Fedora Linux 45 Virtual Release Party happening on October 30, 2026.

Learn more about the Design team.

Docs

This week, the Docs team implemented important changes to standardize contribution workflows. Direct pushes to main and prod branches have been disabled across all docs/* repositories; all contributors must now use forks and pull requests to submit changes. The team is also testing a new real-time collaborative writing tool via a CryptPad instance hosted in CommuniShift.

Additionally, discussions are ongoing regarding structural improvements to the Docs site. This includes evaluating whether to merge Antora components so content from different SIGs can be combined seamlessly, and determining the best way to consolidate scattered multimedia documentation. Finally, the team opted into having the "This Week in Fedora" summary bot monitor their ticket trackers to boost the visibility of their work.

Decisions

Direct pushing to main branches is now disabled across all docs/* repositories. Non-admin contributors must fork the repository and submit a pull request, which now requires at least one approval before merging.
The team agreed to let this weekly report collect the entire Docs organization's ticket trackers rather than summarizing their Matrix alert chat room.

Contribution opportunities

The team is seeking volunteers for the Fedora Docs Captains pilot program to act as documentation liaisons for SIGs like Kernel, Multimedia, and AI/ML.
Contributors are needed to write detailed image descriptions (alt text) for screenshots in the Beginner's Guide to meet accessibility standards.
Help is requested to review, categorize, and organize scattered multimedia documentation across Quick Docs into a unified section.
The team is looking for someone to help configure Zabbix monitoring for OpenShift Docs site builds to automatically track and report failures.

Learn more about the Docs team.

Legal

This week, a question was raised on the legal mailing list regarding the licensing of the Slint UI Framework. A contributor is looking to package the software and asked for clarification on whether utilizing the framework solely under the GPL-3.0-only option of its multi-license scheme is acceptable for Fedora. Additionally, they sought input on how the project's inbound MIT-0 contribution license interacts with its outbound licensing options.

Contribution opportunities

Legal experts and community members can contribute by replying to the licensing inquiry regarding the Slint UI Framework, specifically confirming the viability of using the GPL-3.0-only option for Fedora packaging and explaining the compatibility of its inbound MIT-0 contribution policy.

Learn more about the Legal team.

COPR

Pavel Raiskup announced a planned Fedora Copr outage scheduled for October 1, 2026, at 06:00 UTC, lasting approximately two hours. During this window, build queue processing was paused and the frontend/web UI was unavailable to accept new tasks, though DNF packages and repositories remained accessible.

The purpose of this downtime was to deploy the latest development versions of the copr-* packages to the infrastructure machines, tracked under infrastructure ticket #13597.

Decisions

The Copr team scheduled a two-hour infrastructure outage on October 1, 2026, temporarily halting build queues and web UI access to deploy package updates.
It was decided to keep the Copr download server online during the update so that hosted DNF packages and repositories remained continuously available to external users.

Learn more about the COPR team.

EPEL

The EPEL team discussed the potential sunset of Red Hat's Bugzilla instance and its impact on EPEL's workflows, noting a strong preference for a Fedora Bugzilla instance over Forgejo due to the operational need to transfer issues between components. Maintenance efforts are currently heavily focused on an upcoming Qt6 update in EPEL9 to proactively handle llvm22 changes before the RHEL 9.9 release, alongside various CVE fixes for djvulibre and ffmpeg.

The release engineering team is preparing automation playbooks for koschei minor mass branching and minor EOL processes. They are also actively tracking infrastructure changes for the upcoming EPEL 9.8 archive snapshot and the complex EPEL 10.2 retirement / EPEL 10.3 switch.

Decisions

Due to a lack of maintainer response, proven packager privileges were used to merge a fix for CVE-2025-53367 in djvulibre.

Contribution opportunities

A community member is seeking a sponsor or an existing packager to co-maintain and branch autossh for EPEL 10.
Contributors are needed to bring mailman3 to EPEL 10 to assist Releng with moving mailman to RHEL 10.
Help is requested to get the incus package into EPEL 10 following its 7.0.0 LTS release on Rawhide.
Assistance is needed to backport a fix for an ffmpeg heap-buffer-overflow CVE in EPEL 10 (version 8.1).

Learn more about the EPEL team.

ELN

The ELN SIG held a brief meeting on September 29. The main topic of discussion was a large Architectural Decision Record (ADR) pull request focused on the unification of bootc and CoreOS. Contributors discussed how ELN is envisioned to fit into this new structure as a layer built upon one of the proposed flavors.

Learn more about the ELN team.

Atomic

The Atomic group met to review the first draft of an Architectural Decision Record (ADR 002) proposing a unified strategy for Fedora CoreOS and Atomic. The draft outlines a three-tier architecture (base, flavor, and product) and standardizes on Konflux for image building; it is currently open for community review and feedback.

On the issue tracker, significant attention was given to improving the experience for downstream consumers building derived OCI images. This included discussions on how to handle Fedora trademark compliance (Ticket #125) and exploring ways to publish OCI images without Fedora-specific packages (Ticket #132). Other notable activities included a proposal to ship smartmontools for disk health monitoring (Ticket #135), fixing systemd checks that break the composefs backend (Ticket #133), and addressing package versioning and compose bugs across Fedora 45 and Rawhide.

Decisions

It was decided that official Atomic Desktops images cannot use generic package replacements because Fedora branding is required. To aid downstream users, the team will instead focus on simplifying the package swap process and writing proper rebranding documentation (Ticket #125).

Contribution opportunities

Reviewers and Subject Matter Experts (SMEs) are requested to provide feedback on the draft ADRs for unifying Fedora CoreOS and Atomic.
Help is needed to identify which GUI applications can be included to display SMART data for users across the various desktop environments.
A contributor is requested to submit a Pull Request removing the ConditionPathExists=/run/ostree-booted condition from specific systemd unit files to fix compatibility with the composefs backend.

Learn more about the Atomic team.

CoreOS

The CoreOS team successfully wrapped up the Fedora 45 Test Week, reporting that the F45 release schedule is on track without any failing packages requiring retirement. In infrastructure and pipeline matters, several issues were resolved, including failing kola-azure jobs, an insecureAcceptAnything policy block causing upgrade failures, and Vim installation conflicts on testing-devel. The team is actively investigating a new SELinux denial related to systemd 262 that breaks cloud tests on F45/F46, and working around dead AWS regions that caused garbage-collection job failures.

During their weekly meeting, the group discussed allowing this weekly report to gather data. They opted to pause Matrix channel data collection for the bot until the Fedora Council finalizes a formal opt-in policy, choosing to rely on GitHub repositories and meeting logs in the meantime. Additionally, members agreed to consolidate legacy meetings to improve cross-team collaboration.

Decisions

Merge the legacy CoreOS Wednesday meeting and the legacy bootc Tuesday meeting into a single meeting to encourage cross-pollination between the communities. (Meeting log)
Hold off on allowing LLM bot data collection in the CoreOS Matrix room until the Fedora Council establishes a formal opt-in privacy policy. (Meeting log)

Learn more about the CoreOS team.

IoT

The Fedora IoT Working Group reviewed their release status, noting that the Fedora 45 Beta freeze is complete and the final freeze begins next week. Both stable and Rawhide composes are currently healthy, and contributors are conducting hardware upgrade and installation tests leading into the final freeze.

In addition to routine release management, the team opened investigations into moving toward device-specific ARM images using arm-image-builder, assessing the impact of recent DNF repository path changes on image builds, and establishing a VM-based testing workflow to make hardware testing more accessible. The group also agreed to collaborate with the Fedora RISC-V Working Group to enable IoT support for RISC-V boards.

Decisions

Drop support for Fedora 42 and older releases; any tracker issues related to these versions will be closed. (Meeting Log)
Investigate transitioning from generic images to device-specific ARM images via arm-image-builder and IoT Compose. (Issue #141)
Assess the impact of the new DNF .repo path configuration on bootc and Bootable Image Builder (BIB) workflows. (Issue #140)

Contribution opportunities

Help is needed to run Fedora 45 nightly tests on any available physical hardware (especially aarch64 devices or modern hardware with accelerators like Orin) to assist with the final freeze.
Community members with spare cycles are encouraged to review the Fedora IoT issue tracker to help close or fix open bugs.
Contributors interested in QA can assist in evaluating VM-based hardware testing strategies to better share the validation workload across the team.

Learn more about the IoT team.

ARM

The ARM mailing list received announcements for two Fedora 45 Blocker Review meetings. The first meeting was held on September 28 to review four proposed blockers for the Final release. The second meeting was scheduled for October 5 to evaluate two proposed blockers and two freeze exceptions.

Contribution opportunities

Review and vote on proposed blockers and freeze exceptions for Fedora 45 via the blockerbugs app prior to the review meetings to help shorten the meeting durations.

Learn more about the ARM team.

Cloud

The Cloud group's recent activities focused on refining image configurations to maintain feature parity and security alignment with upstream changes. A new request asks to add the SUSPEND_SAFE_FPR guest OS feature to Google Cloud Platform (GCP) images, specifically those patched for a page_reporting suspend Use-After-Free vulnerability (CVE-2026-74481). Additionally, a proposal was made to include the google-noto-sans-mono-fonts package in Cloud images to ensure the console appearance remains consistent with other Fedora editions following the recent kmscon update.

Contribution opportunities

Provide feedback or assist with adding the SUSPEND_SAFE_FPR tag to GCP images containing the CVE-2026-74481 patch.
Discuss the potential inclusion of google-noto-sans-mono-fonts to ensure consistent console rendering across editions by participating in Issue #448.

Learn more about the Cloud team.

Hummingbird

This week, the Hummingbird community saw ongoing forum discussions following the cancellation of their September meeting. A community member expressed enthusiasm regarding the project's use of superintelligence (SI) and container technology for building packages and customizing bare-metal systems.

Several inquiries were raised during the discussion, particularly regarding whether Fedora users have public access to this SI and any associated costs. The participant also asked about the feasibility of using SI agents to generate, lint, and highly optimize bootable container images—such as pruning irrelevant firmware or unused packages—based on specific hardware descriptions.

Learn more about the Hummingbird team.

Kernel

The Fedora kernel team discussed a proposal to split perf out of the kernel packaging and build it as a standalone package. Proponents noted that a standalone build would reduce BuildRequires (such as Java) for the kernel, lower the barrier to entry for new contributors intimidated by the massive kernel.spec file, and help resolve inconsistencies with perf headers.

However, reviewers raised concerns about the overhead of maintaining two separate packages, the risk of breaking user expectations if the perf version no longer perfectly matches the shipped Fedora kernel, and the potential disruption to vanilla kernel COPR builds that currently catch upstream bugs early. The primary blocker for the proposal is alignment with RHEL.

Contribution opportunities

Contributors interested in the proposal to split perf out of the kernel packaging are welcome to join the effort to draft and submit a Change Proposal for Fedora 46.
Community members and maintainers (specifically perf upstream maintainers) are encouraged to help advocate for this packaging split within RHEL, as their buy-in is a strict prerequisite for the change.

Learn more about the Kernel team.

AI & ML

During the week of September 28 to October 4, 2026, the AI & ML group focused on two major themes: group identity evolution and documentation modernization. The team successfully formalized its evolution into the Fedora AI Working Group (WG), reflecting a broader scope that encompasses both technical hardware enablement and community stewardship of open AI best practices.

On the documentation front, the group merged new issue templates that introduce lightweight bug reporting, structured content proposals, and a mandatory AI assistance disclosure checkbox. Furthermore, an active proposal was opened to migrate comprehensive packaging workflows and AI reference material from the legacy Fedora Wiki to the modern Fedora Docs platform to improve discoverability and maintainability.

Decisions

The AI/ML SIG officially evolved into the Fedora AI Working Group (WG). This rebranding affects the broader community, as Matrix channels, Forgejo repositories, and the documentation site are being updated to reflect the unified identity.
The group adopted structured issue templates containing an AI assistance disclosure checkbox for its documentation site to ensure all external community contributions comply with the Fedora AI policy.

Contribution opportunities

An active project to migrate AI/ML content to Fedora Docs needs help converting legacy Wiki markup, structuring pages, and setting up :page-alias: redirects for existing Quick Docs.
Contributors with automation experience are needed to help develop a new Fedora Agent Skill for reviewing Fedora Docs components and content.
Help is requested to write automated ingestion scripts that pull build and release statuses directly from Koji and dist-git to maintain dynamic package tracking tables.

Learn more about the AI & ML team.

RISC-V

This week, the RISC-V group celebrated the release of the Fedora 45 RISC-V Beta images. Extensive testing on physical hardware—including Jupiter, P550, K3, and Titan boards—showed that the new images work smoothly. The group also made major strides preparing for Fedora 46, bringing the RISC-V content set almost fully into sync with the primary Fedora repositories, with over 19,000 packages now up to date.

Community members have been actively patching several packages that currently fail to build on the architecture, such as gdl, cmake, os-autoinst, and vxl. Meanwhile, kernel development continues for the upcoming 7.3 kernel, alongside stability improvements for the Omni kernel on ESWIN and P550 boards. Discussions in the Fedora RISC-V chat room and the fortnightly meeting confirmed that development is progressing well with no major blockers.

Decisions

Users upgrading to Fedora 45 via dnf will need to manually install the fedora-repos-omni repository. The team decided to document this manual step on the wiki to assist users.
The group agreed that removing board-specific kernel patches (such as the VisionFive 2 PCIe patch from the non-omni kernel) should only occur during major release transitions (like F45 to F46) to avoid disrupting existing users mid-cycle.

Contribution opportunities

Assistance is needed to submit pull requests for fixing cmake tests on RISC-V.
The group is looking for contributors to help test and maintain python-torch on the riscv64 architecture.

Learn more about the RISC-V team.

NeuroFedora

NeuroFedora contributors are preparing updates for the hdmf-common-schema, python-hdmf, and python-pynwb packages. During this process, the team noted that the listed maintainer has not performed a build or update in four years. These packages avoided the standard inactive packager flags because the broader NeuroFedora team has been keeping them up to date in the interim. A contributor has reached out directly and plans to initiate the nonresponsive maintainer policy if there is no reply within a few days. Further details can be found in the NeuroFedora Matrix room.

Learn more about the NeuroFedora team.

Gaming

This week, the Gaming group discussed packaging nbsdgames, a collection of 21 terminal-based games. The upstream maintainer reached out to the SIG to suggest its inclusion, noting it is easy to build and depends only on ncurses.

A packaging attempt revealed a binary name conflict between one of the games and the existing sos package. This was quickly resolved by building the games with an upstream option that prefixes all binaries with "nb" (e.g., nbsos). Additionally, the upstream maintainer noted that the games have been dual-licensed under Apache 2.0 to simplify the review process. An initial RPM is currently being prepared for official review.

Decisions

To resolve a binary name conflict with the sos package, the upcoming nbsdgames package will use an upstream build flag to prefix all game binaries with 'nb' (e.g., nbsos).
An initial RPM for nbsdgames was created and will be submitted for official Fedora package review.

Contribution opportunities

Community members are encouraged to help review the upcoming package submission for nbsdgames once it is officially submitted.

Learn more about the Gaming team.

Perl

This week, the Perl group focused on routine package updates and minor configuration adjustments across several repositories. Maintainer Jitka Plesnikova successfully opened and merged pull requests to bump perl-Imager to version 1.037 and perl-DBI to version 1.654. Additionally, a change to the default fixed-width font in perl-podlators (switching from CW to CR) was implemented and merged into the project.

Decisions

Merged a pull request to update perl-Imager to version 1.037 (Source).
Merged a pull request changing the default fixed-width font from CW to CR in perl-podlators (Source).
Merged a pull request to update perl-DBI to version 1.654 (Source).

Learn more about the Perl team.

Python

Miro Hrončok announced a plan to retire pypy3.10 from Fedora 46 and onwards, following the successful packaging of pypy3.12 and the cessation of upstream releases for pypy3.10.

To avoid disruptive surprises for existing contributors and users, pypy3.10 will be retained in Fedora 45 due to the proximity to the final freeze.

Decisions

pypy3.10 will be retired from Fedora 46+ because upstream has stopped making releases and pypy3.12 is now available.
pypy3.10 will remain in Fedora 45 since the release is very close to the final freeze.

Contribution opportunities

Community members are asked to speak up and provide feedback if they have a compelling reason to keep pypy3.10 in Fedora 46+.

Learn more about the Python team.

Other Discussions

In EPEL, ELN and Fedora packaging requirements, Jef Spaleta sparked a conversation about whether packages in the EPEL and ELN namespaces strictly adhere to Fedora packaging guidelines, which clarified that EPEL-only packages still must pass standard Fedora package reviews.
A discussion regarding Bodhi: require_bugs and require_testcases have never been enforced - should they be? resulted in a consensus that previously ignored flags should default to off, and existing updates must be mass-edited to false before enforcing gating rules.
Priscila Gutierres posted a Bioinformatics SIG Proposal to package essential genetics and computational biology tools, leading to cross-collaboration talks with the NeuroFedora SIG on the devel list.
Christopher noted that GMail will remove ability to send email from @fedoraproject.org addresses soon, prompting contributors to seek alternative SMTP solutions and email clients for interacting with mailing lists.
Miroslav Suchý asked contributors to Donate 1 minute of your time to test upgrades from F44 to F45 using an assumption-less dry run to preemptively catch and report package dependency issues.
Gordon Messmer inquired about How can I contact the crypto team? to add AWS s2n-tls and AWS-LC; the thread detailed Fedora's crypto-policy constraints and concerns regarding AWS-LC's configuration format.
Gordon Messmer also asked Would your package be easier to build if you could select specific releases of dependencies?, proposing upstream-release tracking branches in dist-git to build complex apps like vLLM as containers without hindering Rawhide maintenance.
While coordinating an update of libxml2 and mini mass rebuild for F45, Zbigniew Jędrzejewski-Szmek prompted a side-debate over the etiquette of committing directly to branched package repositories without maintainer consultation.
Julian Sikorski started a thread on the NTFS drivers situation, concluding that user-space tools and guestfs should continue relying on the mature ntfs-3g driver rather than the newer, less stable in-kernel ntfs3 driver.
Several users reported Problems with https://koji.fedoraproject.org/ leading to 403 errors, which Kevin Fenzi attributed to temporary IP bans designed to block aggressive data scrapers hitting expensive endpoints.
Other discussions included a proposal to pass --noclean to rpmbuild in Mock, a search for help for the Potentially non-responsive maintainer for julia, an RFC: splitting perf out of the kernel packaging, announcements for Fedora 45 RISC-V (non-official) Beta images and a Wiki resource for Fedora RISC-V + KVM, a scheduled Fedora Copr Outage on the buildsys list, the upcoming Fedora 45 Blocker Review Meeting, a warning about Package builds / updates accidentally missing from Fedora 45(+), and a request for IBus in update testing on the i18n list.

Package Orphaning

Jakub Martisko gave a heads up about Deprecating and later Orphaning Atlas package (including the subpackages) due to upstream inactivity since 2018.
Ben Beasley announced he is Orphaning python-fastapi and related packages due to the mounting maintenance burden caused by new opentelemetry dependencies.

Package Updates

Yann Collette shared Some news about the Audinux activity for September, highlighting a successful F45 beta build, 16 new packages, and 336 updates.
Pavel Raiskup announced the release of Mock v6.9 (cross-posted on the buildsys list), which introduces an unconditional --noclean flag to skip the obsolete %clean section during RPM builds.

All contribution opportunities

There are numerous highly accessible opportunities for community members to contribute to Quality Assurance, testing, and feedback, even without being part of a specific Special Interest Group (SIG). Anyone can help shorten review meetings by voting on proposed blocker bugs and freeze exceptions for Workstation, KDE, and ARM. Hands-on testers are needed to evaluate Anaconda F45 features, run IoT nightly tests, perform Fedora 44 to 45 upgrade dry-runs, and validate F45 Server Release Candidates. If you have specific hardware, testing is requested for SAS controllers and the new RISC-V Beta images. Furthermore, the broader community is encouraged to weigh in on structural proposals, such as keeping pypy3.10 in Fedora 46+, preserving Git-derived mtimes in RPMs, and resolving a GPL/MIT-0 licensing inquiry regarding the Slint UI Framework.

For contributors with skills in writing, design, and event coordination, there are excellent entry-level tasks available. Writers can help meet accessibility standards by authoring image alt-text for the Beginner's Guide, organizing scattered multimedia documentation, or structuring migrated AI/ML Wiki content. The Docs team is also recruiting Fedora Docs Captains to act as liaisons and seeks feedback on building a "Contribution" section for their homepage. Designers are invited to contribute visual assets for the F45 Virtual Release Party, sketch ideas for the F46 Wallpaper, or tackle UI/UX projects in the Websites chat. On the community front, Mindshare is seeking moderators, and open-source event organizers in the Philippines are looking to partner with local Fedora Ambassadors.

Contributors with backgrounds in packaging, development, and automation can assist several teams with critical maintenance and coding tasks. The EPEL group urgently needs packagers to branch autossh, bring mailman3 and incus to EPEL 10, and patch an ffmpeg heap-buffer-overflow CVE. Developers can also help maintain python-torch on RISC-V, rescue the julia package from retirement, or review the nbsdgames submission. Those with DevOps or automation experience are encouraged to update apps.fedoraproject.org, configure Zabbix monitoring for OpenShift Docs, write automated ingestion scripts for AI/ML tracking, or submit pull requests fixing systemd units for Atomic desktops.

Kevin Fenzi: misc fedora bits: first week of october 2026

2026-10-04T23:24:29+00:00

A bit late with the weekly recap this week, possible due to lower energy from getting my flu and covid boosters friday, but lets go...

Mass update/reboot

The mass update reboot cycle went pretty well. We also applied firmware to all the machines that had updates, which always takes a while, but probibly is worth it.

Database server upgrades

Also, as part of the outage on thursday to do the outage causing hosts updates and reboots, we moved all our database servers over to postgresql 18, rhel10, and the latest timescaledb (in the case of db-datanommer).

That also went reasonably well, and we shouldn't have to do that again for a while.

Fedora 45 infrastructure freeze coming up

This coming tuesday is the start of the infrastructure freeze for fedora 45 final release.

Out next weekend

I'm out next friday through sunday, heading to seattle for a rust concert. I'm planning on taking the train, so that should be fun, but there will not really be a recap next weekend. :)

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

Fedora Infrastructure Status: Fedora Forge outage

2026-10-04T08:00:00+00:00

Tristan Partin: iCloud and CalDAV

2026-10-03T15:29:36+00:00

Phil Wyett: Code samples on GitHub

2026-10-03T10:39:00+00:00

I have begun adding git repositories on my GitHub instance with code samples in a variety of programming languages. These languages are C, C++, Java and others as time passes. These samples may help people in their learning of coding, but it also is fun for me to write basic programs in varying languages and keep my hand in.

kathenasdg on GitHub

Michael Catanzaro: The Era of Software Quality, or the Era of Ostriches?

2026-10-02T18:08:21+00:00

Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.

The above paragraph is taken from the abstracts of my GUADEC 2024 and 2025 talks. At the time, I thought failure was inevitable: we humans were so bad at writing software that we had no chance to do it properly, and I certainly would not have trusted an AI to do better than a human. But the landscape today is completely different than last year. AI has improved considerably, and offers a magic fairy wand solution to this problem: we can now simply ask a language model to look for vulnerabilities in our software. They are quite good at this.

There is zero hope of maintaining quality software in 2026 without AI vulnerability scanning. Any claims to the contrary are unserious and delusional. The tremendous quantity of bugs found in our best-maintained projects, like GLib and fwupd, should speak for itself. Failure to scan our projects is an unfair disservice to our users. If we don’t find the vulnerabilities by scanning projects ourselves, attackers certainly will, because the Linux user base has increased to the point that Linux users are finally numerous enough to be worth targeting. Meanwhile, AI has made it easier than ever to build working exploits, which was previously unheard of.

Already resolved all the detectable vulnerabilities? Then ask the AI to look for non-security bugs as well, to further improve quality. GNOME code is generally much better than it used to be, but there remains considerable room for improvement. For the first time in history, we now have the opportunity to improve software quality to a degree that was never realistic before.

Have you heard that most AI bug reports are “slop?” Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)

AI-generated vulnerability reports have nevertheless introduced many undesirable impacts on GNOME maintainers. They are usually annoyingly verbose and unnecessarily detailed. They often exaggerate the severity of the problem, or make misleading or irrelevant claims. They are occasionally incorrect. Sometimes they include outright fabricated data, such as fake stack traces (which is not the norm, but sadly also not uncommon). A good human reviewer will notice and resolve most of the above problems before creating a bug report on your issue tracker, but often problems are reported by inexperienced humans who do not actually know what they are looking at and simply copy/paste everything blindly. Even when the generated issue report is good and avoids all of the above problems (which is rare), good vulnerability reports in sufficiently high quantity can still overwhelm volunteer maintainers. And even if reporters submit a merge request to resolve the problem so maintainers don’t have to (which is also rare), reviewing those merge requests is itself more unwelcome work for overworked maintainers.

That all is to say: I understand the pain caused by the current wave of AI-generated issue reports. Nevertheless, they are essential and unavoidable. We have to learn to accept and deal with them, not stick our heads in the sand and ignore them.

Some GNOME maintainers have adopted a policy prohibiting AI-generated content in issue reports. Do not do this. Nowadays, the overwhelming majority of vulnerability reports are AI-generated. Projects that choose to ban AI-generated content in issue reports might as well ban all vulnerability reports; the effect will be approximately the same.

I propose the following:

GNOME maintainers should rewrite their AI contribution policies to permit AI-generated vulnerability reports, as I previously requested four months ago.
Projects that continue to prohibit AI-generated vulnerability reports are no longer suitable dependencies for GNOME, and should be developed someplace other than GNOME GitLab.

We don’t have to tolerate bad issue reports, but AI use alone should not be disqualifying.

Shouldn’t humans rewrite AI-generated bug reports?

When I complain that maintainers should allow AI-generated vulnerability reports, the most common counterargument is that humans should read the AI’s report, understand it, and rewrite the entire thing to remove all AI-generated content. Some bug reporters actually voluntarily do this, but this is rare.

Vulnerability reporting is a public service, not an obligation. If you ask a reporter to do any amount of extra work, they might be willing to do so, but it’s much more likely that they will either stop looking at your project and move on to something else, or continue looking at your project and publish the vulnerability reports someplace other than your issue tracker.

Rewriting issue reports also does not scale. Let’s say you use AI to find 100 security bugs in a GNOME project, a number consistent with the results of actual scans (read on). Would you really spend months rewriting those bug reports before submitting them to upstream? Validating the AI’s claims, upstreaming the issue reports, and submitting merge requests is already a lot of work. Not many people would be willing to additionally rewrite all the issue reports. That’s more work than everything else combined, and is unrealistic.

Even with just a small number of bugs, I would hesitate to spend much time rewriting an issue report because I have many other tasks I would rather spend my time on. At best, I might prepare a quick summary, but it won’t be as useful as a full report.

The CVE Wave Hits GNOME

The current wave of vulnerability reports is reflected in GNOME’s CVE issuance trends:

Year	GNOME CVEs	GNOME CVEs Excluding GIMP, Gegl, libxml2, and libxslt
2021	21	14
2022	14	6
2023	13	4
2024	37	28
2025	97	49
2026 Year-to-date (2026-09-30)	141	74
2026 Normalized	188 (141 * 4 / 3)	99 (74 * 4 / 3)

The trend here should be pretty clear. Until recently, not many people were reporting vulnerabilities in GNOME. That has changed. We are currently dealing with an order of magnitude more CVEs than just 3 years ago. AI is not the only reason for this; GNOME maintainers have also gotten a little better at flagging issues so that I add them to security tracking. But AI is the primary cause for the increase.

(A few technical notes on this table. CVEs are classified by the year the issue was reported to GNOME, not by the year in the CVE identifier, so e.g. many CVE-2026 issues are counted in 2025. Vulnerabilities reported in 2026 which do not yet have CVEs are not counted, so you can think of the data as being accurate through roughly September 1; multiply the 2026 numbers by 4/3 to make them comparable to the prior years. I count only issues reported to GNOME Security, so any unreported CVEs do not count.)

Although there are still 3 months left in 2026, we will never have data for the rest of the year because I have ended security tracking for new issue reports and nobody else has volunteered to do that work. These CVEs exist only because I request them myself, so I expect the number of CVEs to drastically decrease going forward.

The CVE Wave Hits WebKitGTK

A similar pattern holds for WebKitGTK:

Year	WebKitGTK CVEs
2015	175
2016	57
2017	158
2018	101
2019	99
2020	38
2021	52
2022	50
2023	45
2024	38
2025	66
2026 Year-to-date (through WSA-2026-0006)	305

CVEs are reported against the year they appeared in a WebKitGTK security advisory, not the year in the CVE ID. The large increase in 2026 is entirely due to AI analysis of Skia and ANGLE. WebKit bundles these libraries because they are not designed to be installed as system libraries, so their vulnerabilities should be counted the same as vulnerabilities in WebKit’s own code. Excluding Skia and ANGLE, there are actually only 21 other WebKitGTK CVEs so far this year, a significant decrease, but excluding CVEs in bundled code would not be fair.

There has actually been a very large increase in WebKit security fixes this year, but this has not resulted in any increase in CVEs. Apple generally creates CVEs for flaws found by external researchers, not often for flaws found by WebKit developers, so the increase in security fixes is not reflected in the total number of CVEs. Only a small fraction of WebKit vulnerabilities receive CVEs.

I had not previously noticed that the count of WebKitGTK CVEs had, until 2026, been decreasing over the past decade. I am not sure why. I also do not know how to explain the low number in 2016.

Announcing the GNOME Bug Bounty Program and Announcing the End of the GNOME Bug Bounty Program

My blog post to-do list says that I need to write a blog post announcing the creation of the GNOME Bug Bounty Program on the YesWeHack platform. Oops, too late. It’s already closed. (Once a task enters my to-do list, it can be a very long time before I get around to doing it.)

The GNOME Bug Bounty Program was generously sponsored by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency. I’m not sure precisely when it opened, but the first vulnerability was reported on June 27, 2024, so it would have been sometime shortly before then. We accepted issue reports only for GLib, glib-networking, and libsoup, because GNOME had never operated a bug bounty program before and we did not know what to expect. Starting small had — naively — seemed like a prudent way to avoid a large quantity of issue reports. I had wanted to expand the program to cover all of GNOME, but this failed due to the overwhelming deluge in issues reported against GLib and libsoup.

I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:

Year	Reports Submitted	Reports Accepted
2024	26	14
2025	150	33
2026	122	24
Total	298	71

Those numbers for 2026 reflect less than two months’ worth of issue reports, so you can see why it was no longer sustainable.

After the program closed, our work was not done: there was a long backlog of reports to work though. We just last month caught up with accepting the last of the issues reported back in February, and the last bounty was finally awarded earlier today! Even with YesWeHack’s professional triagers analyzing the issue reports before I reviewed them, keeping up with such a large number of vulnerabilities was not easy for me.

At this point, all reports not accepted have been rejected. The program awarded €183,900 in bounties for 71 vulnerabilities: 45 in libsoup, 23 in GLib, and 3 in glib-networking. Award amounts varied from €500 (16 awards) to €7,500 (2 awards). The arithmetic mean award was €2,662.99.

Bug bounty programs are an exception to the rule that most AI-generated vulnerability reports are good. You can see the number of reports accepted is a small fraction of the number of reports submitted. Excluding 30 reports closed as duplicates, that leaves 197 reports rejected. Turns out, people will submit bad reports when financially incentivized to do so. The low percentage of accepted reports even understates the problem, because many of the accepted reports were actually not very good! Many accepted reports did successfully identify valid security problems (in fact, many of the rejected reports successfully identified valid security problems!), but required many rounds of revision and corrections.

Suffice to say, I have reviewed a lot of really bad AI-generated vulnerability reports. But the reports we received via the discontinued bug bounty program are not comparable to the reports received via regular GNOME issue trackers or the security bug report form. We do still occasionally receive bad vulnerability reports, but not often and not many, so it’s not a big problem anymore. When people submit AI-generated reports without hope of a financial award, those reports are generally much better.

Lessons from the Bug Bounty Program

Closing the bug bounty program because it found too many vulnerabilities is not a particularly pleasant result. That said, it was still a partial success in that it uncovered lots of bugs in libsoup and GLib.

I had hypothesized that libsoup was probably not very secure, but I never imagined just how many vulnerabilities would be discovered. To reduce the quantity of incoming issue reports and better reflect actual risk to GNOME users, I eventually removed all denial of service bugs from program scope, and then later removed SoupServer from the scope due to too many request smuggling vulnerabilities, which are HTTP request parsing bugs that pose no threat to GNOME users. Even with those changes, the libsoup vulnerability reports kept coming until I gave up. The silver lining is that libsoup is now relatively much more secure than before. Other bug reporters have been submitting AI-generated bug reports using the normal libsoup issue tracker, so fortunately the improvements to libsoup will continue despite an end to the financial awards.

I had hypothesized that GLib would be much better than libsoup. I’m not sure whether I was correct. Evaluating the severity of GLib flaws is much harder than for libsoup, since GLib vulnerability reports are generally hypothetical in nature: usually some proof of concept program calls a GLib API using valid but improbable values, then something bad happens.

A large portion of the GLib bugs were integer overflow flaws, which generally result in buffer overflow. I am now more scared of integer overflow than anything else. It’s likely that most software projects have many integer overflow problems. Fortunately, we should be able to catch most such problems by adjusting the compiler flags we use. In particular, -Wconversion or -Wint-conversion and -Wsign-compare should help here. Some GNOME projects already use -Wsign-compare, but I suspect most do not. I think few or no GNOME projects use -Wconversion or -Wint-conversion.

Resuming the bug bounty program would only be possible under substantially different conditions. What we were doing was not working well. To resume, we would need to limit the scope to projects that regularly perform their own AI vulnerability scans. We would also most likely want to pay only for functional exploits, rather than for all vulnerabilities. GNOME code is currently not good enough to continue paying for every vulnerability, and it no longer makes sense to pay bounties for issues that can be found by AI scanners.

Red Hat Scans GLib

Red Hat has contracted with AISLE Research to perform AI vulnerability scans of various GNOME projects. We received a large quantity of findings, and are only just now beginning to individually validate and report our findings to upstream. GLib is by far the hardest hit project, which I was not expecting, accounting for more than 40% of our total findings. I’m not certain why, but perhaps this is because GLib provides so many public APIs. Data passed to public APIs is potentially untrusted, so the attack surface is considerable.

Red Hat’s scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these “vulnerabilities” are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let’s count all of them as false positives. That alone creates a 40% false positive rate. Ouch.

I don’t have more stats to share here because we are not yet done working through the issue reports. That said, I am quite pleased with the results thus far. Substantially all of the reports are high-quality. The false positive vulnerability reports are almost all due to one particular misunderstanding and can be treated as good quality non-security bug reports, which are still valuable. Expect many forthcoming CVE assignments for the other findings.

It’s rare for Linux vendors to proactively look for software vulnerabilities, rather than waiting for security researchers to report them. This was a successful experiment in proactively seeking out problems.

Humans Still Useful

In addition to the bug bounty program, the Sovereign Tech Resilience program also sponsored a security audit for GNOME, performed by Codean Labs. This resulted in many findings in various GNOME projects. Most notably, the scope of the audit extended to Flatpak and xdg-desktop-portal, resulting in critical findings.

Most of these issues could have been detected via AI scans, but I am not confident that AIs would have been able to discover the most important findings, like the two Flatpak sandbox escapes that I linked to above. Accordingly, I do not recommend relying on AI alone.

Humanity Still Desired

Although I like AI-generated issue reports, I particularly do not appreciate when I wind up interacting with a robot rather than with a human. It’s pretty obvious when your issue tracker or code review comments are written by an AI. Consider whether outsourcing your writing and your thinking to a language model is truly wise for your public image.

We even have one experienced GNOME developer who is obviously using AI to write all of his posts on GitLab. I am unsure whether he is copy/pasting all of his responses from an AI, or whether he is just a bot now. I especially do not understand the value of this.

Here is a soft proposal, intended only as a starting point for discussion and not as a serious proposal, for what my preferred AI usage policy might look like:

Newer developers should exercise caution when using AI to write code. Your priority should be learning, and I wonder how much you are really learning when relying on the AI to do work for you.
Do not use AI to write code comments. Currents AIs are terrible at writing comments. Most comments written by AIs should be deleted. If a comment is truly necessary, then I’d like to see it written in your own words. Presumably AIs will get better at this eventually, but as of 2026, human judgment is still required here.
Do not use AI to write commit messages. AIs are actually probably better than humans at writing commit messages, but I would still rather hear your own thoughts on the code you are submitting.
Certainly do not post AI-generated comments on an issue tracker or merge request as if they are your own. You’re not fooling anybody.

Maintain Perspective

Are you scared by the large numbers of recently-discovered vulnerabilities? There is no need to panic. Security bugs are just bugs, and they’re not necessarily more important than other bugs. Occasionally they are emergencies, but far more often they are boring and unexceptional. Security vulnerabilities are not even the biggest digital security threats that users face: those are surely phishing and trojans, with software security bugs a distant third place. No amount of CVE fixing will protect you from those more likely threats.

I don’t want to downplay the severity of security issues either. In fact, evaluating severity is hard. I quite often decide that a bug is not a big deal, only to be proven incorrect. Ideally, we would fix as many security issues as possible, and sooner rather than later. Lifetime issues and out of bounds writes are especially important to fix. Two years ago, I claimed that memory safety vulnerabilities were becoming less threatening, a claim that did not age well: that is surely no longer true due to the drastically increased accessibility of AI exploit generation.

Nonetheless, volunteer maintainers should not feel obligated to fix security issues or treat them as higher-priority than other bug reports. It’s certainly good to fix problems when possible, but my request is only that you do not prohibit issue reports, not that you attempt to personally resolve every security problem yourself. When I add due dates to vulnerability reports, that represents only a disclosure deadline — because issue reports should not stay confidential indefinitely — not an expectation that you fix the issue by that date. Resolving security problems in projects used by big tech companies that depend on your software without contributing back is basically free labor for said companies, and only you can decide whether that’s how you want to spend your volunteer time.

Rust

Yes, even projects written in memory safe languages like Rust still need to allow AI-generated vulnerability reports. Rust will indeed eliminate most memory safety issues (except in unsafe blocks), and you can reasonably expect a Rust project to have an order of magnitude fewer vulnerabilities than a comparable project written in C or C++ or Vala. This is amazing, but not all vulnerabilities are memory safety issues, so this is not an excuse to avoid scanning for flaws.

Although Rust mostly eliminates memory safety risk, any use of Cargo to download dependencies dramatically increases supply chain security risk. The risk of bundling a trojanized dependency arguably — I would even say probably — outweighs the benefit of eliminating memory safety flaws. This problem is inherent to any programming language package manager. Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.

To Be Continued…

I have exhausted my thoughts on AI vulnerability reports, but there is still much to discuss regarding software quality. Next time, I will discuss additional strategies to improve GNOME quality without significantly relying on AI.

Phil Wyett: Change naming of screenshots under MacOS 27

2026-10-02T17:53:00+00:00

Some like myself change many settings in whichever Operating System (OS) we are using. Under MacOS I change the naming for screenshots. On the commandline it can be accomplished with the command below.

defaults write com.apple.screencapture name "YourCustomName"

Have the naming you want. That is it.

Phil Wyett: Elegoo Neptune Pro 3 - Playing and Learning

2026-10-02T17:30:00+00:00

This weekend has become the one where I have setup my new Elegoo Neptune Pro 3 3D printer. We will be testing and getting used to the device and working towards building some useful projects.

One of the first projects is to print cases for my Arduino UNO R3 devices.

Watch this space for future projects that incorporate 3D printed elements.

Michael Catanzaro: How to Request a CVE

2026-10-02T15:00:15+00:00

As previously announced, I have discontinued my tracking of GNOME security issues. Nobody else has volunteered to continue that work, so it has concluded (except for issues reported during September 2026, which I will keep an eye on until the end of this month).

Maintainers, I encourage you to request your own CVEs by writing to Red Hat Product Security. Red Hat is an ideal CNA (CVE Numbering Authority) to use for GNOME CVEs because you will receive timely responses. Ignore Red Hat’s suggestions to encrypt your mail using GPG, and use the following email template:

Hi, I request a CVE for:

Summary:
Requirements to exploit:
Component affected:
Version affected: All versions <-- change this if needed
Patch available: Yes/No
Version fixed (if any already):
Upstream coordination: See issue report (below)
CVSS (optional):
Impact (optional):
Embargo: No
Acknowledgment:
Steps to reproduce if available: see issue report
Mitigation if available: <-- it's OK to write "None"
Original report:

Request a CVE after making your issue report public. It’s possible to reserve a CVE in advance, but this requires twice as many steps, so I recommend making it public first, then request a CVE second.

GNOME and Fedora maintainers should feel free to get in touch with me if you have questions.

Christof Damian: Friday Links 26-30

2026-10-01T22:00:00+00:00

Fedora Infrastructure Status: Updates and reboots on Fedora infrastructure

2026-10-01T20:00:00+00:00

Fedora Infrastructure Status: Fedora Copr outage - updating servers

2026-10-01T06:00:00+00:00

Christof Damian: XScreenSaver on Fedora Wayland with retrosaver

2026-09-30T22:00:00+00:00

Ben Cotton: Providing project emails

2026-09-30T12:00:00+00:00

If your project has a domain, you may accept inbound email. And if you accept inbound email, you may offer email addresses to contributors. And this can get complicated.

In 2026, you are almost certainly not running a full-fledged mail service for your project. By which I mean you don’t provide accounts that can send, receive, and store email from a server that you run. Because we cannot behave ourselves, the email industry has attempted to adopt stronger security practices. The end result of which is that if you’re running your own email server, a lot of the mail you send gets send to the recipient’s spam folder (or worse: dropped by the server). This is 100% not a valuable use of time for an open source project. But just because you’re not running a full email system, that doesn’t mean you can’t give your contributors aliases that point to their real inboxes.

Why would you do this? Well, it can be a (basically) free way to reward regular contributors. Giving them a project email address is a form of recognition. It’s a status symbol that they can take pride in. Plus, it has some practical advantages. They can use it as a filtering tool: mail sent to bcotton@coolfossproject.example.org may end up in the same account as all of my other email, but I can filter anything sent to that address to my “Cool FOSS Project” folder. It’s also a signal to others that I am doing work on behalf of the project.

Unfortunately, the asymmetry of email services makes this (particularly the last time) less effective than it once was. A lot of people, myself included, would use the project email alias in a “send as” setup so that we could not only receive email using the alias, but (appear to) send it, as well. A big chunk of the world uses GMail for email, and GMail will no longer support sending from third-party addresses beginning in January 2027.

So should you still provide project emails? I wouldn’t go out of the way to at this point. But if you have the pieces in place for other reasons, it’s a nice thing to offer your contributors.

This post’s featured photo by Thanhy Nguyen on Unsplash.

The post Providing project emails appeared first on Duck Alignment Academy.

Phil Wyett: Back again...

2026-09-30T10:03:00+00:00

It has been a while since my last post. I am still recovering from a serious illness and major operation. I will be posting more now I am better and truly on the mend.

Coming up will be some new projects using Single Board Computers (SBCs) and also some robotics work.

Remi Collet: 🎲 PHP 8.6 as Software Collection

2026-07-03T05:38:00+00:00

Version 8.6.0alpha1 has been released. It's still in development and will soon enter the stabilization phase for the developers and the test phase for the users (see the schedule).

The RPMs of this upcoming new version of PHP 8.6, are available in remi repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) in a fresh new Software Collection (php86) allowing its installation beside the system version.

As I (still) strongly believe in SCL's potential to provide a simple way to allow installation of various versions simultaneously, and as I think it is useful to offer this feature to allow developers to test their applications, to allow sysadmin to prepare a migration or simply to use this version for some specific application, I decide to create this new SCL.

I also plan to propose this new version as a Fedora 46 change (as F45 should be released a few weeks before PHP 8.6.0).

Installation :

yum install php86

⚠️ To be noticed:

the SCL is independent from the system and doesn't alter it
this SCL is available in remi-safe repository (or remi for Fedora)
installation is under the /opt/remi/php86 tree, configuration under the /etc/opt/remi/php86 tree
the FPM service (php86-php-fpm) is available, listening on /var/opt/remi/php86/run/php-fpm/www.sock
the php86 command gives simple access to this new version, however, the module or scl command is still the recommended way.
for now, the collection provides 8.6.0-alpha1, and alpha/beta/RC versions will be released in the next weeks
some of the PECL extensions are already available, see the extensions status page
tracking issue #342 can be used to follow the work in progress on RPMS of PHP and extensions
the php86-syspaths package allows to use it as the system's default version

ℹ️ Also, read other entries about SCL especially the description of My PHP workstation.

$ module load php86
$ php --version
PHP 8.6.0alpha1 (cli) (built: Jun 30 2026 11:28:16) (NTS gcc x86_64)
Copyright © The PHP Group and Contributors
Built by Remi's RPM repository  #StandWithUkraine
Zend Engine v4.6.0-dev, Copyright © Zend by Perforce
    with Zend OPcache v8.6.0alpha1, Copyright ©, by Zend by Perforce

As always, your feedback is welcome on the tracking ticket.

Software Collections (php86)

Fedora Community Blog: Anaconda F45 features Test Week

2026-09-29T14:08:36+00:00

The Fedora QA team invites you to participate in the Anaconda F45 features Test Week, which is running now through October 2, 2026. There is still time to jump in this week and help us shape the Fedora 45 installer before it ships.

What’s New in the Anaconda F45 Installer

Fedora 45 brings three significant changes to how you install the system. Each one is ready for real-world testing – and better testing means a better installer.

WebUI for Atomic Desktops – The modern web-based installer now covers the Atomic Desktops (Silverblue, Kinoite, and the Cosmic/Sway/Budgie Atomic variants). See the Change page.
Remote WebUI – You can now drive an installation from another device entirely, straight from a browser. See the Change page.
Stratis support – The WebUI can now configure Stratis storage. See the Change page and the introduction on Fedora Magazine.

How to Participate

Requirements

A virtual machine or a spare bare-metal box – not a production machine and not one with data you care about.
The latest Fedora 45 nightly image (nightly images or the development mirror).
A little time between now and October 2.

Start here

The Anaconda Test Week is running now through October 2, 2026. We have prepared easy-to-follow steps for you here: https://fedoraproject.org/wiki/Test_Day:2026-09-28_Anaconda_F45_features

If you need any help, community contacts are listed on that page too.

Learn more:

The post Anaconda F45 features Test Week appeared first on Fedora Community Blog.

Fedora Community Blog: Fedora Shines Blue at Software Freedom Day Bukidnon 2026

2026-09-29T12:00:00+00:00

On September 19, 2026, the Fedora Project supported the conduct of Software Freedom Day Bukidnon 2026. The event took place at the Northern Bukidnon State College, Manolo Fortich, Philippines.

Now in its second run, Software Freedom Day Bukidnon gathered students, professionals, educators, and community members to explore how Free and Open Source Software can empower innovation, digital inclusion, and impact their daily lives, primarily in the province of Bukidnon, Philippines. Despite the challenges like power outage, the event was a massive success, demonstrating the local community’s resilience and passion for open technology.

Event Highlights

The event features an impressive speaker lineup, with presentations spanning foundational Open Source principles and cutting-edge technology trends.

Paul Harriet Asiñero while presenting Hello Fedora
Walt Miner while presenting Introduction to Automotive Grade Linux
Arjay Sitoy while presenting Local LLMs: My 8GB VRAM vs the World
Romar Mayer Micabalo while presenting Harnessing Krita For Fun and Profit
Rafael Tibudan while presenting Building a Second Brain: Turning Information into Leverage
Wei Lee while presenting Orchestration Still Matters: Apache Airflow in the Age of AI
Jay Ginete while presenting 5 Cool Open Source Tools to Pimp Out Your Windows CLI
Roger Madjos while presenting Practical Agentic Coding with OpenCode

Linux and Open Systems

Hello Fedora by Paul Harriet Asiñero – This session introduced attendees to Fedora Linux, highlighting its pivotal role in driving Open Source innovation. Participants explored the power, robust security, and exceptional flexibility that make it one of the world’s premier Open Source operating systems.

Introduction to Automotive Grade Linux by Walt Miner – Attendees received an exciting look at how Open Source technology has moved beyond PCs and servers, driving the software systems that power modern smart vehicles.

Art and the Developer Workflow

Harnessing Krita For Fun and Profit by Romar Mayer Micabalo – Proving that Open Source is just as crucial for creatives as it is for developers, this talk walked attendees through building a career or hobby using Krita, a premier Open Source digital painting tool.

5 Cool Open Source Tools to Pimp Out Your Windows CLI by Jay Ginete – A practical guide for developers stuck on proprietary systems, showing how to upgrade a boring terminal into an Open Source-powered developer powerhouse.

The AI and Data Pipeline

Local LLMs: My 8GB VRAM vs the World by Arjay Sitoy – In a highly relevant, budget-conscious session, this talk demonstrated how developers can break free from corporate API reliance by running powerful Large Language Models locally on standard consumer hardware.

Practical Agentic Coding with OpenCode by Roger Madjos – Shifting from consumption to creation, this session showed developers how to leverage Open Source AI agents to actively write and debug code. Attendees walked away with a practical blueprint for turning agentic coding into a reliable, secure, and repeatable development workflow that delivers value faster without compromising quality.

Building a Second Brain: Turning Information into Leverage by Rafael Tibudan – Explored how to use knowledge management, AI, and automation to build a digital “second brain.” The session shared simple, scalable strategies to transform past code bugs, research notes, and AI conversations into a personal knowledge base.

Orchestration Still Matters: Apache Airflow in the Age of AI by Wei Lee – Attendees got a deep dive into the backend infrastructure powering modern technology. The talk drove home a crucial point: even as artificial intelligence dominates the headlines, leveraging Apache Airflow to control and orchestrate the data pipelines and workflows powering AI applications remains absolutely vital to AI success.

Page Follow Bingo Game and Raffle Draw

In addition to the engaging sessions, the event featured a Page Follow Bingo Game and an exciting raffle for all attendees. The Bingo game was designed to boost engagement for our event sponsors and partners by encouraging participants to follow their official pages, with the first five to complete the task being crowned winners. The event wrapped up with a raffle draw featuring an array of prizes generously contributed by our sponsors. The raffle was conducted using pyraffle, an Open Source raffle draw software executed within a notebook environment.

Final Thoughts

Despite the challenges, Software Freedom Day Bukidnon 2026 was a resounding success! An impactful movement like this cannot happen in isolation. As we look back on the success of this year’s event, our deepest gratitude goes out to the incredible individuals and organizations who helped bring this vision to life.

Event Sponsors and Partners

Software Freedom Day Bukidnon 2026 Event Partners and Sponsors

This event was made possible through the generous support of our partners and sponsors. In addition to the Fedora Project, we would like to extend our sincere gratitude to the following organizations:

Event Sponsors:

Event Partners:

Aside from the participating organizations, we would like to express our gratitude to an anonymous donor for providing financial support for the event.

Speakers

Awarding of tokens for the Speakers

Thank you for sharing your time, passion, and unparalleled expertise. You gave our community tangible frameworks to work with, sparking ideas that will undoubtedly fuel local tech innovation for months to come.

Event Volunteers

Volunteers are the backbone of Software Freedom Day Bukidnon 2026, driving everything from pre-event preparations to post-event operations. We are proud to recognize the dedicated individuals who made this success possible:

Participants

Thank you for taking the time out of your weekend to show up, engage, and learn. Your energy, thoughtful questions, and collaborative spirit are what give life to the FOSS movement in Bukidnon. You are the future of our digital landscape, a thriving ecosystem where the veterans lift up the rookies, passing the torch to ensure the next generation keeps pushing boundaries.

The event has wrapped up, but our mission continues. The Free and Open Source Software movement in Bukidnon thrives because of community advocates and supporters like you. As we look ahead to the return of Software Freedom Day next September, we invite you to join us as a participant, volunteer, sponsor, or partner. Together, we can empower local tech ecosystems and drive collaborative innovation.

The post Fedora Shines Blue at Software Freedom Day Bukidnon 2026 appeared first on Fedora Community Blog.

Aurélien Bompard: From September 21 to September 27

2026-09-28T09:00:00+00:00

Across the Fedora community this week, the primary focus is squarely on preparations for the upcoming Fedora 45 Final release, with groups including Workstation, KDE, Release Engineering, and Quality heavily engaged in blocker bug reviews, freeze exception evaluations, and rigorous test days ahead of the imminent October 6 infrastructure freeze. Concurrently, teams are bracing for a massive planned infrastructure outage scheduled for October 1, 2026, which coincides with foundational planning to move dist-git from Pagure to Fedora Forge. Another prominent, community-wide theme is the spirited debate over opting into a new LLM-powered weekly reporting tool; groups like EPEL, Websites and Apps, and RISC-V approved data collection with varying privacy boundaries, while the Kernel and CoreOS members negotiated compromises for their channels. Finally, foundational housekeeping remains a shared priority, highlighted by the Packaging Committee's drive to simplify snapshot versioning rules and FESCo's ongoing efforts to standardize packager workflows and evaluate long-term Bugzilla replacements.

Announcements

Fedora 45 is bringing modern local storage management to the forefront, as the Anaconda installer will now feature built-in support for Stratis storage (detailed further in a companion Fedora Magazine article), allowing users to easily configure pools and filesystems via the Cockpit Web UI or Kickstart. On the hardware side, Fedora Podcast Episode 061 explores the successful collaboration to ship the Framework Laptop 12 with Fedora KDE pre-installed, highlighting upstream kernel bug fixes that benefit the broader Linux ecosystem. The community also shared excellent technical resources this week, including a highly portable guide for installing the Navidrome music server using Podman and a comprehensive deep dive into BTRFS maintenance, Snapper configurations, and drive balancing.

To ensure contributors are prepared for upcoming maintenance and avoid disruptive surprises, please note a planned infrastructure outage scheduled for October 1, 2026, at 20:00 UTC. The downtime will last approximately six hours to apply necessary system updates and reboot servers. While most services will only experience brief interruptions, some may be unavailable for a longer period due to firmware upgrades.

Council

The primary focus of the Council this week was advancing the new Fedora Forge Usage Policy to a formal vote. After incorporating community feedback over several weeks, the policy is designed to govern the scope, access, and resource limits of the Fedora Forge infrastructure. Council members have until September 30, 2026, to cast their votes, requiring full consensus to pass.

Additionally, during the Council meeting, members celebrated the release of the Fedora 45 beta and noted that the Fedora 45 Final freeze will begin on October 6. In open floor discussions, the Council also deliberated on a proposed Conflict of Interest policy and discussed how to improve escalation and mediation pathways from project groups like FESCo and Mindshare to the Council.

Decisions

The Council formally agreed that they are satisfied with the latest version of the Fedora Forge Usage Policy and have moved it to a formal vote in Ticket #581. Voting is due by September 30, 2026, and requires full consensus (+3 votes, and no -1 votes) to pass.

Learn more about the Council team.

FESCo

FESCo's week focused heavily on finalizing system changes for the upcoming Fedora 45 release, managing the ongoing Bugzilla migration investigation, and addressing packager workflows. The committee evaluated the status of several incomplete F45 changes and approved a critical, late-stage security update for libxml2. They also discussed concerns regarding meeting quorum and attendance, deciding to reach out directly to inactive members before pursuing formal policy adjustments.

Extensive discussions took place asynchronously regarding the eventual replacement of Fedora's Bugzilla instance, with members heavily debating whether to migrate to a modernized upstream Bugzilla or transition to Forgejo. Key considerations included the preservation of historical data, necessary API integrations, and cross-component query capabilities. Additionally, FESCo addressed community concerns regarding AI-generated upstream code in the proposed oo7 secrets service provider and debated new performance baseline requirements for alternative architectures hosted in the main Koji instance.

Decisions

Approved a policy exemption to upgrade libxml2 to 2.15.4 in F45 to address critical security vulnerabilities, deciding to treat it as an Updates Policy exception rather than retargeting the official Change proposal.
Agreed to publish a reminder to provenpackagers clarifying that converting packages to %autorelease or %autochangelog does not constitute a "general cleanup" and strictly requires prior maintainer consent.
Declared the Filter Fedora Flatpaks for Atomic Desktop v2 Change as complete, with Aoife Moloney tasked to update the Bugzilla and wiki entries to reflect the correct release target.

Learn more about the FESCo team.

Packaging Committee

This week, the Packaging Committee focused heavily on cleaning up and simplifying the packaging guidelines, with RPM versioning rules as a major theme. A recent incident involving the bluez package—where non-standard snapshot versioning broke upgrade paths and led to incorrectly waived test failures—highlighted the excessive complexity of the current snapshot guidelines. As a result, the committee is actively discussing standardizing on a single, highly simplified snapshot format to prevent packagers from making similar errors in the future.

Alongside the versioning simplification efforts, the committee handled several routine housekeeping tasks. These included proposing a new appendix page to declutter the main versioning guidelines, fixing typos in the OCaml guidelines, and completely updating outdated references to decommissioned Pagure instances across the documentation.

Learn more about the Packaging Committee team.

Workstation / GNOME

The Workstation / GNOME group evaluated new third-party software repository proposals this week, including LiveFaceSwap Desktop and 1Password. In community discussions, users highlighted issues with power management during offline upgrades on Ryzen laptops, and it was noted that the RPM package for Bottles is orphaned and slated for removal in Fedora 45+ unless a maintainer steps up.

Furthermore, the group is preparing for the Fedora 45 Blocker Review and is addressing concerns about stale appstream-data, which severely impacts GUI software stores like GNOME Software and KDE Discover if left unmaintained.

Decisions

The working group voted to include 1Password as an approved third-party repository, pending the repository being correctly set up with AppStream repodata.

Contribution opportunities

Help is urgently needed to automate the weekly updates for appstream-data, which currently depends on manual interventions. This is critical for the stability of graphical software centers in Fedora.
Contributors are invited to review and vote on bugs for the upcoming Fedora 45 Blocker Review to help expedite the upcoming Matrix meeting.
The Bottles package is currently orphaned and requires a new maintainer to prevent its removal from Fedora 45+.
The LiveFaceSwap Desktop application has been proposed as a third-party software repository and is open for community evaluation.

Learn more about the Workstation / GNOME team.

KDE

This week, the KDE SIG focused on modernizing the default package selection for Fedora KDE installations. Proposals currently under review include making k3b optional in favor of a lightweight USB ISO image writer like Fedora Media Writer, and dropping the akonadi-server-mysql backend from the default install. Because KDE Gear 26.04 now defaults to SQLite, removing the MySQL backend would reduce the installed footprint by approximately 184 MiB.

In the community forums, users are investigating a potential bug where startup and shutdown sounds continue to play despite being disabled in the system settings. Additionally, Fedora QA announced the upcoming Fedora 45 Blocker Review meeting, reminding community members that they can vote on proposed blockers in advance.

Contribution opportunities

Vote on proposed blockers and freeze exceptions ahead of the Fedora 45 Blocker Review meeting using the blockerbugs app.
Provide feedback on the SIG proposal to make k3b optional and include a modern USB ISO image writer in the default installation.
Review the SIG proposal to drop akonadi-server-mysql from the default comps.
Help troubleshoot and investigate a potential bug where startup and shutdown sounds cannot be disabled in Fedora 44 Plasma.

Learn more about the KDE team.

Server

The Server group focused heavily on Fedora 45 release testing and finalizing their Ansible support strategy. System updates for Python 3.15, Perl 5.44, and MariaDB 12.3 have been successfully integrated and most F45 Branched installation tests (USB/NET, BIOS/UEFI) are passing smoothly. However, persistent partition type errors and initial-setup infinite boot loops remain unresolved for KVM Guest and ARM SBC images.

Concurrently, the group shaped the delivery mechanism for Fedora Server's Ansible automation. To accommodate both advanced administrators and everyday users, the team opted to provide standard Ansible collections alongside an opinionated, turnkey management wrapper designed to hide Ansible's complexity for regular single-node deployments.

Decisions

The group will publish the core Fedora Server Ansible collection under the name fedoraserver.general to Ansible Galaxy before packaging it into Fedora via RPM (Ticket #265).
The Server team will develop a separate, turnkey 'management project' package containing a purpose-built CLI, template playbooks, and a default inventory to simplify single-node server setups for users unfamiliar with Ansible (Meeting Log).
Documentation articles in the 'Postinstallation Customizations' section will use single-word titles based on a working group vote (Meeting Log).

Contribution opportunities

The Fedora QA team invites contributors to vote on proposed F45 blockers and freeze exceptions prior to the review meetings to help expedite the review process (Mailing list post).
Assistance is needed in diagnosing an initial-setup infinite boot loop and incorrect LVM partition typings affecting the F45 KVM Guest and ARM SBC images.
Community members are invited to review two newly submitted documentation articles regarding virtualization and creating a VM from a disk image (Meeting Log).

Learn more about the Server team.

Infrastructure

The Infrastructure team is preparing for a major planned outage on October 1st, which will involve mass updates, reboots, firmware upgrades, and database migrations (including RHEL 10 upgrades). In preparation, the team has been focused on deploying new databases in production and testing the new siguldry signing code in the staging environment. Additionally, the Forge team completed the foundational planning for migrating Fedora's dist-git from Pagure to Forgejo, implementing automated backups, SSH key sync from FAS, and developing private issues.

Other notable activities included mitigating a Koji Out-Of-Memory incident caused by a scraper aggressively hitting rpminfo and tweaking Zabbix monitoring thresholds for disk space. Routine maintenance involved archiving old mailing lists, creating new FAS groups, and addressing various service access issues.

Decisions

A major infrastructure outage for mass updates, reboots, and database migrations is scheduled for 2026-10-01 at 20:00 UTC.
The Fedora 45 infrastructure freeze will begin on 2026-10-06.
The qa-devel and autoqa-devel mailing lists have been archived and made read-only.

Contribution opportunities

Help is needed to rewrite Standupbot in the Maubot framework and to clean up technical debt on Status.fpo.
The team is looking for testers and karma for several kiwi plugin updates across different Fedora and EPEL releases.
A community member is looking for someone to run the Oraculum playbook for them.
New contributors interested in non-sysadmin tasks, such as documentation or application development, are encouraged to check the Infrastructure Join Guide.

Learn more about the Infrastructure team.

Release Engineering

The Release Engineering group focused heavily on preparations for the Fedora 45 Final release this week. Blocker review meetings were held to evaluate critical bugs, accepting key issues involving oo7-portal and GRUB boot failures on FW RAID, while rejecting other proposed freeze exceptions. In the background, the team refined their beta release announcement templates, updated standard operating procedures to prevent missed commits during future release branchings, and scheduled the second round of retiring Fail-To-Install (FTI) packages currently in the NEW state.

Other infrastructure and pipeline efforts progressed smoothly. The team investigated ostree failures during system composes, which were successfully traced back to background git maintenance runs. The group also coordinated the upcoming generation of a new GPG key for ELN 12, discussed the routing of unsigned RISC-V builds directly to eln, and processed package orphanings for non-responsive maintainers.

Decisions

Accepted bug 2537341 (oo7-portal not installed by default after upgrading) as a Final Blocker, and bug 2530897 (GRUB boot failure on FW RAID) as a Final Freeze Exception during the Fedora 45 Blocker Review Meeting.
Confirmed that package maintainers requesting unretirement no longer need to open RelEng tickets and should use the automated fedpkg request-unretirement command, as noted in Ticket #13535.
Confirmed that RISC-V builds in the Koji instance are currently unsigned and decided that ELNBuildSync will tag them directly to eln rather than routing them through Bodhi, as discussed in the Matrix chat.
Decided to drop the "Retire all packages with broken deps" step from the release freeze schedule, as historical review showed it has not been actively utilized since 2017 (Meeting Log).
Cancelled the scheduled September 28th RELENG meeting due to overlapping PTO and conferences (Meeting Log).

Learn more about the Release Engineering team.

Quality

The Quality team has been actively preparing for the Fedora 45 release through rigorous blocker bug reviews, test days, and validation testing. The F45 CoreOS Test Week took place this week, and preparations are finalized for the upcoming Anaconda F45 features test days (focused on the new WebUI and Stratis support) as well as the Conmon-v3/Podman test days in October. Additionally, the release-blocking storage interfaces list has been trimmed to remove obsolete or hard-to-test interfaces.

In addition to F45 preparations, the team addressed CI/CD pipeline improvements, such as downgrading rpmlint spell-check errors to warnings to reduce dist-git PR failures, and cleaning up the fedora-ci-admins group membership. Discussions are also underway regarding power management regressions with tuned-ppd on modern laptops and a proposal to make the Fedora KDE Plasma Desktop AArch64 live ISO release-blocking for Fedora 46.

Decisions

[CI/CD Improvement] rpmlint spellchecking errors in Fedora CI have been downgraded to warnings to prevent unnecessary dist-git PR blockages on valid technical terms (URL).
[Community Process] The qa-devel mailing list has been made read-only due to long-term inactivity; communication will consolidate to modern channels (URL).
[F45 Final Blocker] Bug 2537341 was accepted as a Final Blocker because the oo7-portal replacement for gnome-keyring is not installed by default on upgraded systems, breaking keyring functionality (URL).
[F45 Freeze Exception] Bug 2530897 was accepted as a Final Freeze Exception for an Anaconda installer bug where Grub boot fails with an "invalid magic number" on FW RAID (URL).
[F45 Final Blocker] Bug 2448283 regarding non-ASCII capable keyboard layouts was rejected as a Final Blocker, as UI pre-selection now mitigates the issue on KDE live installs (URL).
[F45 Freeze Exceptions] Bugs 2533661 and 2535835 were rejected as Final Freeze Exceptions due to the risks of introducing minor or substantial upstream changes during a freeze (URL).

Contribution opportunities

Testing Opportunity: Test the Fedora 45 RISC-V (non-official) Beta images on various boards and provide feedback on the Fedora RISC-V Matrix channel.
Test Days: Participate in the upcoming Anaconda F45 features test days (Sept 28 - Oct 2) to test Stratis, Atomic Desktop default installs, and the new remote WebUI.
Test Days: Participate in the upcoming Conmon-v3 test days (Oct 5 - Oct 11) to test the new Podman container monitor lifecycle and logging capabilities.
Translations: Language teams and translators are encouraged to help add missing strings to the anaconda-webui translation before the Final Freeze.
Test Organization: Help organize or suggest test cases for remaining F45 planned test days.

Learn more about the Quality team.

Websites and Apps

The Websites and Apps team focused heavily on optimizing page load times for several Fedora download pages, including /misc, Spins, Labs, and Atomic Desktops. By removing heavy client-side JavaScript related to the "beta" release toggles and replacing it with a lightweight redirect script, contributors reduced initial page load times from around 5 seconds to just over 1 second. Following this success, the team is discussing further optimizations to the Nuxt codebase, including standardizing URL construction and moving static metadata from navigation.js into the project's CMS to allow more pages to be built entirely server-side.

Additionally, a bug that caused CoreOS bare metal raw images to disappear from the download page was identified as a Nuxt YAML parsing issue and was promptly fixed. The group also updated the Swedish translation files and approved the inclusion of their communication channels in automated weekly community reports.

Decisions

CoreOS bare metal raw images have been restored to the download page after a Nuxt content YAML parsing issue was patched.
The team approved the collection of their Matrix logs and GitLab trackers for LLM-generated community reporting, and requested that the CMS repository be monitored as well.

Contribution opportunities

Contributors familiar with Nuxt and Vue are welcome to help optimize the codebase by migrating remaining client-side rendered elements to Server-Side Rendering (SSR) and moving static description data out of navigation.js and into the Fedora CMS. Long-term refactoring efforts should be tracked by opening tickets on the Fedora Websites GitLab.

Learn more about the Websites and Apps team.

Design

The Design team published a final wrap-up of the Fedora 45 wallpaper in a recent blog post and is currently preparing for the Fedora 46 wallpaper, which honors mathematician Karen Uhlenbeck. The team is also evaluating a request to provide a higher-resolution Fedora logo to resolve blurry rendering on the GDM login screen when using fractional scaling, a default setting since Fedora 41.

In addition, the Design team successfully finalized the new EPEL Steering Committee badge, and a new pull request was opened to add a "Fedora loves KDE" sticker to the Event Kit. Ongoing foundational work continues on the Community Personas project, aimed at creating character concepts for different Fedora contributor roles.

Decisions

The EPEL Steering Committee officially accepted the new badge design created by the Design team. The badge has been published and is now available for current and past committee members.

Contribution opportunities

Contribute sketches or visual explorations for the Fedora 46 Karen Uhlenbeck wallpaper ahead of the September 28th checkpoint.
Sketch character concepts and ideas for the Community Personas project to visually represent various Fedora contributor roles, such as coders, translators, designers, and event organizers.
Help resolve the higher-resolution Fedora logo request by verifying or providing a crisp, SVG-derived render of the Fedora logo (at least 600px wide) to fix pixelation issues on the GDM login screen.

Learn more about the Design team.

Docs

The Docs team launched a new Matrix channel (#alerts-docs:fedoraproject.org) dedicated strictly to automated notifications for issues, pull requests, and build failures. To reduce noise in this channel, they agreed to disable org-level Action Run events in favor of per-repository configuration. In tooling news, a Cryptpad instance was successfully deployed on CommuniShift ahead of the Fedora Linux 45 release, providing the team with a dedicated, AsciiDoc-friendly collaborative writing tool.

On the content side, the Beginner's Guide was updated for F45 compatibility, which notably includes migrating the backup section from kbackup to Vorta. Discussions are also underway regarding a proposal to generate an llms.txt index to optimize interactions with AI agents, and the team remains divided on whether to allow the TWIF bot to summarize their Matrix channel. Finally, efforts to improve monitoring and incident reporting for site builds are continuing with plans to test Zabbix integrations and replicated CI workflows.

Decisions

The team decided to disable global Action Run webhooks in Forgejo and manage them manually on a per-repository basis to prevent spamming the new alerts channel.

Contribution opportunities

Experienced Git users are invited to help provide input on a new Git cheat sheet being drafted for team documentation.
Contributors interested in AI integrations can participate in the discussion about adding llms.txt discovery indexes to the Docs site.

Learn more about the Docs team.

COPR

Between 2026-09-21 and 2026-09-27, the COPR team announced and completed a scheduled infrastructure outage to update their systems to the September 2026 release version. The maintenance took place on September 23, lasting approximately two hours. While build queue processing and the frontend web interface were temporarily disabled, existing DNF packages and repositories remained fully accessible to users throughout the downtime.

Following the successful deployment, the team published the September 2026 release highlights detailing the new changes and improvements for the community.

Decisions

The COPR team scheduled and executed a two-hour infrastructure update on September 23, 2026, temporarily pausing build queues and web UI access while ensuring existing DNF repositories remained online. (Source)

Learn more about the COPR team.

EPEL

This week, the EPEL group officially approved Issue #373 to include specific EPEL communication channels in a new LLM-powered weekly report. The committee deliberately excluded the general Matrix chat channel to preserve conversational privacy while authorizing data collection from mailing lists, Discourse, specific trackers, and meeting logs. Additionally, progress was shared on finalizing and merging the ESC member badges.

The team also engaged in package policy work regarding snapshot version guidelines alongside routine maintenance for djvulibre and ansible-collection-ktdreyer-koji_ansible (Issue #19). Quality work was similarly performed on FTI packages including pipewire-epel.

Decisions

Approved Issue #373, permitting an LLM-powered weekly report generator to parse specific group channels: the epel-devel and epel-announce mailing lists, Discourse posts with the #epel-sig tag, the epel/misc, epel/releng, and epel/steering trackers, and the official weekly meeting logs.

Contribution opportunities

The python-sphinxcontrib-apidoc package has been orphaned in EPEL because it fails to install in epel9. The community is seeking a volunteer to take over the package's maintenance. (Mailing List Thread)

Learn more about the EPEL team.

ELN

During the ELN meeting on September 22, 2026, the group focused on aligning the fedora-eln-release package with fedora-release. Contributors noted that the DNF configurations require manual synchronization, mirroring recent updates made to the generic release. Completing this alignment is an important maintenance step that will streamline the process of forking the package to create future CentOS and Red Hat release packages.

Decisions

Stephen Gallagher will update the fedora-repos-eln package with the necessary DNF configuration changes to ensure it is synced properly with the main Fedora release. (Source)

Learn more about the ELN team.

Atomic

This week in the Atomic group, a community member inquired about an up-to-date solution for running the 3D VFX software Houdini on Fedora Silverblue. The discussion focuses on finding a modern method to manage the software's background services, specifically adapting to recent changes in how the free version's license server operates.

Learn more about the Atomic team.

CoreOS

The CoreOS group primarily focused on the Fedora 45 CoreOS Test Week which ran from September 21 to 25. Throughout the week, community members and maintainers tested FCOS based on F45 content, identifying bugs such as the live installer not appearing on VT1 due to the system-wide integration of kmscon, and a Cilium defect on 7.2.x kernels that prevents networking on Kubernetes clusters.

Additionally, the team discussed their inclusion in the LLM-powered weekly report, resolved several SELinux policy issues (including a pin to fix podman-remote socket connections), and successfully merged support for the STACKIT cloud platform.

Decisions

The team decided to defer the decision on allowing the weekly report scraper into the general Matrix #coreos channel, opting instead to start by supplying public, structured data like formal meeting logs, Discourse posts, and issue trackers. (Meeting log)
Decided to drop DTBs (Device Tree Blobs) on aarch64 architectures for Fedora 45+ to save space in the /boot partition. (Issue #2222)
Pinned the selinux-policy package to mitigate an issue where SELinux denied podman-remote socket connections via SSH on the next and testing streams. (Issue #2217)
Accepted and merged native platform support for STACKIT, a European sovereign cloud provider, into Afterburn, Ignition, and CoreOS Assembler. (Issue #2175)

Contribution opportunities

The Fedora CoreOS team invited the community to participate in the Fedora 45 CoreOS Test Week to test FCOS before it is released to the stable streams. Contributors can find testing instructions on the Fedora Wiki and log their results on the Test Day Results page.

Learn more about the CoreOS team.

ARM

This week, the ARM group received an announcement regarding the upcoming Fedora 45 Blocker and Freeze Exception Review meeting scheduled for September 28, 2026, at 16:00 UTC on Matrix. The community will evaluate four proposed blockers for the Final release to determine if they violate any release criteria.

Contribution opportunities

Participate in the Fedora 45 Blocker Review meeting on Matrix to evaluate bugs against the release criteria.
Review and vote on proposed blocker and freeze exception bugs ahead of the meeting via the Blockerbugs app. Voting early helps expedite the review process and keeps the meeting short.

Learn more about the ARM team.

Kernel

Aurelien Bompard initiated a discussion regarding LLM data collection for the "This Week in Fedora" newsletter. The proposal involves gathering activity from the group's mailing list, Discourse tags, and public Matrix channel to summarize ongoing work. Following privacy concerns from some members regarding the processing of Matrix chat logs, Justin Forbes volunteered to provide human-written summaries instead. However, other members suggested retaining the LLM automation to avoid adding to the manual workload, provided there is a human review step before publication.

Decisions

Specific users who object to having their messages processed by an LLM have been added to an exclusion list to prevent their data from being collected. (Source)
The newsletter tool is being modified to output draft articles to the Community Blog, allowing contributors to review and amend the LLM-generated summaries prior to publication. (Source)

Learn more about the Kernel team.

AI & ML

The AI & ML SIG celebrated the official launch of their new documentation site and discussed potential plans to migrate legacy wiki content to the new platform, though this will wait for further input from key wiki contributors. Upstream changes in ROCm 10.0 have introduced a faster time-based release cycle, and efforts are underway to package it for Rawhide. Looking ahead to Fedora 46, the SIG explored debuting a Fedora Skills Library to facilitate the sharing of agentic tools, though they acknowledge ongoing packaging challenges with complex dependencies like PyTorch and Electron.

In administrative updates, the new skills-reviewers FAS group was successfully established and linked to Forgejo, formalizing the sub-team that will review and curate the skills library. Meanwhile, members are currently discussing whether to allow a summarizer bot to parse their Matrix channel data for weekly community reports, stressing the need for clear disclosure to room members if implemented.

Decisions

Reverse dependencies for ROCm can switch to the 7.2 compatibility packages if migrating to the newly released ROCm 10.0 is not yet realistic.
No final decisions will be made on the Wiki to Docs site content migration without input from primary wiki authors; a ticket will be opened to outline the proposed plan instead.
The creation of a Skills Reviewers sub-team has been finalized via a new FAS group, concluding the administrative setup for the skills-library.

Contribution opportunities

Package reviewers are needed for podman-desktop and its Electron dependencies.

Learn more about the AI & ML team.

RISC-V

The RISC-V group has been finalizing unofficial Fedora 45 Beta images (Server, Cloud, and Container), which are now available for testing in the alt architectures test directory. During generation, the team diagnosed an LVM/XFS boot failure tied to a dm-sysfs truncation bug related to the Zbb CPU extension, as well as a kernel panic with ACPI enabled in QEMU. Consequently, they temporarily reverted the image filesystems back to Btrfs while upstream kernel patches are finalized.

Meanwhile, the Fedora 46 mass rebuild is approximately 70% complete, and the ELN bootstrap on RISC-V continues. Packaging fixes are actively being upstreamed for scipy, nodejs26, cmake, and others. The group also discussed maintaining the existing LP64D ABI while targeting the RVA23 baseline hardware, and officially opted back into having their Matrix channel scraped for the weekly Fedora LLM reports.

Decisions

Reverted the default file system for RISC-V Fedora 45 images back to Btrfs (from XFS/LVM) due to a dm-sysfs truncation bug linked to the Zbb CPU extension (Issue #33).
Opted the Matrix channel back into the LLM-powered 'This Week in Fedora' summary scraper to improve group discoverability (Issue #30).
Published unofficial Fedora 45 Beta RISC-V images (Server, Cloud, and Container) to the alt architecture testing mirrors for community evaluation (Issue #34).
Agreed to target the RVA23 ISA baseline while maintaining the existing LP64D ABI so that new and existing binaries can be safely mixed (Issue #31).

Contribution opportunities

Test the newly generated unofficial Fedora 45 RISC-V Beta images (Server, Cloud, Container) and report feedback (Issue #34).
Help track down the root cause of the QEMU/EDK2/Kernel ACPI boot freeze occurring on the F45 server images (Issue #35).
Investigate and fix architecture-specific test failures for ELN packages such as cmake, java-25-openjdk, llvm, and toolbox.
Assist with builder capacity and Fedora Message Bus integration for the ongoing ELN bootstrap on RISC-V (Issue #32).

Learn more about the RISC-V team.

Other Discussions

Gordon Messmer initiated a discussion on adding upstream-release branches in dist-git to easily build applications like Flatpaks using specific dependencies, which spurred debates regarding maintainer workload, Fedora's curation philosophy, and dependency management.
A user reported that ~2,300 Fedora/EPEL security tracking bugs unexpectedly became private, to which Alasdair Kergon responded that the changes were quickly reversed using a new administrative function to prevent future occurrences.
Varshitha Kolupuri pointed out that Bodhi's require_bugs and require_testcases flags have never been enforced despite defaulting to enabled, prompting Adam Williamson to suggest flipping the default to false and mass-editing existing updates before enforcing them.
Priscila Gutierres published a Bioinformatics SIG Proposal aimed at identifying, prioritizing, and packaging core bioinformatics and computational biology tools in Fedora, asking for feedback and potential contributors.
Miroslav Suchý requested volunteers to test F44 to F45 upgrades to uncover dependency issues, which helped identify several required obsolete paths and conflicting package situations (e.g., openssl-devel-engine, python3-protobuf, and python3-magic).
Adam Williamson's earlier proposal to gate all stable release updates on rmdepcheck was resurrected by Nikita Popov, who expressed strong support for extending the gating process to Rawhide updates as well to prevent accidental breakages.
Gordon Messmer provided an update on his proposal to use got-audit as a generic Fedora test, noting that he successfully scanned all F44 packages featuring service units and confirmed the tool effectively detects ELF namespace tampering.
Maxwell G announced the completion of the two-factor authentication requirement for provenpackager members, removing a few non-compliant members while prompting a wider discussion on eventually enforcing 2FA for all standard packagers.
Norbert Manthey proposed extending default compiler settings to harden applications by adding flags like -fno-strict-overflow, but Jakub Jelinek opposed this change, explaining it primarily serves as a workaround for kernel bugs and could severely impact performance and break C/C++ userland code.
Paul Bolle raised concerns about thousands of sources files still using the plain md5sum format (and its subsequent discussion), leading to suggestions of using a provenpackager mass-update to transition them to the secure sha512sum format.
Other discussions across the mailing lists included a question about stalled package reviews, multiple patches submitted on the libteam mailing list for adding a per-runner decoupled LACP option (2, 3, 4), a contentious proposal on the buildsys mailing list to unconditionally pass --noclean to rpmbuild in Mock, a notice about a Fedora Copr outage, the scheduling of the F45 Blocker Review Meeting, the availability of F45 RISC-V Beta images, and a report of a dead link for the sshd role on the systemroles mailing list.

Orphaning packages

Paul Bolle inquired about who monitors pull-requests to unmaintained packages, to which Miroslav Suchý merged a trivial cleanup and recommended opening a releng ticket for packages with broken retirement states.
Joe filed a non-responsive maintainer check for ddcutil, resulting in the current maintainer stepping down and Jan Drögehoff offering to adopt the package.
An automated report detailed orphaned packages looking for new maintainers that will be permanently retired in six weeks if no one steps up to adopt them.
Chih-Tao Lee reached out regarding the unresponsive maintainer for python-authlib, and Kai Hiller responded offering to transfer ownership to anyone with the resources to maintain it.
František Šumšal announced the intent to retire linux-atm in F45/Rawhide because upstream kernel 7.2 dropped the required ATM-related UAPI headers, urging maintainers of dependent packages like ppp and iproute to review pull requests dropping their dependencies.

Package updates

Zbigniew Jędrzejewski-Szmek coordinated an update of libxml2 and a mini mass rebuild for F45, managing a few minor synchronization snags with branch maintainers.
Luya Tshimbalanga managed the OpenVDB 13.1.0 SONAME change and coordinated rebuilds via a side-tag, receiving help from Jerry James to push through some failing rebuilds for F45 and Rawhide.
Kaleb Keithley announced a libarrow (Apache Arrow) SONAME bump in rawhide for Arrow 25.0.1, with Orion Poplawski assisting in rebuilding hard dependencies like gdal, groonga, and root.
Artur Frenszek-Iwicki updated libunibreak to v8.0 in Rawhide, bringing a SONAME bump and API changes that required test rebuilds of dependent packages like fbreader, libass, and krita.

New contributor introductions

Damian Daniel introduced himself on the sway mailing list, hoping to join the Sway SIG to help package scenefx, SwayFX, and related projects.
Vivek Denny introduced himself as a backend engineer interested in systems programming, looking to start contributing via package maintenance.
Bradan Fleming introduced himself as a current RPM Fusion maintainer who aims to bring more audio plugins and the ICANN-RDAP tool to Fedora, asking for a package review sponsor.

All contribution opportunities

A crucial way for any community member to support the project is through quality assurance, testing, and troubleshooting. Volunteers are invited to review and vote on Fedora 45 blocker bugs and freeze exceptions using the blockerbugs app across Workstation, KDE, Server, and ARM environments to expedite upcoming review meetings. Testers are highly requested for the upcoming Anaconda F45 features and Conmon-v3 test days, the Fedora 45 CoreOS Test Week (log results here), testing kiwi plugin updates for Infrastructure, and validating F44 to F45 system upgrades. For users with specific hardware or virtualization environments, testing the unofficial F45 RISC-V Beta images (Issue #34) or diagnosing infinite boot loops on F45 KVM Guest, ARM SBC, and RISC-V server images provides immense value. Additionally, volunteers can help organize future test cases or help investigate a startup sound bug in Fedora 44 Plasma.

If your strengths lie in communication, localization, or visual arts, several teams are seeking immediate assistance that does not require coding. Writers and editors are needed to review new Server documentation, refine a Git cheat sheet, and document instructions for running Houdini on Silverblue. Translators are encouraged to provide missing strings for the anaconda-webui before the Final Freeze. Visual designers are invited to conceptualize the Community Personas project, submit visual explorations for the F46 Karen Uhlenbeck wallpaper, or provide a crisp, SVG-derived Fedora logo render to fix pixelation on the GDM login screen. All community members are also welcome to evaluate non-technical proposals, such as the LiveFaceSwap desktop repository or the KDE SIG's proposals regarding k3b defaults and akonadi-server-mysql.

Developers and infrastructure engineers have numerous opportunities to resolve technical debt and build new tooling. Web developers familiar with Nuxt and Vue can significantly optimize the Fedora Websites GitLab repository by migrating remaining client-side rendered elements to SSR. Programmers are needed to automate appstream-data updates, rewrite Standupbot using the Maubot framework, and address technical debt on Status.fpo. System administrators and DevOps contributors can assist by running an Oraculum playbook for a community member, and integrating the Message Bus for the ELN RISC-V bootstrap. Discussions are also open regarding adding llms.txt discovery indexes to the Docs site, and newcomers wanting to learn more can consult the Infrastructure Join Guide.

Finally, contributors with packaging experience can ensure the software ecosystem remains secure and up-to-date by adopting orphaned packages or conducting reviews. Volunteers are actively sought to take over maintaining Bottles in Workstation, python-sphinxcontrib-apidoc in EPEL9, and python-authlib. There is a pressing need for package reviewers for pending requests like airwindows-lv2, VDR packages, and podman-desktop along with its Electron dependencies. Advanced packagers can also investigate architecture-specific test failures for ELN packages such as cmake, llvm, and toolbox on RISC-V, or explore specialized computing by joining the newly proposed Bioinformatics SIG.

Kevin Fenzi: misc fedora bits: fourth week of sep 2026

2026-09-26T17:15:38+00:00

Time for another saturday recap of the week in longer form.

A interesting interrelated issue

A while back we moved our ansible control host to rhel10. After this move, I noticed that the nightly job we run to run a --check --diff over all our playbooks was taking a really long time to finish. I added it to my todo list to look at sometime but didn't think it was super high priority.

Last week we got some zabbix alerts about disk space on our central logging host (log01). Usually when this happens, it's caused by some openshift application crash looping or sending large tracebacks over and over. However, that was not the case this time, as we had added some checks to notify if that ever started happening so we could fix things more quickly.

Looking at the (large) logs, it seemed like it was mostly builders and mostly ssh-session messages.

Thinking these two issues could somehow be related, we started digging into the check-diff run first. It seemed that ansible was connecting to the target hosts, then just disconnecting again and again in a loop. But why?

Dumping the trace output into a clanker gave a quick answer: it's an ansible-core bug. Specifically: https://github.com/ansible/ansible/issues/82685

TLDR: If you specify multiple facts gathering modules (which we do because we have one that gathers some python information), it tries to do them in parallel, but there is a bug and it fails.

So, That was the base cause of both issues. check-diff was slow because it would get stuck trying to gather facts (and get killed after 24h by the script), and it was also causing tons of log messages for each ssh connection which was filling up log01.

A simple:

ansible_facts_parallel: false

Fixed both things.

RHEL10 Database servers

Staging is all done, all servers there are postgresql 18 and rhel10 now. The last one was db-datanommer01.stg, which I did monday. Its still a complex process, but it seems working and doesn't need a intermediate rhel9 instance (as long as I am willing to upgrade the existing one's timescaledb).

So, next thursday we have a outage and I am going to try and migrate all the production database servers. I'll be glad when they are all done.

I might try and do db-datnommer production a different day. Its a lot more complex than the rest and might be good to get out of the way seperately. Also, it's not super end user facing, so it can probibly be down for a little while without too much ill effect. Thats likely to be tuesday or wed.

Mass updates/reboots/outage next week

This is going to be a big one:

We are going to apply firmware updates on servers. This always makes reboots take a while as they have to apply the firmware upgrades.
We have some machines that aren't booting with secureboot enabled and we want to fix those. Sadly that means a boot to setup, enable, and another boot, which takes a while.
I am going to migrate all the prod database servers over to rhel10. This is likely to take a while, but not too bad. There's no dump restore needed, just 'fast' upgrades and shuffling things around so the old rhel9 instances are retired and the new rhel10 ones take their place.

Of course eariler in the week we will do staging and any hosts we can take out of dns, etc... so thursday will mostly just be the bare metal / vmhosts and their guests that we can't take down without an outage.

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

Guillaume Kulakowski: Migration UI de SeedboxSync : De Bulma à Bootstrap

2026-09-26T13:12:20+00:00

Simon de Vlieger: Cohesive Linux

2026-09-25T09:00:00+00:00

Fedora Magazine: Installing Navidrome on Fedora Linux using Podman

2026-09-25T08:00:00+00:00

Navidrome is an open-source music server that lets you stream your personal audio collection anywhere. It gives you freedom to listen to your music collection from any browser or mobile device. It’s like your personal Spotify!

In this guide, we will explore how to get Navidrome up and running securely using Podman on Fedora Linux. Best of all, because Navidrome builds official multi-architecture container images including, linux/amd64, linux/arm64, and linux/arm/v6/v7, this setup is highly portable. Whether your hardware is a standard x86 PC server or a low-powered ARM-based Raspberry Pi, this walk-through has you covered.

For the official image for Navidrome Music Server go to:

deluan/navidrome – Docker Image

Using the official container images with Podman and Podman Compose

Container images are available for the linux/amd64, linux/arm/v6, linux/arm/v7 and linux/arm64 platforms. They include everything needed to run Navidrome

[nico@stamfordbridge navidrome\]$ podman pull deluan/navidrome
 docker.io/deluan/navidrome:latest
Trying to pull docker.io/deluan/navidrome:latest…
Getting image source signatures
Copying blob 75c0824146ea done |
Copying blob 4f4fb700ef54 done |
Copying blob 4f4fb700ef54 done |
Copying blob e1dbf20ea67c done |
Copying blob 1cc3d825d8b2 done |
Copying config 0c9bad3bd7 done |
Writing manifest to image destination
0c9bad3bd7305815d56fe588a64f9172a8bb6aa2bfef3ad77e764c8694e7e860

If you have SELinux enabled on your Fedora Linux server, then add the container_file_t SELinux context to the Data and Music directories and its contents.

[nico@stamfordbridge navidrome]$ sudo semanage fcontext -a -t container_file_t  '/home/nico/navidrome/Data(/.\*)?'

[nico@stamfordbridge navidrome]$ sudo semanage fcontext -a -t container_file_t  '/home/nico/navidrome/Music(/.\*)?'

Apply the SELinux policy to the Data and Music directories.

[nico@stamfordbridge navidrome]$  sudo restorecon -R /home/nico/navidrome/Data

[nico@stamfordbridge navidrome]$  sudo restorecon -R /home/nico/navidrome/Music

Change the owner of the /home/nico/navidrome/Data and /home/nico/navidrome/Music to 1000.

[nico@stamfordbridge navidrome]$ podman unshare chown 1000:1000 /home/nico/navidrome/Data

[nico@stamfordbridge navidrome]$ podman unshare chown 1000:1000 /home/nico/navidrome/Music

Using podman-compose :

Create a podman-compose.yml file with the following content (or add the navidrome service below to your existing file):

[nico@stamfordbridge navidrome]$ cat podman-compose.yml
version: "3"
services:
  navidrome:
    image: deluan/navidrome:latest
    user: 1000:1000 # should be owner of volumes
    ports:
      - "4533:4533"
    restart: unless-stopped
    environment:
      # Optional: put your config options customization here. Examples:
      ND_SCANSCHEDULE: 1h
      ND_LOGLEVEL: info  
      ND_SESSIONTIMEOUT: 24h
      ND_BASEURL: ""
    volumes:
      - "/home/nico/navidrome/Data:/data"
      - "/home/nico/navidrome/Music:/music:ro"

Start the navidrome container with podman-compose up -d.

[nico@stamfordbridge navidrome]$ podman-compose up -d

Note that the environment variables above are just an example and are not required. The values in the example are already the defaults

Using podman command line tool:

[nico@stamfordbridge navidrome]$ podman run -d - name navidrome - restart=unless-stopped - user $(id -u):$(id -g) -v /home/ec2-user/navidrome/Music:/music -v /home/ec2-user/navidrome/Data:/data -p 4533:4533 -e ND_LOGLEVEL=info deluan/navidrome:latest
c00c31d49ec5e0f0a0141aef9e2b69abf6a1b5f0604515bc7111f3e0ef398237

[nico@stamfordbridge navidrome]$ podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c00c31d49ec5 docker.io/deluan/navidrome:latest 9 seconds ago Up 9 seconds 0.0.0.0:4533->4533/tcp navidrome

Customization

The user argument should ideally reflect the UID:GID of the owner of the music library to avoid permission issues. For testing purposes you could omit this directive, but as a rule of thumb you should not run a production container as root.
Remember to change the volumes paths to point to your local paths. /data is where Navidrome will store its DB and cache, /music is where your music files are stored.
Configuration options can be customized with environment variables as needed. For podman-compose just add them to the environment section or the yml file. For podman CLI use the -e parameter. e.g.: -e ND_SESSIONTIMEOUT=24h.
If you want to use a configuration file with Navidrome running in Podman, you can create a navidrome.toml config file in the /data folder and set the option ND_CONFIGFILE=/data/navidrome.toml.

Remi Collet: 🛡️ PHP version 8.2.34, 8.3.35, 8.4.26 and 8.5.11

2026-09-25T06:00:00+00:00

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

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

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

RPMs of PHP version 8.2.34 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.

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

🛡️ These Versions fix 10 security bugs (CVE-2026-91768, CVE-2025-1218, CVE-2026-91769, CVE-2026-91767, CVE-2026-6103, CVE-2026-91765, CVE-2025-14181, CVE-2026-93682, CVE-2026-92842, CVE-2026-91766), 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:

Fedora Rawhide now has PHP version 8.5.11
Fedora 45 - PHP 8.5.11
Fedora 44 - PHP 8.5.11
Fedora 43 - PHP 8.4.26

⚠️ 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)

Christof Damian: Friday Links 26-29

2026-09-24T22:00:00+00:00

Fedora Badges: New badge: ESC member !

2026-09-24T19:26:43+00:00

Jef Spaleta: New blog who dis?

2026-09-23T16:02:35+00:00

I haven’t blogged seriously since about 2012, not since I was an active Fedora contributor, in fact. And now that I’m back and in the very privileged position of being the Fedora Project Leader, it's time for me to start blogging again.

Actually, it’s well past time. I should have restarted several months ago, but I’ve been reluctant to start doing it again. To understand my own reluctance requires some introspection into why I stopped in the first place. If you go back and look at the historical blog, it was pretty much about stuff going on in the broader open source ecosystem at the time… 20 years ago. I could have continued to do that; I could have been “that guy” continuing to have an opinion about something I cared about and shout it loudly into the void, but I decided that was not the best path for me. As I stepped back from participating in the Fedora Project culture, I made the decision that I wanted to focus my energy on the things I was well positioned to impact. Sure, I had a lot of opinions about a lot of things over the last decade and change, but I didn’t need to take the time to write them up. I could just have them quietly, and focus on what was in front of me, and let the open source ecosystem go on without me. I let go, not because I thought my voice was valueless, but because I trusted in the fact that I wasn’t indispensable in the conversation.

But now I find myself back in the project, inhabiting a role that is indispensable. And that creates a degree of cognitive dissonance for me. Now, because I’m FPL, I need to start doing some of my thinking out loud again; long-form, nuanced thinking. Maybe not coherent thinking. Maybe not self-consistent thinking. But nuanced and researched. I knew at the start of this gig, I was going to have to pick blogging back up again. I made an excuse to myself that I needed to wait a bit and ease back into the discussion culture, but that was a rationalization that allowed me to wait too long. I owe it to everyone in the Fedora Project to start publishing what I’m thinking about and how I’m examining a topic and how deeply I’ve interrogated my own values, biases, and assumptions.

So hey! I’m blogging again. But this time it’s going to be different. This time it’s going to be primarily a dialog with myself… between my inner skeptic, idealist, and pragmatist aspects of my persona. The glass will be half full, half empty, and completely full all at the same time. This is going to be an experiment to openly journal an introspective process in how I form and reform opinions on topics. Topics will be scoped for relevance to the open source ecosystem using the Fedora Project Leader role as a lens for how I organize my thoughts. You might see some discussion about fusion energy and curling here, because I’m me and I’m having a dialog primarily with myself, so I have to reach for experiences I can relate to in order to argue with myself… that can’t be helped. And I will double-space my sentences because I am old, and no matter how hard I try to change the muscle memory to accommodate the drift in cultural standards on that, it’s not gonna happen, and I’m not gonna use a copy editor in this space. This is my space, typos and all.

Guillaume Kulakowski: Portainer 3.0 : virage entreprise et Kubernetes : pourquoi mon passage à Arcane était la bonne décision

2026-09-23T10:52:00+00:00

Remi Collet: ⚙️ PHP version 8.4.25 and 8.5.10

2026-08-28T04:51:00+00:00

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:

Fedora Rawhide now has PHP version 8.5.10
Fedora 45 - PHP 8.5.10
Fedora 44 - PHP 8.5.10
Fedora 43 - PHP 8.4.25

⚠️ 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)

Remi Collet: 🛡️ PHP version 8.2.33, 8.3.33, 8.4.24, and 8.5.9

2026-07-31T05:05:00+00:00

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:

Fedora Rawhide now has PHP version 8.5.9
Fedora 44 - PHP 8.5.9
Fedora 43 - PHP 8.4.24

⚠️ 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)

Fedora Magazine: Installing Fedora 45 on Stratis storage

2026-09-23T08:00:00+00:00

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.

Fedora Infrastructure Status: Fedora Copr outage - updating servers

2026-09-23T06:00:00+00:00

Remi Collet: 🎲 PHP version 8.4.26RC1 and 8.5.11RC1

2026-09-11T04:32:00+00:00

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)

Remi Collet: 📝 Valkey version 9.2

2026-09-22T06:50:00+00:00

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

Remi Collet: 📝 Valkey version 9.1

2026-03-18T09:29:00+00:00

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

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.1/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.1
# 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-search (Fedora)
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.7 and 10.1, and Fedora 42 have Valkey 8.0 in their repository
Fedora 43 has Valkey 8.1
Fedora 44 will have Valkey 9.0
Fedora 45 will have Valkey 9.1

4. Statistics

valkey

Aurélien Bompard: From September 14 to September 20

2026-09-21T09:06:00+00:00

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

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

New contributor introductions

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.

Rénich Bon Ćirić: The Interlock Protocol: Deterministic Rails with Autonomous AI Oversight

2026-09-21T02:55:00+00:00

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?

The Two Polar Anti-Patterns

In modern agentic automation, I see people constantly falling into one of two traps:

LLM-First Naivety (Agent Sprawl):: This is the Silicon Valley hype pattern: wrapping every routine mechanical task in an autonomous agent. You spin up an LLM to curl an archive, parse a version string with regex, bump a number in a text file, and git commit. It takes 45 seconds, burns $0.08 of API credits, risks stochastic hallucinations on simple syntax, and introduces five points of network latency to something POSIX utilities solve in 4 milliseconds.
Script-Only Fragility:: This is the old-school UNIX purist trap: writing rigid shell scripts for everything. It runs at blistering speed and zero token cost—until upstream refactors a directory, a patch rebase fails with rejects, a Go vendor hash changes, or a new binary appears that violates your RPM %files manifest. The script crashes, execution halts, and you are dragged out of deep work to manually triage a trivial packaging drift.

Both approaches are broken in production.

The sweet spot is an architectural pattern I call the Interlock Protocol.

The Philosophy: Deterministic Spine, Agentic Tripwire

In mechanical engineering and industrial safety, an interlock is a mechanism that prevents a machine from harming itself or its operator by halting execution the moment a state parameter drifts outside tolerance.

The Interlock Protocol applies this exact concept to AI systems engineering:

Note

Prime Axiom: Run deterministic rails until the end. Engage AI strictly on exception or verification.

Under this protocol, your automation has two distinct stages:

Stage 1 (The Deterministic Spine): All routine operations—source retrieval, checksum validation, spec bumping, local SRPM building, static linting, and git operations—run on rigid, deterministic POSIX rails. Zero tokens are consumed on the happy path.
Stage 2 (The Forensic Interlock): When—and only when—a deterministic gate trips (a non-zero exit code, a compiler error, an rpmlint failure, or a remote build failure), the harness halts, serializes a forensic payload, and dispatches an AI agent to investigate the root cause, remediate the code, and restore equilibrium.

+-----------------------------------------------------------+
|                  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)

The Four Core Axioms

If you want to implement this in your own infrastructure, here are the four non-negotiable rules:

Axiom 1: The Deterministic Spine: If a step can be accomplished via standard utilities, compilers, or exit-code checks, it must never touch an LLM. 90% of your operational cycles should execute in milliseconds with zero tokens spent.
Axiom 2: The Forensic Tripwire: Failures must never fail silently. When a command fails, your harness intercepts the signal and captures the exact failure slice: the failed stage name, exit codes, stderr/stdout tails, remote builder logs, and the active git diff.
Axiom 3: Scoped Escalation: Never launch an open-ended conversational agent. Dispatch the agent with bounded diagnostic context, target repository paths, and an explicit, verifiable objective. Run it in an isolated supervisor unit (like a transient systemd user unit) with independent resource accounting and cgroup isolation.
Axiom 4: Zero-Trust Handback & Circuit Breakers: An AI agent's fix must never be accepted blindly. The remediation must re-enter the deterministic harness and satisfy all original verification gates (clean compile, zero lint errors, test suites) before any change is committed or pushed. Crucially, enforce a Circuit Breaker (max 1 or 2 attempts) to prevent recursive self-healing cascades if a codebase has fundamental architectural flaws.

How I Put This into Practice

Tonight, I implemented the Interlock Protocol across my Fedora Copr packaging pipeline.

First, my auditor (fedora-copr-sync.bash) checks upstream GitHub Atom feeds for my packages (like obscura, d2, and lavinmq). When an update is detected, it doesn't just ping me; it dispatches my new updater script:

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

The script runs Stage 1:

Pulls remote changes and verifies the git tree is clean.
Bumps the version in obscura.spec.
Runs spectool -g to fetch the new release archive.
Replaces the old tarball in git (for personal staging repositories) and stages the spec.
Runs rpmlint on the spec (enforcing 0 errors).
Builds the source RPM locally with rpmbuild -bs and validates the SRPM.

Commits the deterministic release:

feat(packaging): update obscura to 0.2.3

Signed-off-by: Rénich Bon Ćirić <renich@evalinux.com>

Pushes to GitLab over SSH and queues the build across all Fedora and CentOS Stream chroots in Copr.

Notice that on the happy path, there is no AI co-author trailer—because no AI was involved. It ran at pure hardware speed.

What Happens When the Build Breaks?

Here is where the Interlock trips. Suppose upstream introduced an incompatible C flag, or a Go package failed to re-vendor, or a patch rejected with .rej files, or a remote Copr builder failed in Rawhide.

In a pure script, the job dies. In an LLM-first setup, you waste tokens watching an agent fumble through 20 minutes of compilation.

Under the Interlock Protocol, the failure immediately trips Stage 2:

# 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}"

Because it runs under systemd-run --user:

The parent process exits cleanly without hanging the supervisor or timer.
The agent inherits active SSH credentials (via the systemd user session's SSH_AUTH_SOCK) so it can push verified fixes.
Its thinking trace, tool executions, and stderr stream directly to journald.
When a remote Copr build fails, the harness automatically downloads and decompresses the remote build.log.gz from the failed chroot, extracting the exact compilation failure so the agent isn't guessing blind.

The agent reads the failure, rebases the patch or updates the spec, validates the fix locally against rpmlint and rpmbuild -bs, and commits with the proper human-agent co-authorship trailer:

feat(packaging): update obscura to 0.2.3

- Remediate compiler flag incompatibility in spec
- Rebase 0001-btls-sys-fix.patch against upstream 0.2.3

Signed-off-by: Rénich Bon Ćirić <renich@evalinux.com>
Co-authored-by: Antigravity <antigravity@google.com>

The agent pushes to the remote repo, resubmits the Copr build, and notifies me on the desktop when the build is back in the green.

The Second Mode: Interlock-Verify

While tonight's focus was on Interlock-Resolve (self-healing exceptions), the Interlock Protocol also defines a second mode: Interlock-Verify.

In this mode, all deterministic checks pass, but the pipeline halts at a semantic boundary to allow an AI agent to perform non-computable qualitative evaluation:

Security Attestation: Auditing AST diffs for unintended supply-chain anomalies before package signing.
Changelog Semantic Consistency: Verifying that commit messages and user-facing changelogs actually reflect the underlying code diffs.
Breaking Change Auditing: Scanning exported API symbols for subtle semantic breaks that type-checkers might miss.

If the audit passes, the release gate unlocks and publication proceeds. If the agent flags an issue, execution halts for human review—with maintainers retaining a deterministic override flag (e.g. --bypass-interlock-verify) to handle false positives.

Conclusion

AI agents are phenomenal reasoners, but terrible conveyor belts.

Don't use an LLM to turn a bolt that POSIX tools have been turning reliably for fifty years. Build rigid, lightning-fast deterministic rails for your happy path, instrument forensic tripwires at your failure boundaries, and unleash your AI agents where their cognitive capabilities actually matter: diagnosing root causes, adapting code, and verifying intent.

Deterministic till the end. AI on exception. That is the Interlock Protocol.

References

Kevin Fenzi: misc fedora bits: third week of sep 2026

2026-09-19T21:21:54+00:00

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

RHEL10 Database migrations

So, I had finished off all the staging databases except for one the week before, so I spent a fair bit of time this last week looking at the last one. It's a pretty fun case, our db-datanommer.

This is the database that stores all the messages that go accross our message bus and allows you to search them via datagrepper. Because of the nature of the data in it, it uses the timescaledb extention on top of postgres. It's currently (in both staging and production) a rhel9 vm with postgresql 13 and timescaledb 2.10.1.

Before getting into the fun set of constraints, I'll mention that I am a paranoid sysadmin. This means I always think about 'what would happen if this migration fails there, or there' So I strongly prefer to leave something in a state where I can backout to it if something goes wrong. So, in this case I strongly prefered to just leave the existing vm alone an dmigrate to a new one, and if something blows up, can just move back to the old one.

So, the constraints were pretty fun here:

timescaledb has a handy chart about which versions support which postgres versions. 2.10.1 doesn't support 16 or 18. No versions support both 13 and 18. 1 version does support both 13 and 16 however.
rhel9 actually has postgresql-16 available, but as a module. Because it's a module it makes it hard to build normal rpms against it.
dump and restore of the db would take way way way too long as a pg_dumpall (sql) dump. The pg_dump formats would be faster, but not all that much because timescaledb doesn't work with -j (N jobs) on restore.
rhel10 has postgresql16 (default) and 18 available as seperate packages.
When you upgrade from 16 to 18, you need to either enable data page checksums (running a tool over the db's) or make 18 start without them. They sound like a really good idea though, so I wanted to enable them

So, in order to do this under all my constraints it would require 3 vm's: The current one (untouched), another rhel9 one to sync the data to, upgrade timescaledb on, then sync that to a rhel10 one to upgrade to 16 and then another timescaledb upgrade and upgrade from 16 to 18.

In the end though, it seems like timescaledb upgrades are pretty smooth and easy, so I decided (at least in staging) to just upgrade timescaledb to 2.13.1 (which supports both 13 and 16). That allows no intermediate rhel9 vm.

So, thats the plan, but there's more gotchas I hit along the way:

When upgrading from 13 to 16, you have to also have timescaledb from the 13 install installed in the right place for the upgrader to use it.
You also need to modify the template postgresql.conf file the upgrader users to enable timescaledb, or else when it upgrades it blows up at the end because there's a missing extension.
Both those last 2 things apply for 16 to 18 too.
The upgrader also helpfully tells you to look at some log when things fail, but it's the log from the data dir it JUST DELETED BECAUSE IT FAILED! I ended up reading those logs by running the upgrader under strace. :(

After all that, I think I have a process now. I was going to do the staging one friday, but I made a stupid mistake (putting the 13 timescaledb.so in the wrong dir) so I ran out of time. Will move it monday.

Mass firmware update/mass reboot/database migrations

So, with the last database server sorted in staging, time to get production done. We are tenatively planning an outage for 2026-10-01, the thursday before final freeze. Hopefully we can get all the databases done then.

https://forge.fedoraproject.org/infra/tickets/issues/13563

Scrapers?

Of course this will jinx things, but things have been reasonably quiet on the scraper front of late. There was some activity where they were hitting our wiki really hard, but luckily it was reasonably easy to block them in that case. It did cause problems for other services however as it caused our proxy network to hit max connections.

Otherwise it's been quite nice not to have to battle them day to day so much.

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

Fedora People

Rajeesh KV: ICFK 2026: Calligraphy Festival

Miroslav Vadkerti: Keeping secrets out of my AI agents

Guillaume Kulakowski: SeedboxSync v4.3 : Bootstrap, UI repensé, widget Homepage et correctifs majeurs

Guillaume Kulakowski: Migration vers Fedora 45 Bêta : mon retour d’expérience sur mon laptop Asus

Akashdeep Dhar: Maintainer Summit - IndiaFOSS 2026

Theme

Experience

Remi Collet: 🎲 PHP version 8.4.27RC1 and 8.5.12RC1

Remi Collet: 🎲 PHP on the road to the 8.6.0 release

Christof Damian: Friday Links 26-31

Kamil Páral: Heroes of Fedora Quality for Q3 2026

Testing proposed updates

Test days participation

Fedora Magazine: Podman Test Week: Help test the Rust-based conmon v3

Why we’re testing conmon v3

Getting started

What to test

Results and help

Peter Czanik: Using syslog-ng with OpenSearch 3.9

Guillaume Kulakowski: Maîtriser mes données de poids : la synchronisation sur mesure

Aurélien Bompard: From September 28 to October 04

Table of contents

Announcements

Council

Decisions

FESCo

Decisions

Packaging Committee

Decisions

Mindshare

Decisions

Contribution opportunities

Fedora Join

Decisions

Contribution opportunities

Ambassadors

Decisions

Contribution opportunities

Diversity & Inclusion

Workstation / GNOME

Contribution opportunities

KDE

Decisions

Contribution opportunities

Server

Decisions

Contribution opportunities

Infrastructure

Decisions

Release Engineering

Decisions

Contribution opportunities

Quality

Decisions

Contribution opportunities

Websites and Apps

Decisions

Contribution opportunities

Design

Decisions

Contribution opportunities

Docs

Decisions

Contribution opportunities

Legal

Contribution opportunities

COPR

Decisions

EPEL

Decisions

Contribution opportunities

ELN

Atomic

Decisions

Contribution opportunities

CoreOS

Decisions

IoT

Decisions