/rss20.xml">

Fedora People

Day One - IndiaFOSS 2026

Posted by Akashdeep Dhar on 2026-10-13 18:30:46 UTC

Theme

Experience

Day One - IndiaFOSS 2026
Manifest A
Day One - IndiaFOSS 2026

There are only so many hours that one could rest for, so, of course, calling it a day early on the previous day led me to wake up early on 26th September 2026. I knew that waking up at 0600am Indian Standard Time would help me reach the venue four hours later with the swags inventory. Since Samyak Jain had arrived on the night before and was planning on joining me for the next couple of days, one of the first things we did was to take the inventory of Ceramic Branded Coffee Mugs and Round Magnet Pin Combos that we had delivered to his relative's house. Working closely with Rajan Shah, we were able to secure the best location for the Red Hat booth and the best schedules for Fedora Project's community presence. We knew from the beginning that we would very likely be the major draw at the booth since we had engaging activities and enticing swags to keep the booth visitors occupied.

Day One - IndiaFOSS 2026
Manifest B

Finishing off the breakfast at around 0800am Indian Standard Time, I finally met Samyak at the reception area when he was just returning from the temple. Luckily enough, he had already taken care of having the swag inventories delivered to SRS Springs And Spa Hotel and, alongside that, he had also gone ahead with ordering some stationery after consulting with me. As we did not necessarily have a talk or discussion planned for that day, we wanted to be sure that we had everything we needed for a successful community booth representation. One could not stress just how important supplies like cellophane tapes, marker pens, plastic scissors, thumb tacks, etc., could be in times like these, not just to us Fedora Project folks but also to the neighbouring communities sharing the booth with us, like Ansible, PyTorch, Tekton, Virtualization, and Containers, for the next couple of days of the event.

Day One - IndiaFOSS 2026
Manifest C

I was not happy with the incomplete breakfast on that morning, but I did not have the luxury of expressing my dissent at the time. Making do with Boiled Idli and Coconut Chutney, paired with some Onion Pakodas and Hot Tea, I joined Samyak at the hotel reception at around 0930am Indian Standard Time. With the delayed delivery of the swag inventory eating up most of our time, we decided to skip the preliminary accounting and instead haul the entire inventory on our Uber ride to the event venue, NIMHANS Convention Center Bengaluru. Thankfully, Rajan's cohort was able to reach the venue earlier to help set things up amidst the early event rush hours, where we were going to dive right in after some time. Thinking on our feet allowed us to prevent any further delays in reaching the event venue and to take advantage of the first period of the flagship hallway track experience.

Day One - IndiaFOSS 2026
Manifest D

With the help of the concierge, we loaded up the heavy units onto the back of our Uber ride, and in the next fifteen to twenty minutes, we found ourselves arriving at the NIMHANS Convention Center Bengaluru. Samyak and I took turns lugging the heavy boxes, weighing 30-40 kg, from the parking area to the registration desk, where we checked ourselves in. Thankfully, our booth was located on the ground floor, right near the entrance, which not only meant that we did not have to play porters for long, but also ensured us the maximum footfall. It was crazy to think just how occupied the venue was, judging by the fact that it had paid registration. With crowd densities comparable to those of free events like FOSDEM etc., this was an expression of just how enthusiastic Indians and people from adjacent regions were about free and open-source software and the folks who maintain it.

Day One - IndiaFOSS 2026
Manifest E

Getting to the Red Hat Community Booth was half the struggle – beyond which Samyak and I had to play it by ear to make it behind the already packed booth space. Samyak slowly made his way to the back of the community booth first, while I began unpacking our swag inventory on the desk. With him designing the poster for our community booth interaction activities using generative tooling, it helped us immensely in ensuring that we were able to make meaningful chats with our community of users and contributors at IndiaFOSS 2026 in our period. After a swift catch-up with the likes of Rajan, Deepesh Nair, Shivraj Patil, Veer Kumar Patil, and Gaurav Kamathe, I arranged the metallic Fedora Project-branded round magnet pin combos on the desk at around 1100am Indian Standard Time, which only led to the big crowd at the Red Hat Community Booth grow a whole lot more.

Day One - IndiaFOSS 2026
Manifest F

Both Samyak and I knew that we had to leverage the visitor footfall that we drew as the local Fedora Project ambassadors to channel visitors to our FOSS projects. As we were already at our capacity for handling visitors, we deferred handing out the rarer swags, such as Wooden Branded Pop Sockets and Ceramic Branded Coffee Mugs, until later, when the visitor crowd became manageable. Of course, that was a good problem to have, as not only Fedora Project but also the sister community projects could use the attention that we were bringing to the Red Hat Community Booth. Armed with the comparative study between Fedora Linux and other related GNU/Linux distributions, we helped the booth visitors understand the differences. We wanted to ensure that they had the knowledge before deciding on the one that they would want to settle on, instead of incessantly singing the praises of our own.

Day One - IndiaFOSS 2026
Manifest G

In the constantly fast-moving world of artificial intelligence, most booth visitors appreciated how Fedora Linux provided them with a curated collection of recent updates for the software applications they used. That, in turn, empowered them to architect solutions for the people of today and the future, instead of waiting much later for them. Being the general-purpose Linux distribution that Fedora Linux was, its appeal was universal among those people who wanted a middle-ground GNU/Linux distribution that was both stable and feature-rich. To our pleasant surprise, we met folks at the booth who learned about Fedora Project while using GNU/Linux distributions such as Bazzite and Ultramarine Linux. Among those questions, we also fielded misconceptions on the figurative death of CentOS Linux and misinformation around Red Hat Enterprise Linux becoming closed source.

Day One - IndiaFOSS 2026
Manifest H

Taking one unit of the Ceramic Branded Coffee Mugs at a time to keep the booth conversations going, we were surely able to draw visitors into an interactive task for which Samyak had created the poster. Being this close to our community of users and contributors at an in-person event allowed us to have a unique approach towards gathering feedback. While our questions were subjective in nature and we strictly made a point of not collecting personally identifiable info, we were curious about how this feedback could help shape the future of Fedora Linux. I got to meet various people from both technical and managerial backgrounds who had thoughts on an ideal Linux distribution. As a gesture of thanks, we handed out the limited-edition swag units, all while introducing some friendly competition every now and then whenever a group appeared to keep things lively at our community booth.

Day One - IndiaFOSS 2026
Manifest I

In hindsight, the change in our approach towards engaging visitors, from a more passive Google Form during DevConf.IN 2026 to a more active human interview at IndiaFOSS 2026, felt well-guided. While being joined by Sudhir Dharanendraiah, the PyTorch representative, I also got to catch up with him after having met him about six months back. Amidst engaging with the booth visitors, Samyak and I did not realize how we ended up spending most of our time at our community booth itself, even when the designated duty was for the first two hours alone. That was, of course, not a problem; as Rajan mentioned, it was extremely appreciated that we were going above and beyond in steering the crowd of nearby attendees at the venue entrance towards our community booth. The two of us did find ourselves at our energy's limits as we temporarily wrapped things up around the lunchtime.

Day One - IndiaFOSS 2026
Manifest J

After a brief run-in with some familiar faces from the Debian Project, namely Ananthu CV and Abhijit PA, and also with some FOSSUnited organizers who came to us for sponsor feedback, we left for the food place. Getting visibly frustrated by the long queue at the serving area, we briefly considered heading out for lunch, only for us to realize later that there were few good places nearby. The closest one was a couple of kilometers away, and we would not be able to return in time if we were to travel there through Bengaluru's traffic. Turning back to the event lunch by around 0130pm Indian Standard Time, we found that the previously huge queue had subsided greatly by then. With no place to sit and eat, we resorted to refuelling ourselves with some Boiled Rice, Mattar Paneer, Mixed Vegetable, Chilled Raita, Warm Chapatis, and Gulab Jamun while standing near the rear exit of the venue.

Day One - IndiaFOSS 2026
Manifest K

Finishing off our food by around 0200pm Indian Standard Time, we still had half an hour more to kill before heading back to the community booth. We used this time to explore other community booths that were located at the event venue. It would have been a waste not to interact with FOSS friends from various teams just because we were too occupied representing our own. There was learning to be had, not just from the enthusiastic visitors coming to our booth, but also from being one of the visitors to the neighbouring booths. That led me to having a lively chat with the folks representing F-Droid about the recent unfair restrictions introduced by Google on certified Android handheld devices. Leaving Samyak in a quiet hall on the first floor to recover, I continued by myself to explore the booths on the other side of the event venue, which were mostly about the embedded electronics.

Day One - IndiaFOSS 2026
Manifest L

With its majority portion conveniently hidden behind thick vegetation, NIMHANS Convention Center Bengaluru was a deceptively huge location. I could not have guessed that there was an entire second part of the floor being shared by the Red Hat Community Booth with others because of the impressive floor planning. In the hardware section, the couple of event booths that caught my attention exhibited low-profile, manually crafted ergonomic mechanical keyboards and various useful ESP32-based trinkets. It was quite the coincidence to run into another FOSS friend whom we met during FOSSAsia 2026, Anuvrat Parashar, with whom I caught up and shared a few clicks. At around 0245pm Indian Standard Time, it was time for me to head back to our community booth for the second half of the Fedora Project representation duty and connect with Samyak for his assistance while returning.

Day One - IndiaFOSS 2026
Manifest M

Manoj Kumar Gupta, who was representing the virtualization team, remarked on just how influential Fedora Project's presence was at the community booth, all while reflecting on how the activity nearly died down in both Samyak's and my absence. He was right, though, as swag collectibles can be conversation starters for a bunch of people who might arrive at the event booth for collectible trinkets but also stay back for the interesting conversations that we have to offer. With our swag units displayed on the booth desk again and Samyak started the discussions, I got the FOSSUnited tees for us that Rajan had kept aside for the event sponsors. Seeking coffee with Sudhir at around 0400pm Indian Standard Time led us to have a great catch-up with him at the dining area. On heading back, Veer Kumar even graciously offered his specialized audio recording device for our interviews.

Day One - IndiaFOSS 2026
Manifest N

Being super occupied at the community booth, I could not attend Rajan's bite at the 2026 FOSSUnited GB Elections: Meet The Candidates Session. For someone who had been supporting Fedora Project's local presence in India as well as in the APAC region, it felt important to support him. Anyway, we started packing up the community booth at around 0515pm Indian Standard Time after attending to the booth visitors who had missed us during lunchtime. Thanks to Shivraj's query to the FOSSUnited personnel, we did not have to return to the hotel with all the booth supplies, as we could securely store them at the booth area. To ensure that Samyak had what he needed to organize the Fedora Linux 45 Release Party at a local university in the following month, I ensured that I passed on the limited swag units to him so that they could be returned before being used up on the next day.

Day One - IndiaFOSS 2026
Manifest O

For an in-person FOSS conference where Fedora Project could not timely secure a separate community booth, I scarcely imagined just how much attention we would eventually end up getting. With the folks from Red Hat being mutually supportive, since even they utilized Fedora Linux-powered Corporate Standard Builds on their work devices, this had been an experience like none other. Nine times out of ten, when Fedora Project was a conversation starter at our community booth, it was endearing to observe how most folks stayed back to learn more about projects like Shipwright, PyTorch, Tekton, Confidential Computing, and Ansible, etc. With our evening plans still being tentative at the time, our little Red Hat group decided to have some coffee on our way out. At around 0530pm Indian Standard Time, Samyak was finally able to book a returning Uber ride to take us back to the hotel.

Day One - IndiaFOSS 2026
Manifest P

The Bengaluru traffic situation only drifted from bad to worse as the sun started going down, so it took us a while to make it to the other side of the road where the auto-rickshaw had been waiting for us. We headed out once more on Deepesh's invitation to Brooks And Bonds Brewery at around 0730pm Indian Standard Time. Even though I did not hear back from Samyak for a little while when I had booked an Uber ride for us, he was swiftly available in the lobby area after a couple of hours of resting. Moving through the evening Bengaluru traffic, we were able to make it just in time to see Rajan, Shivraj, Veer Kumar, Gaurav, and Deepesh on their way upstairs in the building's elevator. For a dining experience that had been overbooked on that weekend evening, Deepesh definitely made the right call in booking us a large table well in advance to ensure that we were able to secure one.

Day One - IndiaFOSS 2026
Manifest Q

It was a lovely evening catching up with the folks over some nice drinks and tasty bites. Partitioning the dining table to place ourselves based on dietary preferences, we stuck around to see if we could get ourselves a table outdoors. With Samyak briefly checking with one of their attendees and returning empty-handed, we stuck around with the table that we had. Looking back on it, I would not have necessarily advised an outing like this in the evening if one was to wake up early the next day. I still found myself hanging back with the folks till 0130am Indian Standard Time. As luck would have had it, it was down to me again to set things up at the Red Hat Community Booth the next morning. I was uncertain about the task being fulfilled, so I wasted no time in falling asleep and recouping energy once Samyak and I were finally able to get an Uber ride back to the hotel at 0230am Indian Standard Time.

Ektu Bangla, to help kids to read Bengali

Posted by Kushal Das on 2026-10-13 15:14:18 UTC

Py (daughter) is still struggling to read Bengali text, as she was not reading it everyday. And on top of that Bengali script has many complex Bangla (Bengali) conjuncts (ক্ষ, জ্ঞ, ষ্ণ, ঙ্ক), and Py could not remember all the characters and had to go back and find them.

Reader/kid's view of the text

So now I am using https://ektubangla.org where anyone (a teacher/ parent) can click to "Create a session" and type in any Bengali text, and the students/readers can see the reader board where each word is broken into letters, so that the new reader can easily pick up what those letters are.

Writer view

The conjuncts are also colored differently in the text and broken into letters properly. Py is super happy to use to read much longer texts. I hope this will be helpful for more parents/teachers.

Fedora & CentOS at LinuxDays 2026

Posted by Jiri Eischmann on 2026-10-13 11:06:21 UTC

LinuxDays 2026, the largest open-source event in Czechia, took place on the first weekend of October, and we had a Fedora & CentOS booth there again. This time, we got a smaller table and our booth equipment was more modest because no one traveled from Brno by car—we only had what we could carry on the train. However, we had quite a few nice stickers and one Framework laptop, which generated a lot of attention again.

I was happy that I didn’t have to staff the booth alone; I was accompanied by Vojtěch Trefny, a long-time Fedora contributor.

Even though CentOS Stream has existed for seven years now, we still received questions like: “Oh, CentOS is still alive? I thought Red Hat killed it a long time ago.” This was typically the starting point for a conversation about the differences between the original CentOS and CentOS Stream, as well as their relation to Red Hat Enterprise Linux.

Most questions about Fedora were related to Framework, which didn’t come as a surprise given that we were showcasing Fedora Linux 45 on a Framework Laptop 16. People asked whether there is any cooperation between Fedora and Framework, whether Fedora Linux is a good OS for Framework hardware, and whether Framework is a good laptop option for Fedora Linux. To all of that, we had very positive answers.

It was an exhausting weekend because we had dozens of conversations, but it was also refreshing to meet Fedora and CentOS users and hear feedback directly from them. I’d like to thank Fedora for sponsoring my trip and Vojtěch for helping me with the booth.

From October 05 to October 11

Posted by Aurélien Bompard on 2026-10-13 09:10:00 UTC

Across the Fedora project this week, the primary focus is stabilizing the upcoming Fedora 45 release, which has officially entered its Final Freeze. Teams including Release Engineering, Quality, and various desktop and architecture groups are actively triaging blocker bugs, testing deliverables, and locking down infrastructure changes. Beyond the immediate release, a major collaborative focus is the newly named "Atomic Fusion" initiative, a strategic effort uniting the Atomic, CoreOS, IoT, and Hummingbird groups to design a unified, Konflux-built base image that minimizes attack surfaces by excluding tools like cloudinit and ignition. On the operational front, groups are heavily engaged in evaluating workflow tooling, marked by widespread assessments of a Bugzilla-to-Forgejo migration—which FESCo is currently pushing back against—and the rollout of LLM-powered community reporting tools, which prompted teams like Workstation and CoreOS to establish strict privacy and human-review boundaries. Finally, repository health remains a continuous cross-team priority, with FESCo, the Rust community, and NeuroFedora actively addressing orphaned packages and non-responsive maintainers to prevent downstream dependency breakages.

Announcements

On the development and infrastructure front, Fedora 45 has officially entered its final freeze, and an impact assessment for removing inactive packagers for the F45 release cycle lists potentially orphaned packages that currently need new maintainers. Infrastructure updates include detailed progress and plans for s390x improvements to address resource constraints, necessitating a planned s390x reboot. For QA and testing contributors, a Podman Test Week (also covered in a detailed Fedora Magazine article) invites help testing the Rust-based conmon v3, while community members continue to share advice on BTRFS system recovery methods.

Council

The Council held a bi-weekly meeting to discuss the F45 Final Freeze, finalize the new Decision Support Process, and begin brainstorming for Flock to Fedora 2027 Call for Proposals (CfP) themes. The Fedora Forge Usage Policy and Fedora Docs 2025 Initiative were formally closed following their approvals and updates, while @jflory7 was officially off-boarded from the Council following the end of his term as Fedora Community Architect.

New proposals were introduced regarding internal processes, including a non-binding "Sense of Council" vote process and making the Council Matrix channel publicly logged. A Bootable Image Unification Meeting also took place, where the team discussed Architecture Design Records (ADRs) and agreed on the project name "Atomic Fusion".

Decisions

Contribution opportunities

Learn more about the Council team.

FESCo

FESCo addressed several critical governance, security, and infrastructure topics this week. The committee continued pushing back on the proposed migration from Bugzilla to Forgejo due to major feature regressions (e.g., cross-repo searches, bug relationships) and discussed exploring a self-hosted or consultant-supported Bugzilla instance instead. Additionally, FESCo processed multiple non-responsive maintainer tickets, notably prioritizing the retirement of vulnerable NetworkManager VPN plugins (NetworkManager-vpnc and NetworkManager-fortisslvpn) going back to Fedora 43. This obsoletion will impact existing users but was deemed an unavoidable security measure to prevent privilege escalation.

Other highlights include the nomination of a new FESCo member (maxamillion) to fill a vacant seat, progressing the change to use Sequoia (%openpgpverify) for post-quantum cryptography, and reaffirming strict boundaries for provenpackagers regarding mass package changes.

Decisions

  • Retired and obsoleted NetworkManager-vpnc and NetworkManager-fortisslvpn across Fedora releases down to F43 due to unpatched privilege escalation vulnerabilities. (Ticket #3681)
  • Elected to mark fedora-third-party updates as a blocker for Fedora Linux 45. (Meeting Log, Ticket #3682)
  • Reaffirmed the provenpackager policy, specifically that provenpackagers must not perform mass cleanups or changes—such as converting to %autorelease or %autochangelog—without explicit maintainer permission. (Ticket #3687)
  • Nominated maxamillion to fill the vacant FESCo seat left by duffy's resignation, which he accepted. (Ticket #3689)
  • Processed non-responsive maintainer tickets for lkundrak, prarit, and gui1ty, resulting in the transfer to new volunteers or mass-orphaning of their respective packages. (Ticket #3681, Ticket #3665, Ticket #3678)

Learn more about the FESCo team.

Packaging Committee

This week, the Packaging Committee focused on two major themes: simplifying RPM snapshot versioning and updating Emacs packaging guidelines. Triggered by a recent versioning error in the bluez package that broke upgrade paths and caused openQA failures, the committee is heavily discussing a move to standardize snapshot versioning to a single, simpler format (<number>.<revision>) to prevent future mistakes (Issue #1570, Issue #1578).

Additionally, the group is modernizing its Emacs guidelines. This includes a new Work-in-Progress proposal to introduce RPM macros and dependency generators that natively support Emacs' built-in package management system, alongside finalized updates to existing Emacs packaging rules.

Decisions

  • The pure GTK Emacs build is now explicitly packaged under the name emacs-pgtk (Issue #1575).
  • The packaging guidelines were updated to clarify that Emacs 'compilation' refers strictly to byte compilation, distinguishing it from newer native compilation features (Issue #1574).

Learn more about the Packaging Committee team.

Mindshare

During the week of October 5 to October 11, 2026, the Mindshare committee actively cleared a backlog of event funding and swag requests while taking concrete steps to improve its own administrative efficiency. The committee successfully formalized a weekly meeting cadence—alternating between text and video formats—to curb previous delays in ticket resolutions.

Alongside standard event approvals, strategic discussions took place regarding the modernization of Fedora's physical event presence. This included plans to replace aging US and EU event boxes with new Pelican Air cases, the creation of a dedicated event box for India, and the production of localized tablecloths for EMEA events. Additionally, in response to persistently vacant seats on the committee, members proposed a structural change to allow rotating representation from active teams like Fedora Docs and Magazine, rather than static appointments.

Decisions

  • Decided that the Fedora Design team will no longer supply custom artwork for event badges; event organizers must now design their own badges and submit them for Mindshare approval with a 30-day lead time (Ticket #145).
  • Adopted a new weekly meeting cadence, alternating between text and video formats, to improve the committee's responsiveness to requests (Ticket #135).
  • Approved producing an EMEA-specific event tablecloth first before expanding regional physical assets to APAC (Ticket #119).
  • Maintained the current shared-responsibility model for Fedora's representation in the Digital Public Goods Alliance (Ticket #152).
  • Approved regional swag and travel budgets for Texas Linux Fest 2026 (Ticket #148), LinuxDays 2026 (Ticket #149), IndiaFOSS 2026 (Ticket #147), and a Polish technical school (Ticket #138).

Contribution opportunities

  • Provide feedback on the proposal to reconsider Mindshare Committee representation by rotating seats based on team activity and needs, potentially reallocating vacant CommOps or Marketing seats to the Fedora Docs or Magazine teams (Ticket #154, Ticket #145).
  • Weigh in on the idea to create a DIY printable "Ask me about Fedora" t-shirt design (complete with a QR code) for community members to wear at conferences where Fedora lacks an official booth (Ticket #99).
  • Mindshare Committee members are requested to pledge their timely availability to address recent delays in ticket voting and event curation (Ticket #153).

Learn more about the Mindshare team.

Fedora Join

This week, the Fedora Join group's primary focus was on addressing technical debt and improving the visibility of Fedora's web applications. Efforts are underway to update the outdated apps.fedoraproject.org directory. This exploratory project involves auditing existing applications, identifying unlisted infrastructure tools, and upgrading the web app's underlying Python software stack.

A community member has recently been assigned to take on this task as a "good first issue." The work will require collaboration with the broader Fedora Infrastructure team to ensure that the web directory accurately reflects the current state of active Fedora services.

Contribution opportunities

  • The task to update apps.fedoraproject.org was identified as an excellent "good first issue." Although a community member has begun the initial exploratory work, the effort requires reviewing current infrastructure, discovering missing tools, and potentially upgrading the codebase to support modern software versions, which may offer further avenues for collaboration.

Learn more about the Fedora Join team.

Workstation / GNOME

The Workstation / GNOME group focused on preparations for the Fedora 45 release, evaluating blocker bugs and freeze exceptions as the Final Freeze begins. A major technical priority was fixing integration issues for the new oo7-daemon (which replaces gnome-keyring-daemon), specifically ensuring its portal component is correctly installed on Silverblue and GNOME systems. Additionally, developers are actively scripting the automation of appstream-data generation to prevent GNOME Software and KDE Discover metadata from becoming outdated between releases.

In other discussions, the Working Group addressed third-party software requests and clarified questions about dependencies. The group also provided feedback on these weekly reports, requesting that human review remain in place to filter out irrelevant or personal information before publishing chat summaries.

Decisions

  • The Working Group rejected a proposal to include the proprietary, subscription-based LiveFaceSwap Desktop application in Fedora Workstation's third-party software discovery (Issue #530).
  • To resolve missing dependencies during the transition to oo7-daemon, xdg-desktop-portal-gnome will now explicitly require oo7-portal to ensure it is installed by default on GNOME and Silverblue variants (Issue #506).
  • The Working Group requested that human review of community posts and Matrix chat logs be required before including them in these automated weekly summaries, ensuring personal or irrelevant details are not broadcast (Issue #527).

Contribution opportunities

  • Vote on Fedora 45 Blockers: Community members are encouraged to vote on proposed blockers and freeze exceptions for Fedora 45 in the blockerbugs app before review meetings. Voting in advance helps shorten the meetings (Meeting Announcement).
  • AppStream Data Automation: There is ongoing work to automate the weekly generation of appstream-data. Contributors interested in packaging automation or verifying metadata diffs between Fedora versions can follow or assist in the progress (Issue #507).

Learn more about the Workstation / GNOME team.

KDE

The KDE group is preparing for the upcoming releases of KDE Plasma 6.8.0 and KDE Apps (Gear) 26.08.2. Due to the Fedora 45 final freeze, these major updates have already been pushed to Rawhide. For Fedora 44 and 45 users, the updates will be temporarily combined and made available via a COPR repository until the freeze is lifted and Fedora 45 is officially released.

In other news, the team is actively working on pulling the Union theme into Plasma Workspace, and preparations are underway for the Fedora 45 Blocker Review Meeting to finalize the upcoming OS release.

Decisions

  • KDE Plasma 6.8.0 and KDE Apps 26.08.2 updates will be delayed for Fedora 44 and 45 until the F45 final freeze concludes; they will be provided via a COPR repository in the interim.
  • The kgamma and kcm_wacomtablet packages will no longer receive updates and will be retired once Plasma 6.8 is released.
  • Due to a libplasma soname bump in the Plasma 6.8 update, several dependent packages (including merkuro, kweather, kclock, kalgebra, kcm-fcitx5, kup-backup, and applet-window-buttons) will be rebuilt.
  • The Union theme will be added to the KDE deliverables, starting with a recently rebased pull request for plasma-workspace.

Contribution opportunities

  • Contributors and upstream community members are needed to help plan and participate in the KDE Plasma 6.8.0 Test Day, including exploring testing methods for Kinoite.
  • Community members are encouraged to review and vote on F45 blocker bugs prior to the Fedora 45 Blocker Review Meetings using the blockerbugs app.

Learn more about the KDE team.

Server

The Server working group focused this week on F45 Beta release testing and advancing their Server Ansible support project. In F45 testing, initial-setup issues with the KVM image were successfully resolved, though some partition type issues with Kiwi persist. The group also briefly discussed aligning with the wider Fedora ecosystem by exploring a Borg-based backup solution, as backup coverage for F44 Server is currently lacking.

On the Ansible front, work is nearing completion to package the Server Ansible collection as an RPM, which will soon be released on Copr. Contributors identified idempotency and permission issues in the postinstall role, leading to plans to set up a molecule testing harness to test idempotence continuously. Finally, an announcement was shared on the mailing list regarding the upcoming F45 Blocker Review meeting for finalizing the release.

Decisions

  • The group decided to hold off on immediately fixing the Kiwi partition type issue, as it is non-blocking and can be corrected during post-installation.
  • Agreed to provision a dedicated VM for a molecule testing harness to ensure idempotence across the Ansible collection.

Contribution opportunities

  • Contributors are asked to keep an eye on the F45 Beta testing tickets and claim tasks by leaving a comment.
  • The working group is seeking help to draft the first versions of user documentation for their new Ansible support.
  • There is a known gap in backup strategies and coverage for F44 Server; contributors familiar with backup tools (like Borg) have an opportunity to help shape Server backup documentation and defaults.

Learn more about the Server team.

Infrastructure

The Infrastructure group entered the Fedora 45 Final Infrastructure Freeze on October 6th, locking down system changes until after the release. Operations this week involved handling s390x hypervisor memory issues, replacing a failing RAID controller on a Copr builder host, and resolving an EPEL 10 repository access issue caused by version differences between RHEL and CentOS Stream. Additionally, discussions continued on migrating from Bugzilla to Forgejo, tracking AWS resource costs, and optimizing LLM code reviews on Forgejo.

The team welcomed several new contributors this week and processed multiple new tracking groups in FAS (including Fedora Java Lounge, dpdk, Regolith, and Free Explorers) alongside updates to mailing list ownerships and documentation fixes.

Decisions

Contribution opportunities

  • Review untagged AWS resources older than 24 hours. Owners must add the FedoraGroup tag to prevent automated deletion.
  • Help is requested to create a playbook to automate the creation of tracking groups, which requires defining variables for description/display names and setting up FAS group configurations.
  • The team welcomes newcomers! Interested contributors are encouraged to read the Infrastructure Join Guide and start with good-first-issues or small ticket requests in #noc:fedoraproject.org.

Learn more about the Infrastructure team.

Release Engineering

This week, the Release Engineering team successfully initiated the Fedora 45 Final Freeze. The team managed several critical build and infrastructure issues, including fixing a permissions bug that caused 403 errors on PXE boot images, resolving an AWS IAM role policy issue that broke Fedora CoreOS uploads, and mitigating an XML parsing failure on Koji builders triggered by a Python 3.14 update.

Looking forward, discussions and preparations have begun for a major system-wide change in Fedora 46 to switch to the RPMv6 package format. The team plans to test the rollout conservatively in a side-tag using a few select packages before considering broader implementation.

Decisions

  • Fedora 45 officially entered its Final Freeze phase on October 6 (Issue #13544).
  • Bug 2540692 (Cannot authenticate to secure wifi during gnome-initial-setup) was accepted as a Fedora 45 Final Blocker during the October 5 Blocker Review meeting.
  • Bug 2545485 (Storage editor ignores BTRFS subvolumes under specific naming conditions) was rejected as a Final Blocker but accepted as a Freeze Exception during the October 5 Blocker Review meeting.
  • The Fedora-ELN-NetworkInstaller package was created in the eln tag so Fedora ELN can transition to using image-builder for building artifacts (Issue #13547).

Contribution opportunities

Learn more about the Release Engineering team.

Quality

The Quality team is highly focused on the final stages of the Fedora 45 release, which has officially entered the Final Freeze. Release validation is currently in progress, with strong test coverage and a relatively short blocker list. The team has been actively testing major new features, including kmscon userspace consoles and imagebuilder-built installer images, and recently discovered and fixed a longstanding bug affecting missing console keyboard layouts.

Test Days remain a major focus, with the Anaconda and CoreOS events concluding, and the Podman Conmon-v3 Test Days scheduled for mid-October. The team also conducted their weekly blocker review meeting, discussed streamlining predictable release chores by adding them to the automatic blockers list, and published the Q3 Heroes of Fedora Quality statistics to highlight and thank top community contributors.

Decisions

  • It was generally agreed on the mailing list to add 'updates-testing repository still being enabled' and 'fedora-release package having a release number lower than 1' to the automatic Final release blockers list to save time during future blocker reviews.
  • Bug 2540692 (Cannot authenticate to secure wifi during gnome-initial-setup) was officially accepted as a Fedora 45 Final Blocker.
  • Bug 2545485 (Storage editor ignores BTRFS subvolume(s) if partition has the same filesystem label) was rejected as a Final Blocker but accepted as a Final Freeze Exception.
  • Decision on Bug 2544626 (aarch Server DVD image install fails on RPi4 without network connection) was punted for a future meeting due to a lack of clear consensus.
  • To resolve ongoing CI frustrations in dist-git PRs, rpmlint spelling checks will be downgraded to output warnings rather than errors (Issue #591).

Contribution opportunities

Learn more about the Quality team.

Websites and Apps

The Websites and Apps team updated the Fedora download pages to visually highlight release-blocking deliverables with a star, clarifying for end users which images are fully tested by the Fedora Quality team versus those that are not. In the Fedora Websites Matrix room, the team discussed improving overall page load speeds by converting images to WebP format, bundling fonts, and downscaling new screenshots to 1360x768.

In the Fedora Apps Matrix room, a new build of Anitya was deployed to the staging environment for testing ahead of an upcoming release. The team also diagnosed a temporary rate-limiting issue with crates.io on release-monitoring, and clarified user confusion around the Badges admin interface, explaining that the UI remains visible but permission checks are safely performed retroactively when actions are attempted. Lastly, a forum discussion was started regarding the verbosity and excessive use of emojis in LLM-generated code reviews on Forgejo.

Decisions

  • Release-blocking deliverables on the Fedora download pages are now explicitly marked with a star to distinguish them from non-blocking images that lack guaranteed testing.
  • Secondary navigation bar logos on Fedora websites were updated to monochrome SVGs to improve visual consistency and reduce bandwidth.
  • New website screenshots for the upcoming Fedora 45 release will be scaled down to a 1360x768 resolution to help optimize page load times.

Contribution opportunities

  • Help is requested to update screenshots for Fedora 45 across all Editions, Spins, and Atomic Desktops.
  • There is an open opportunity to remove outdated references to Zanata in the event CMS templates and replace them with references to Fedora Weblate.
  • Contributors interested in website optimization can help investigate improving page load times by converting large images to the WebP format or bundling fonts.
  • There is a long-standing wishlist item to create reusable event-specific page templates for major events (like FOSDEM, SCaLE, and DevConf), which currently rely on the Fedora Wiki.

Learn more about the Websites and Apps team.

Design

The Fedora Design team delivered promotional graphics and visual assets for the upcoming F45 Virtual Release Party, including social media banners and streaming templates. The team also concluded an investigation into Bugzilla workflow dependencies, confirming they exclusively use Forgejo and will be unaffected by Bugzilla's upcoming retirement. Additionally, a pull request was submitted to add CSS branding for the new WebUI-based installer to the fedora-logos package.

In their weekly meeting, the team reviewed CDUX logo mockups and managed their backlog by closing stale tickets. To improve workflows, they are restructuring their ticket queues to separate feature improvements from operational tasks. Ongoing open tasks include creating a high-resolution logo for GDM to fix fractional scaling blurriness, designing the F46 beta wallpapers, and crafting an avatar for the Matrix moderation bot.

Decisions

  • Bugzilla Sunset Assessment: The team determined that the Bugzilla retirement will not impact their workflow, as they exclusively use Forgejo. No further migration planning is required for the Design group.
  • Ticket Queue Restructuring: The group decided to establish a separation between standard operational tasks and feature improvements, planning to use a feature/improvements label.
  • CDUX Logo Update: The team agreed to replace the fountain pen with a paintbrush in mockup 1C of the CDUX logo.

Contribution opportunities

  • Design event-kit hex stickers for CentOS and EPEL, as requested in the Matrix chat.
  • Provide a high-resolution (at least 600px width) SVG-derived Fedora logo to fix fractional scaling blurriness in the GDM greeter out-of-the-box experience (Issue #87).
  • Create a new avatar for the Matrix Moderation bot (Issue #68).
  • Help design the "Beta" wallpaper for Fedora 46 ahead of the mid-November deadline (Issue #77).
  • Conduct initial user experience research on existing Fedora remix sites and Jekyll themes for Project Resistor (Issue #84).

Learn more about the Design team.

Docs

This week, the Docs team focused heavily on restructuring their Antora site architecture to allow for flexible module inclusion across different Special Interest Groups (SIGs). They decided to merge components under the ROOT namespace to shorten URLs and simplify maintenance, a massive change that will be tested incrementally on a newly configured staging instance. Furthermore, the team made progress integrating new AI/ML SIG and Security team documentation into the main user documentation structure.

Additionally, the team prepared the Beginner's Guide for the upcoming Fedora 45 release, resolved accessibility issues with image descriptions, and advanced collaborative writing efforts with a live CryptPad instance running in CommuniShift.

Decisions

  • To accommodate cross-repository module inclusion (such as the new Security SIG user docs), all Docs repositories will transition to using ROOT as their antora.yml component name, which drops component names from the URLs altogether. This will be implemented and tested on a staging instance first, as discussed in Ticket #66 and the Oct 6 Meeting.
  • The Security team's new user-facing documentation module will temporarily be included at the Fedora Linux latest index until the repository grows large enough to warrant its own dedicated space (Ticket #65).
  • The obsolete prod branch in the builder repository will be renamed to main, pending successful testing on the staging Forge (Ticket #61).

Contribution opportunities

Learn more about the Docs team.

This week, the Legal group discussed the licensing of several projects and revisited existing policies. A significant portion of the conversation revolved around Fedora's policy on the CC0 license (also discussed here), which is currently restricted for software due to its explicit lack of patent grants. Despite user arguments to reconsider based on the license's "quiet enjoyment" waiver, legal experts maintained that the ban remains appropriate and aligns with both the license's original drafting history and current Free Software Foundation guidance.

Other discussions addressed specific packaging efforts. The Slint UI Framework was reviewed, and it was clarified that its GPL-3.0-only option is acceptable for packaging despite its broader dual-licensing and inbound MIT-0 contribution policy. Finally, a review of the koneko package determined that copyrighted third-party sprites must be removed at the source tarball stage to comply with distribution guidelines.

Decisions

  • The koneko package's source tarball must be modified to remove copyrighted Cardcaptor Sakura artwork before it can be packaged.
  • The Slint UI Framework is acceptable for packaging in Fedora under its GPL-3.0-only license option.

Learn more about the Legal team.

EPEL

This week, the EPEL team navigated tooling updates for the EPEL 10 transition, noting a bug in fedrq and a new mock release that simplifies repository configurations. In EPEL 9, Qt6 is being updated to version 6.10.3, which requires rebuilding a handful of dependent packages. Additionally, maintainers announced the retirement of several packages, and work continues on creating Koschei playbooks for minor End-of-Life and mass branching processes.

Decisions

Contribution opportunities

Learn more about the EPEL team.

ELN

During the October 6, 2026 meeting, the ELN SIG discussed the transition to building boot.iso with image-builder. Minor OpenQA failures were noted in Rawhide, prompting the team to postpone the switch for a week to allow the changes to stabilize before being pulled into RHEL and CentOS Stream. The group also reviewed ELN Extras build failures (FTBFS), noting ongoing fixes for OpenSSL 4.0 compatibility (the_foundation and libesmtp) and resolving KDE issues caused by missed rebuilds. Finally, the team addressed Bodhi updates getting stuck due to planned outages and agreed on a procedural change to prevent this in the future.

Decisions

  • The team decided to delay the switch to building boot.iso with image-builder until next week to let recent Rawhide changes stabilize (Releng Ticket #13547).
  • Infrastructure documentation and procedures will be updated to automatically pause and unpause elnbuildsync (EBS) during future planned outages to prevent updates from becoming stuck (Meeting Log).

Learn more about the ELN team.

Atomic

This week, the Atomic group focused heavily on the unification of Fedora CoreOS and Atomic efforts under the new project name, "Atomic Fusion." The team held their first dedicated video meeting to discuss Architectural Decision Records (ADRs), specifically focusing on a unified base image architecture built with Konflux, which excludes cloudinit and ignition to minimize attack surfaces. They also established standard operating procedures for the project, including a weekly Thursday video meeting cadence, a "Doacracy" work prioritization model, and utilizing a renamed Matrix channel for communication.

In addition to unification planning, several technical issues were addressed for Fedora 45. The group merged a change to use kmscon as the default VT console in F45, resolving dependencies to bring it to bootc base images. A packaging bug causing COSMIC Atomic spin rawhide composes to fail was fixed in the latest compose, and an update was pushed to fix a missing public key error during system upgrades. The team is also actively investigating a boot failure and emergency mode issue affecting users who upgrade on non-BTRFS filesystems.

Decisions

  • Fedora 45 will use kmscon as the default VT console for Atomic images (Source).
  • The official project name for the CoreOS and Atomic unification effort is "Atomic Fusion" (Source).
  • The team will prioritize work using a "Doacracy" model, meaning contributors who step up to do the work will set the immediate task priorities (Source).
  • Unification meetings will be held weekly over video on Thursdays, as listed on the Fedocal SIG calendar (Source).
  • The old initiative Matrix channel has been officially renamed to serve as the main workspace for unification discussions (Source).

Contribution opportunities

  • Help is requested to consolidate the initial Architectural Decision Record (ADR) subdecisions for the unified base image into a single reviewable pull request. Interested contributors should join the Bootable Image Unification channel on Matrix to coordinate (Source).
  • Community members are invited to participate in the CoreOS and Atomic Unification effort by joining the newly scheduled weekly video calls on Thursdays and assisting with the migration to the unified architecture.

Learn more about the Atomic team.

CoreOS

The Fedora CoreOS and bootc teams have officially begun merging their efforts, moving unification planning and architecture discussions to a dedicated Thursday video call, while leveraging the regular Wednesday meeting to handle current events, challenges, and tickets for both offerings. As the Fedora 45 Final Freeze is underway, several important fixes have successfully landed, including using kmscon as the default VT console, removing DTBs on aarch64 to save space in the boot partition, and officially declaring the composefs backend stable in bootc 1.17.0.

The community also addressed a slew of hardware and platform-specific pipeline issues this week. Notably, an AWS AMI import pipeline failure caused by a missing IAM role permission was resolved, and Azure Confidential VMs (CVMs) not picking up Ignition custom data was fixed via an upstream Ignition update. Meanwhile, the group agreed to use a build postprocess to patch dracut 111 errors on rawhide rather than continuing to wait on delayed upstream RPM backports.

Decisions

  • Decided to unify CoreOS and bootc community meetings and outputs, establishing a regular Thursday video call for architecture and planning.
  • Decided to remove Device Tree Blobs (DTBs) on aarch64 builds in Fedora 45 and later to save space in the /boot partition (#2222).
  • Decided to manually patch a known failing file in dracut directly during the build postprocess for Fedora \<= 46 instead of waiting on upstream RPM updates (#2206).
  • Decided to limit data collection for LLM-powered weekly reports strictly to official meeting logs and GitHub repositories, excluding raw chat conversations due to privacy concerns (#2223).

Contribution opportunities

  • Volunteers are needed to help clean up FCOS manifest overrides, which largely involves following up with upstream package maintainers. Interested contributors can reach out in the CoreOS meeting channel.
  • Contributors are invited to help write and consolidate Architectural Decision Records (ADRs) for the unified base image architecture. Interested parties should join the Bootable Image Unification channel on Matrix (as noted in the forum discussion).

Learn more about the CoreOS team.

IoT

This week, the IoT group focused on standardizing bootable image architectures and general repository housekeeping. The newly named "Atomic Fusion" project held a kickoff meeting for bootable image unification, proposing an Architectural Decision Record (ADR) that leverages container files and downstream variants while excluding cloudinit and ignition to minimize attack surfaces. They also recommended using Konflux as the standard build system for all Fedora bootable image outputs and systemd system extensions for platform-specific configurations.

In parallel, the team closed several long-standing tickets, highlighting that the Fedora ROS2 testing repository is now officially available in the ROS2 documentation as a result of collaboration with the Robotics SIG. Other closed trackers included updates for the deprecation of the Zezere provisioning tool, resolving Lua script upgrade errors, missing license files in osbuild installers, and initial bootc container builds.

Decisions

  • The bootable image unification project was officially named "Atomic Fusion".
  • Atomic Fusion's base image will exclude cloudinit and ignition to minimize attack surfaces, manage platform-specific configurations via systemd system extensions, and use Konflux as the standard build system for all Fedora bootable image outputs.
  • The Fedora ROS2 testing repository was officially declared available for use in the ROS2 documentation, expanding Fedora's support for robotics and factory automation use cases.

Contribution opportunities

Learn more about the IoT team.

ARM

The ARM community was notified of the upcoming Fedora 45 Blocker Review Meeting, scheduled for October 12, 2026, at 16:00 UTC on Matrix. The meeting will focus on evaluating 4 proposed blockers and 7 proposed freeze exceptions for the Final release to determine if they violate any release criteria.

Participants were strongly encouraged to review the bug lists and cast their votes ahead of time using the blockerbugs app, which helps streamline the meeting and reduce its overall duration.

Contribution opportunities

Learn more about the ARM team.

Alternative Images

The Alternative Images group met to discuss the upcoming quarterly image updates, which are targeted for release in roughly two weeks. A major highlight for this quarter's release will be the introduction of the project's first aarch64 raw images, generated using KIWI configuration.

In addition to the upcoming images, the team reported progress on building RISC-V packages for CentOS Stream 10 and processing Qt 6 updates for EPEL9. Testing for these alternative architectures has also improved, as team members noted that transitioning development laptops to Fedora CSB has successfully enabled multi-arch virtualization for local aarch64 and riscv image testing.

Contribution opportunities

  • Help is needed to patch or update obs-studio for EPEL9; it is currently failing to build during the Qt 6 updates because GUI-Private was removed in Qt 6.10 (Meeting log).

Learn more about the Alternative Images team.

Hummingbird

The Hummingbird group kicked off its video meeting cadence for the bootable image unification effort, which aims to merge the CoreOS and Atomic Initiatives. During the October 8 meeting, the team reviewed a proposed unified base image architecture that leverages container files and downstream variants, excluding cloudinit and ignition to minimize attack surfaces. They also discussed handling platform-specific configurations via systemd system extensions and recommended Konflux as the standard build system.

The group established a formal process using Architectural Decision Records (ADRs) to track project decisions. Moving forward, the team officially adopted "Atomic Fusion" as the project name and began scaffolding an umbrella ADR to consolidate their initial architectural choices into a single reviewable document.

Decisions

  • Accepted "Atomic Fusion" as the official project name for the bootable image unification effort (Original topic).
  • Adopted a formal Architectural Decision Record (ADR) management process, utilizing sequential numbering and proposal PRs to review and ratify architectural choices (Original topic).

Contribution opportunities

Learn more about the Hummingbird team.

Kernel

In a discussion regarding an RFC on splitting perf out of the kernel packaging, Fedora Python maintainers expressed a desire for the split. This separation would allow them to independently rebuild perf for Python packaging changes without requiring kernel-level signing permissions. However, other community members questioned whether this is a significant hurdle, noting that Rawhide kernels are already built almost daily to keep up with upstream changes.

Learn more about the Kernel team.

AI

The AI/ML SIG is making significant progress on the ROCm 10.1 stack, which is currently available in the preview COPR and compiling cleanly with downstream consumers like PyTorch. The updated toolchain introduces LLVM 24, preliminary support for the Khronos SPIR-V standard, and initial compiler support for the gfx1170 APU, with a multi-day Koji sidetag rebuild expected soon.

On the community front, the group agreed to enable an opt-in LLM summarization bot for the This Week in Fedora (TWIF) weekly reports to improve external visibility. Additionally, the SIG is debating a proposal to migrate documentation from the Fedora Wiki to Fedora Docs to align with standard project infrastructure, alongside discussions on authoring new beginner-friendly AI tutorials.

Decisions

  • Allow the This Week in Fedora (TWIF) summarization bot to ingest the public SIG Matrix chat history on a trial basis to generate weekly reports for the wider community (Ticket #39).
  • Relocate automated Forgejo bot notifications from the main Matrix room to a dedicated, opt-in alerts room to keep human discussions clear of clutter (Ticket #42).
  • Grant forge-ai-ml-owners membership to @jflory7 to manage organization-wide labels and webhooks on the Fedora Forge repositories (Ticket #41).

Contribution opportunities

  • Community members are invited to participate in the upcoming Fedora/RHEL/CentOS Leads (FRCL) open discussion on "Which LLM-gen-AI models are more aligned with Fedora?" scheduled for October 14 (Ticket #43).
  • Contributors are welcome to help draft and shape beginner-friendly getting-started guides for Fedora Linux, focusing on topics like local AI inference (Ollama, RamaLama), GPU tuning, and AI coding agents (Ticket #6).

Learn more about the AI team.

RISC-V

This week, the RISC-V team focused heavily on preparing Fedora 45 (successfully testing Server, Cloud, and Container images) and progressing the Fedora 46 sync, analyzing the content-set diffs compared to the main Koji. Significant effort was directed toward bootstrapping Fedora ELN for riscv64, which involved configuring Koji tags, managing test suite failures in problematic packages, and successfully building LLVM from vanilla Fedora sources.

Kernel development centered on the Omni kernel, with maintainers preparing to adopt the upstream kernel 7.3 for F45. The team also investigated a persistent GCC build segmentation fault on K3 hardware and actively participated remotely in the Linux Plumbers RISC-V Microconference.

Decisions

  • Disable the openmpi test suite on riscv64 due to persistent hardware-specific hangs to unblock the Fedora ELN bootstrap.
  • Remove the VF2 PCIe patch from the unpatched Fedora 7.3 kernel for Fedora 45, steering users of older hardware toward the Omni kernel instead.
  • Disable the MLIR execution engine in LLVM 21.1.1 for RISC-V to bypass unresolved test failures (Issue #2).
  • Hold off on manually fixing empty debugsource packages caused by lack of LTO, as GCC 17 will naturally resolve this issue later this year.

Contribution opportunities

Learn more about the RISC-V team.

NeuroFedora

The NeuroFedora group has successfully reached out to a non-responsive maintainer and consolidated admin rights for all neuro-packages to streamline review and cleanup efforts. This administrative update supports the team's ongoing initiative to reduce their Python packaging footprint by relying on direct installations from PyPI where appropriate. A dedicated test suite has been implemented to monitor the status of these packages and is now running regularly.

The group is currently reviewing packages that fail to install on Python 3.14 and 3.15 in the new test suite, and is considering limiting their automated tests strictly to pre-compiled wheels. Furthermore, team members have agreed to include their public activity in these weekly summaries for the Fedora community.

Decisions

Contribution opportunities

Learn more about the NeuroFedora team.

Perl

This week, the Perl group focused on maintaining and updating key packages, primarily resolving several lingering pull requests. Maintainers manually incorporated commits to update the rt (Request Tracker) package to version 5.0.10 after encountering merge conflicts, and a new draft pull request was recently opened to push rt further to version 6.0.3.

Additionally, housekeeping efforts led to the closure of older, redundant pull requests in rt and perl-Plack, while a dependency update was successfully merged for perl-Package-Generator to conditionalize Params::Util.

Decisions

Learn more about the Perl team.

Rust

This week, the Rust community was alerted to a looming issue affecting crun-vm builds. Fabio Valentini notified the maintainers that several of the project's dependencies are currently orphaned and are slated for removal from Fedora within the next one to two weeks. The affected packages include rust-rxml, rust-rxml_proc, rust-weak-table, rust-rxml_validation, and rust-minidom.

Contribution opportunities

  • Maintainers are urgently needed to take ownership of five orphaned Rust packages (rust-rxml, rust-rxml_proc, rust-weak-table, rust-rxml_validation, and rust-minidom). Community members must step up to unorphan these packages to prevent crun-vm builds from breaking due to missing dependencies.

Learn more about the Rust team.

Other Discussions

  • Shivank Sharma asked if signing the Fedora Project Contributor Agreement (FPCA) automatically grants access to award badges. Akashdeep Dhar clarified that while the admin frontend becomes visible, the user's authorizations dictate which badges they can actually award.
  • Miroslav Suchý shared a list of newly added packages in Fedora Linux for September 2026, generated from the rawhide-changes script.
  • Gordon Messmer inquired about how to contact the crypto team to add AWS s2n-tls to Fedora, noting that their mailing list is closed to non-members. Dmitry Belyavskiy offered to discuss the issue at the upcoming OpenSSL conference.
  • Abdallah Shehawey proposed packaging a source-only version of whatsapp-desktop relying on a system-provided Electron runtime. The discussion highlighted the challenges of maintaining multiple Electron versions in Fedora and keeping dependent packages synced.
  • Fabio Valentini reached out to find the maintainer of julia, noting that unmerged pull requests are causing FTBFS errors in Fedora 45 and that the non-responsive maintainer process has been initiated.
  • Alejandro Lopez asked why rpminspect was reporting insecure mode failures for a sudo merge request on ELN. Dave Cantrell explained that the rpminspect environment lacked a product definition for ELN, leading to the creation of a new tracking ticket.
  • Michel Lind proposed splitting the perf tool out of the kernel packaging to reduce build requirements, simplify the package spec, and avoid requiring kernel rebuilds when updating Python packaging.
  • Julian Sikorski asked for advice on adding openh264 as a build requirement for MAME. Neal Gompa and Michael J Gruber recommended using the system package via pkgconfig and stripping the bundled source from the tarball during the prep phase to avoid patent issues.
  • Chih-Tao Lee initiated a non-responsive maintainer check for python-authlib and successfully stepped up to co-maintain it alongside the RHEL Lightspeed group.
  • Aoife Moloney shared the summary of the latest Fedora Council meeting, noting an agreement to implement a "Decision Support Process" instead of strict Conflict of Interest Guidelines, and starting discussions for Flock 2027 CfP themes.
  • Other discussions included a reminder for the Fedora 45 Blocker Review Meeting, a review request for coconut-svsm for confidential computing, a non-responsive maintainer check for Luis Bazan, deleted branches and commits in the glibc-maintainer-scripts repo on the glibc mailing list, and updates in the Fedora Docs Matrix channel covering pull requests for image accessibility, rebuilding site scripts, and FIDO2 PIN commands.

Orphaning packages

  • Michael Catanzaro announced he is orphaning WebKitGTK across all branches due to leaving his job, with Fabio Valentini volunteering to take over maintenance.
  • Benson Muite announced the orphaning of python-proton-vpn-network-manager due to lack of time to maintain its required dependencies, which now involve Rust.

Package updates

  • Richard Shaw updated OpenColorIO to version 2.6, handling an upstream SONAME bump and successfully rebuilding all dependent packages.
  • Kaleb Keithley announced an update to Apache Arrow 26.0.0, which includes a libarrow SONAME bump and requires rebuilding dependent packages like ceph and gdal in a side tag.
  • Antonio Trande announced that PETSc is being updated to 3.26 in Rawhide and F45, and listed the dependencies that require rebuilding.
  • Stephen Gallagher warned of a backwards-incompatible update to python-openai 3.24.0 in Rawhide and F45, making HTTPX2 the default and removing deprecated CLI tools.

New contributors

  • Andrew Heath introduced themselves, sharing a decade of enterprise Linux and infrastructure-as-code experience, and is looking for a sponsor to help with packaging, image building, and QA.

All contribution opportunities

Contributors with a passion for Quality Assurance and Testing have numerous accessible entry points to help ensure a stable release. Community members are highly encouraged to shorten review meetings by voting early on proposed Fedora 45 blockers and freeze exceptions for Workstation, KDE, ARM, and Release Engineering using the blockerbugs app. Hands-on testers can jump into the Podman Conmon-v3 Test Days or the KDE Plasma 6.8.0 Test Day. If you prefer trying out new builds, you can claim F45 Beta Server testing tickets, run bare-metal installations on Beaker hardware, or test upcoming RISC-V images.

Those skilled in Technical Writing, Community Feedback, and Documentation can make an immediate impact without deep technical onboarding. Writers and editors are needed to proofread the Beginner's Guide Vorta backup section, draft new AI getting-started guides, and create documentation for Server's new Ansible support. Reviewers can also provide valuable insights by suggesting missing commands for a Git cheat sheet, testing a collaborative Cryptpad instance, or weighing in on broad ecosystem changes like the RPMv6 format transition (feedback ticket) and AI model alignment. Additionally, contributors can help coordinate cross-team efforts by reviewing Bootable Image Unification ADRs or sharing thoughts on Mindshare's committee representation adjustments.

For contributors specializing in Design, Web Development, and Automation, several creative and structural tasks are open. Designers are invited to create CentOS/EPEL hex stickers, design the F46 Beta wallpaper, craft an avatar for the Matrix Moderation bot, and supply a high-resolution SVG Fedora logo for GDM. Web developers can help update apps.fedoraproject.org, replace outdated Zanata references with Fedora Weblate in CMS templates, and assist with website optimization and reusable event templates. Meanwhile, scripters and automation enthusiasts can improve infrastructure by automating AppStream data generation, tester statistics (Heroes of Fedora), mediakit checksums, and Infrastructure tracking groups.

Finally, experts in Software Packaging, Debugging, and Systems Engineering are in high demand to maintain the ecosystem's backbone. C/C++ developers can assist in resolving a GCC build segmentation fault on RISC-V K3 hardware or fixing obs-studio build failures against the new Qt 6.10 framework in EPEL. Maintainers are urgently needed to adopt five critical orphaned Rust packages to prevent VM build breakages, alongside other tools like julia and transifex-client. Systems engineers can make an impact by reviewing untagged AWS resources, evaluating Python test suite restrictions, or assisting with the CoreOS and Atomic unification migration. Members with strong leadership experience can also step up to sponsor the Fedora Docs 2025 Initiative.

Managing multiple Git repos with AI: How I keep up with Fedora's sprawl

Posted by Justin Wheeler on 2026-10-13 08:00:00 UTC
Managing multiple Git repos with AI: How I keep up with Fedora&#39;s sprawl

No single person can know everything happening in Fedora at any given time. I say this often in our community, half as a warning and half for comfort. For a while, I did not really believe it applied to me. I wanted to know everything. I joined new teams, participated in tickets, and either participated or led meetings across the project. Surprisingly, as a young university student, I held a vast amount of it in my head.

But Fedora does not stand still long enough for that to last. Eventually, I was spread thin across more teams than I could realistically track. As my academic load increased or I began an internship, promises I made quietly fell off my radar. It was not because I did not care. It was because the systems I used to track them could not keep up with the sprawl, when my available time to contribute changed.

However, as I reentered the Fedora community as a Red Hat employee, the same systems I used as a student were challenged. As I get going with my new role, I am rethinking how I can rebalance my bandwidth sustainably. So, this post is about how I started managing multiple Git repos with AI agents to claw back some of that bandwidth. It is not really a story about a remarkable tool. It is an argument that in a project this sprawling, protecting your attention is the real win. I will cover two moments when things fell through the cracks, the workflow I built to catch them, a real example of it working, and an honest take on trusting AI when it sometimes gets things wrong.

Why managing multiple Git repos gets hard at Fedora’s scale

Fedora is sprawling. Fedora’s distribution Git (dist-git), the home for package sources, holds something like 20,000 packages. Add the team and SIG repositories that coordinate the people behind those packages on Fedora Forge, and the number of places where decisions get made is enormous. Yet, most contributors only touch a handful of them. However, even a handful is often scattered across different platforms, with no single view of all of it.

Where things fell through the cracks

Before this workflow, it felt like pure chaos, and I have the scars to prove it. Fedora runs on mailing lists, Fedora Discussion topics, Matrix chat rooms, and Fedora Forge issues/tickets. Furthermore, all of these are spread across dozens of teams, Working Groups (WGs), and Special Interest Groups (SIGs). In short, there are a lot of different places to follow a lot of different things.

For a long stretch, the Fedora Marketing Team had a backlog of tickets. In a few cases, contributors asked for talks and presentations to be uploaded to the Fedora YouTube channel. I had the access to do it and other YouTube maintainers were no longer active, so therefore, it was quietly mine to own. I saw the tickets at least once, but I was overworked and busy with higher-priority work. The YouTube videos slid off my list. A new volunteer eventually picked them up months or even a year later.

Additionally, Fedora also runs meetings well… on paper. Fedora holds virtual text meetings in Matrix chat rooms with a bot that logs everything. Each meeting has a clear start, a clear end, and annotated topics. But a faithful log is not the same as follow-through. For example, in AI/ML SIG meetings, we discuss a decision or someone takes an action item, and it gets logged. But it does not always make it back into the relevant ticket or discussion post. The record exists, but it does not connect itself to the places that need updating.

Patterns like this repeat themselves. The examples above are merely specific examples of where things fall through the cracks. However, there are things like this that happen everyday in different corners of the community too.

The AI multi-repo workflow

So, here is the workflow I use now. It does not get rid of all the chaos, but it helps me manage it much better. First, I point an LLM-gen-AI agent at a directory holding several cloned Git repositories. For example, the AI/ML SIG docs repository, AI/ML SIG tickets repository, and Agent Skills library. Then I ask it to analyze across all of them.

I also feed it meeting logs or summaries. I ask it to cross-check them against open tickets and Fedora Discussion topics:

  • Did we document the decisions?

  • Did we track the action items?

  • Is anyone still waiting on a reply?

Critically, I do not want it reading only files from my local git clones. I want it to query the remotes too: the Fedora Forge API, issues, discussions, and more. The underlying Forgejo API is enormous. It lets the agent track the actual cadence a team works at, not just a snapshot.

A word on trust and hallucination

I have to be honest here: the agent sometimes gets things wrong. It will occasionally misread a thread or hallucinate a detail. However, I do not think that disqualifies it. Humans get things wrong too. I would rather have slightly imperfect visibility into tens, hundreds, or even thousands of repositories than none at all. Ultimately, the question is not whether the agent is ever wrong. The question is what level of risk you are willing to accept for the visibility you gain.

A real example: Reviewer guidelines across three repos

Our Fedora Agent Skills Library needed reviewer guidelines. Laura Barcziová (@lbarczio), on our reviewer team, wrote a solid REVIEWING.md in the ai-ml/skills-library repo. But our separate ai-ml/docs repository only had a page on creating a skill, and nothing on reviewing one.

I used an agent in OpenCode to pull discussion context from Fedora Forge issues about our reviewer process. It helped me reconcile that context with Laura’s draft. Then I orchestrated multiple Pull Requests across the repositories at once. This brought the AI/ML SIG docs site in line with what the team had actually decided.

The real payoff is not the tool

In conclusion, the payoff is that it hands me back the capacity to zoom out. In a project where nobody can hold it all in their head, something should watch dozens of repositories. It surfaces what changed and what needs to catch up. That means I can engage with people’s feedback instead of just surviving the volume of it. When someone takes the time to review my Pull Request, I want the bandwidth to genuinely consider what they said. I do not want to just clear my queue.

I hope this overview of my flow and process is insightful. As of yet, I do not have a commenting feature on my blog, although I am looking into this. Tag me in a LinkedIn post and we can continue the conversation there.

ICFK 2026: Calligraphy Festival

Posted by Rajeesh KV on 2026-10-12 11:58:38 UTC

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.

Keeping secrets out of my AI agents

Posted by Miroslav Vadkerti on 2026-10-12 00:00:00 UTC
I started with API keys and tokens leaking into agent context, went through CLAUDE.md rules and fetching secrets on demand from 1Password, and ended up at sandboxed agents, MCP servers that hold the credentials, and one-hour GitHub and GitLab tokens on a dedicated identity.

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

Posted by Guillaume Kulakowski on 2026-10-11 16:26:41 UTC
Découvrez les nouveautés de SeedboxSync v4.3 : migration vers Bootstrap, refonte du dashboard et des statistiques, rendu CLI modernisé avec rich.table, ajout d'un widget pour Homepage et correction d'un bug critique sur les arborescences profondes.

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

Posted by Guillaume Kulakowski on 2026-10-10 13:33:57 UTC
Retour d'expérience sur ma migration vers Fedora 45 bêta sur mon laptop Asus : mise à jour fluide, déplacement des fichiers de configuration des dépôts vers /usr/share/dnf5/repos.d, migration de mes paquets Copr, bascule de mes Flatpaks du système vers le profil utilisateur et sélection de quelques indispensables.

Maintainer Summit - IndiaFOSS 2026

Posted by Akashdeep Dhar on 2026-10-09 18:30:25 UTC

Theme

Experience

Maintainer Summit - IndiaFOSS 2026

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!

Maintainer Summit - IndiaFOSS 2026
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.

Maintainer Summit - IndiaFOSS 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.

Maintainer Summit - IndiaFOSS 2026
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.

Maintainer Summit - IndiaFOSS 2026
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.

Maintainer Summit - IndiaFOSS 2026
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.

Maintainer Summit - IndiaFOSS 2026
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.

🎲 PHP version 8.4.27RC1 and 8.5.12RC1

Posted by Remi Collet on 2026-10-09 05:00:00 UTC

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

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

🎲 PHP on the road to the 8.6.0 release

Posted by Remi Collet on 2026-09-30 06:08:00 UTC

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)

Friday Links 26-31

Posted by Christof Damian on 2026-10-08 22:00:00 UTC
Blue Windows update screen: Working on updates 75%, don't turn off your PC

Good long reads this week: Camille Fournier on the manager’s path in the age of AI and how AI affects building things by Paulo André.

Quote of the Week
The first rule is that a measurement—any measurement—is better than none.
High Output Management
Andrew S. Grove

Leadership

If your team is happy, are you doing a good job? - it’s a business and happy means different things to different people.

Heroes of Fedora Quality for Q3 2026

Posted by Kamil Páral on 2026-10-08 13:28:54 UTC

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 commented1: 8077

NameUpdates commented
Geraldo S. Simião Kutz (geraldosimiao)1526
Ephraim Kaov (ephmo)1370
Derek Enz (derekenz)1332
Filipe Rosset (filiperosset)772
besser82423
bojan260
Ian Laurie (nixuser)210
Eugene Mah (imabug)163
anotheruser154
Colin Thomson (g6avk)111
Joe Ant (maketopsite)92
Adam Williamson (adamwill)82
markec78
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
itrymybest8021
Neeraj Kumar (rai510)17
xvitaly16
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
lakhsa11
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!

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

NameTest cases executed
tagoh36
derekenz28
ephmo28
mcrha23
pnemade22
smjagtap22
adriend22
clnetbox21
romeo-5520
pschindl19
toodz8919
psklenar17
modehnal16
oholy15
axelzenzu14
pacorro200014
lruzicka14
vcholasta14
developer113
feborges12
romangherta12
vhumpa12
jgrulich12
mtadault11
luya9
geraldosimiao9
bohdan_milar7
lpavan7
ersen7
pyadav7
jandemus7
abdallahleandro7
panayang7
vlcekpavel936
nielsenb6
imabug6
tharadash6
guiltydoggy6
jgroman6
kengou5
kanru5
rvykydal5

…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.

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

Posted by Fedora Magazine on 2026-10-07 16:25:50 UTC

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.

Using syslog-ng with OpenSearch 3.9

Posted by Peter Czanik on 2026-10-06 14:07:57 UTC

Does syslog-ng support the latest OpenSearch version? I suspected that the answer was yes, but I gave it a try anyway. And as expected, starting to use OpenSearch 3.9 with syslog-ng is a smooth experience. My only problem? Finding a password complex enough for OpenSearch.

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

syslog-ng logo

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

Posted by Guillaume Kulakowski on 2026-10-05 18:24:59 UTC
Après 12 ans, ma balance Withings a rendu l'âme. L'occasion idéale pour abandonner MyFitnessPal, auto-héberger la synchronisation de mes données de poids vers Garmin et automatiser le flux vers Strava via n8n.

From September 28 to October 04

Posted by Aurélien Bompard on 2026-10-05 09:38:00 UTC

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

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

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

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

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

Contribution opportunities

Learn more about the Docs team.

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

Contribution opportunities

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

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

Contribution opportunities

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

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

Contribution opportunities

Learn more about the Python team.

Other Discussions

Package Orphaning

Package Updates

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.

misc fedora bits: first week of october 2026

Posted by Kevin Fenzi on 2026-10-04 23:24:29 UTC
Scrye into the crystal ball

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 Forge outage

Posted by Fedora Infrastructure Status on 2026-10-04 08:00:00 UTC

forge.fedoraproject.org is currently down. We are investigating and hope to restore service soon.

Update 2026-10-04 16:15UTC: service has been restored.

iCloud and CalDAV

Posted by Tristan Partin on 2026-10-03 15:29:36 UTC

Recently I’ve become quite a calendar afficianado. However, I ran into a problem with iCloud and CalDAV that I would like to share.

Code samples on GitHub

Posted by Phil Wyett on 2026-10-03 10:39:00 UTC
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

The Era of Software Quality, or the Era of Ostriches?

Posted by Michael Catanzaro on 2026-10-02 18:08:21 UTC

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:

YearGNOME CVEsGNOME CVEs Excluding GIMP, Gegl, libxml2, and libxslt
20212114
2022146
2023134
20243728
20259749
2026 Year-to-date (2026-09-30)14174
2026 Normalized188 (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:

YearWebKitGTK CVEs
2015175
201657
2017158
2018101
201999
202038
202152
202250
202345
202438
202566
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:

YearReports SubmittedReports Accepted
20242614
202515033
202612224
Total29871

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.

Change naming of screenshots under MacOS 27

Posted by Phil Wyett on 2026-10-02 17:53:00 UTC
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.

Elegoo Neptune Pro 3 - Playing and Learning

Posted by Phil Wyett on 2026-10-02 17:30:00 UTC
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.

Elegoo Slicer

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.

How to Request a CVE

Posted by Michael Catanzaro on 2026-10-02 15:00:15 UTC

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.

Friday Links 26-30

Posted by Christof Damian on 2026-10-01 22:00:00 UTC
Rows of shiny CDs reflecting blue and purple light

Quick one this week. I really liked the sustainability post by Etsy. They are about measuring stuff and advocating for change in the industry.

Quote of the Week
How does a manager motivate his subordinates? For most of us, the word implies doing something to another person. But I don’t think that can happen, because motivation has to come from within somebody. Accordingly, all a manager can do is create an environment in which motivated people can flourish.
High Output Management
Andrew S. Grove

Leadership

The simple answer to improving productivity: asking employees [Podcast] - I really wish more organisations would take employee surveys more seriously.

Updates and reboots on Fedora infrastructure

Posted by Fedora Infrastructure Status on 2026-10-01 20:00:00 UTC

Fedora Infrastructure team will be applying updates to servers and rebooting them.

Many services will be affected, most should only be down for a short time as their particular resources are rebooted HOWEVER some may be down for a non-trivial amount of time due to firmware upgrades.

Fedora Copr outage - updating servers

Posted by Fedora Infrastructure Status on 2026-10-01 06:00:00 UTC

There will be a Fedora Copr outage while we upgrade infrastructure machines to the latest Copr packages.

The build queue processing will be stopped during the outage, and the Frontend/Web-UI will be down most of the time (no new tasks accepted). The DNF packages and repositories (hosted on copr-backend …

XScreenSaver on Fedora Wayland with retrosaver

Posted by Christof Damian on 2026-09-30 22:00:00 UTC
Two monitors on a desk with the XScreenSaver module bubblecolors stretched across both screens

Since I switched to GNOME and Wayland on my desktop I have been missing XScreenSaver.

JWZ is rightly not planning to add support for this unless there are some significant changes in GNOME.

I felt left out whenever I saw a new version with new hacks being released.

Recently I stumbled over retrosaver by c-premus. It is basically a workaround to run the hacks on GNOME Wayland. It doesn’t lock the screen and leaves that to GNOME, so it isn’t really a replacement for XScreenSaver. At home, this is probably good enough.

Providing project emails

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

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.

Back again...

Posted by Phil Wyett on 2026-09-30 10:03:00 UTC
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.

🎲 PHP 8.6 as Software Collection

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

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)

Anaconda F45 features Test Week

Posted by Fedora Community Blog on 2026-09-29 14:08:36 UTC

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 Shines Blue at Software Freedom Day Bukidnon 2026

Posted by Fedora Community Blog on 2026-09-29 12:00:00 UTC

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 Partners and Sponsors
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:

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
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.

Snapdragon X1 laptop kernel COPR for Fedora 45

Posted by Hans de Goede on 2026-09-28 13:28:21 UTC
I'm happy to announce the availability of a COPR repository which rebuilds Fedora 45 kernels with the patches from the qcom-laptops git branch added. This is a branch where various upstream pending patches with Snapdragon laptop improvements are gathered. For the exact contents of the latest kernel from this COPR see this Fedora kernel git-repo fork.

Installing the kernel from this COPR adds camera support for various X1 laptop models, adds bluetooth support for the ThinkPad T14s as well various other improvements. Most of these are expected to land in the 7.4 kernel.



comment count unavailable comments

Snapdragon X1 laptops improvements in Fedora 45

Posted by Hans de Goede on 2026-09-28 13:06:13 UTC

After the initial work to make Fedora live iso media boot OOTB on Snapdragon X1 laptops in Fedora 44, I've continued working on improving the Fedora experience on these laptops for Fedora 45. For Fedora 44 a long list of workarounds was necessary, see the Snapdragon laptop install instructions on the wiki.

For Fedora 45 various improvements have been made in the mainline kernel and I've been working on improvements at the initramfs generator / distro level. Together these result in a much smoother experience, see the install instructions for Fedora 45 on the wiki. A few workarounds are unfortunately still necessary for Fedora 45. For Fedora 46 I hope that the Fedora aarch64 live iso media will just work on X1 laptops.

Note that this blog post is about Snapdragon X1 (Elite,Plus) laptops. Support for Snapdragon X2 laptops at the same level as the current X1 laptop support is quickly coming together in the mainline kernel. But the 7.2 kernel used for the Fedora 45 beta and release isos is still missing some bits and Devicetrees, so Fedora 45 will not work OOTB on Snapdragon X2 laptops.



comment count unavailable comments

Speaking at FOSS United Chennai: Fedora, Forgejo, and a Live Demo Fumble

Posted by Yashwanth Rathakrishnan on 2026-09-28 11:24:30 UTC
A candid recap of representing Fedora at FOSS United Chennai, navigating an unexpected live demo mistake, and finding inspiration in the local community.

From September 21 to September 27

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

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

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

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

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

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

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

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

Orphaning packages

Package updates

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.

misc fedora bits: fourth week of sep 2026

Posted by Kevin Fenzi on 2026-09-26 17:15:38 UTC
Scrye into the crystal ball

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

Migration UI de SeedboxSync : De Bulma à Bootstrap

Posted by Guillaume Kulakowski on 2026-09-26 13:12:20 UTC
Retour sur la migration UI de SeedboxSync de Bulma vers Bootstrap : pourquoi quitter un écosystème au ralenti, les limites de Bootstrap (Dart Sass, dark mode JS, balise progress) et les gains d'un framework riche en composants.

Cohesive Linux

Posted by Simon de Vlieger on 2026-09-25 09:00:00 UTC
Cohesive Linux Over the past few years I’ve been in contact with and working with “image-based” Linux systems and grown fond of the ideas and possibilities they offer while being wary of the things they can take away from tinkerers and hackers (in the correct sense of the word). My work has mostly been on the Fedora side of things and the implementations of “image-based” Linux there through ostree and nowadays bootc.

Installing Navidrome on Fedora Linux using Podman

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

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.

🛡️ PHP version 8.2.34, 8.3.35, 8.4.26 and 8.5.11

Posted by Remi Collet on 2026-09-25 06:00:00 UTC

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:

⚠️ To be noticed :

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

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)

Friday Links 26-29

Posted by Christof Damian on 2026-09-24 22:00:00 UTC
The original Fozzie Bear puppet on display at the Bear House by Newby Hall
Photo: Northerner, Wikimedia Commons — CC BY-SA 4.0

A bit of a catch-up from recent weeks today. I recommend the two Book Overflow episodes about The Pragmatic Programmer and with Uncle Bob. The long post from Charity about Slop is also worth a read.

Quote of the Week
Another benefit of writing a test for every logged message is that it’s painful. Sometimes pain is a good thing.
Agile Java™
Jeff Langr

Leadership

Managers Are Catalysts - “Your job, as a manager, is lowering that activation energy.”

New badge: ESC member !

Posted by Fedora Badges on 2026-09-24 19:26:43 UTC
ESC memberYou have been a member of the EPEL Steering Committee

New blog who dis?

Posted by Jef Spaleta on 2026-09-23 16:02:35 UTC

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.

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

Posted by Guillaume Kulakowski on 2026-09-23 10:52:00 UTC
L'annonce de Portainer 3.0 confirme le virage stratégique de l'éditeur vers Kubernetes et les besoins des entreprises, laissant la version CE sur la branche 2.x. Un changement de cap qui confirme la pertinence de ma récente migration vers Arcane pour la gestion des conteneurs de mon NAS.

⚙️ PHP version 8.4.25 and 8.5.10

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

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

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

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

ℹ️ The packages are available for x86_64 and aarch64.

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

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

Version announcements:

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

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.5 as Software Collection

yum install php85

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

⚠️ To be noticed :

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

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)

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

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

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

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

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

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

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

ℹ️ The packages are available for x86_64 and aarch64.

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

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

Version announcements:

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

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.5 as Software Collection

yum install php85

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

⚠️ To be noticed :

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

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)