We will be rebooting our vpn hub / smtp gateway / bastion hosts in order to apply a new kernel to mitigate possible CVEs.
The outage should hopefully only take a few minutes.
We will be rebooting our vpn hub / smtp gateway / bastion hosts in order to apply a new kernel to mitigate possible CVEs.
The outage should hopefully only take a few minutes.
admin )
on 2026-11-06 11:00:00 UTC
The forge.fedoraproject.org is down because of space issue. We are currently working on fixing it. You can watch the progress in https://matrix.to/#/#forge:fedoraproject.org
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.13RC1 are available
RPMs of PHP version 8.4.23RC1 are available
ā¹ļø 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:
Software Collections (php84, php85)
Base packages (php)
For many years, I have managed all my systems with Ansible. For a similar amount of time, I have used Nebula as my VPN of choice, so I can always connect securely to all my systems, even on the move.
There are no official Ansible modules for Nebula, so over the years many people asked me how I manage it. I changed my approach over time. Although my previous iterations worked, I wasn’t satisfied enough to share the details. I’m now at a point where I think the process is fairly good, so here I am.
I am sure I am not the only in this situation. There are more Open Source maintainers and defenders who are in the same situation. From last July I started poking into various libraries/projects/deployments of open source projects to find vulnerabilites, and it became very tiring 16+ hours long days. As of today morning I found 90+ such issues, many are in projects written or used by Sunet, many has other bigger userbase too.
The things I am poking at are boring Infrastructure pieces. "National Research and Education Network/NREN" (s) in every country are not the top receivers of grant money. Small number of people working years after years to keep the infrastructure on.
And not many are that lucky to have access to the modern LLMs or knowldge on how to use them to find and fix issues. I am lucky and thankful to Anthropic and OpenAI that they provided me with access to latest models with capabilities to do this work. But, not many has it, this crates too much pressure in my mind, and for sure friends told me similar stories (in other fields). To defend Sweden (or your respective country) we will need more capabilites and compute/hardware and people willing to do this work. Where we are not dependent on another country's political views to defend our own country.
Many will say open weight models will solve this. If you only think about capabilities, yes they are catching up. Funniest part for me was that I used an open weight model and found 4 different zero days in 4 java libraries (they are all now fixed) and chained them to bypass validation of particular checks for digital signatures as my first finding (using LLMs) back in July. But, using open weights are either not allowed at every place or folks don't have hardware. We need powerful hardware to be able to defend. A lot of decisions have to made in various levels of our societies to make this happen. And I don't think we will not see much progress so easily.
On the other hand attackers using $25 and access to same capabilities to attack. Nation state level actors are now many more times efficient due to both brain power and money they can spend.
I hope the pace of finding new bugs will come down a bit in 2 years, but not sure how many of us will not be burnt out by then.
Note: many of you may ask me about technical details of the findings or what I am using specifically. That would require multiple other posts for me to explain, but you can just start poking with whatever you have. For example today morning's finding to another big project was using just Pi. No special sauce. Just poking and providing input to the model to guide it. But if I just go by numbers, then OpenAI models helped me the most in finding vulnerabiities and then to write exploits to demonstate to the maintainers. I am missing the capabilties to do proper pentesting though.
t0xic0der )
on 2026-11-05 18:30:00 UTC
We took some time to interact with the booth visitors at the IndiaFOSS 2026 conference's Red Hat Community Booth. While representing Fedora Project on the event grounds and handing out special swags, we were the conduits for the community's sentiments both as users and contributors to free and open source software projects like that of ours.
Version 4.13 of syslog-ng is expected to be released in the coming weeks. There are fixes and enhancements even in the core of syslog-ng. Testing of the latest nightly builds is much appreciated.
Thousands of automatic tests check each source code change before they are merged. Still, nothing can replace some manual testing with real-world configurations. Syslog-ng runs on a wide variety of systems, from RHEL 8 to Fedora Rawhide, FreeBSD, MacOS and others. It supports everything from simple file destinations to various network destinations, including not just syslog, but also OpenTelemetry or ElasticSearch. No automatic testing can fully cover all these variations.
I collected below just some of the highlights:
Read more at https://www.syslog-ng.com/community/b/blog/posts/test-syslog-ng-before-the-4-13-release
Few months ago, a collegue had a question for me. He started uneasy, apologizing that he does not want to neither age-profile nor offend me in any capacity. But I seemed like a person who would know. He continued with the question: what RSS reader do I use?
Before reporting him to HR, I said I've been using Google Reader until recently. But as it was promoted to Google Cementery, I've migrated to Netvibes, which also bit the dust. Now I use Miniflux, BTW.
Miniflux is very nice, with one exception: Passkeys support was broken. It required a login-name entry before attempting a Passkey login. As I have Miniflux connected to the home SSO, there was no login entry to use.
It was fixed in v2.3.5! Now Passkey login works as expected. Smooth!
Nb. I also realised, that I have not used my physical security keys for months, thanks to Passkeys everywhere.
Manifest A
While I had enough respite to prepare for the first day of IndiaFOSS 2026, I could not say the same for 27th September 2026. After returning to SRS Springs And Spa Hotel late the previous night, I found myself horrifically awakened by the noise of running water coming from the bathroom. Creeping cautiously towards the source of the sound while trying to shake off my headache, I was relieved when I realized that the room had not been intruded upon by anyone. It was the Jet Spray Faucet Device that had suffered a leak due to the change in water pressure, and that was where the noise was coming from. I was facing a mixed bag of emotions as I rang up the reception desk at around 0700am Indian Standard Time. I was glad that I had been jolted awake by the noise, as I did not have an alarm set for the morning, but I also had to waste some time dealing with the plumbing issue in the room before I could begin preparing for the day.
Manifest B
I did not realize how quickly my mind moved from finding something to use as a weapon against a potential intruder to gathering the necessary supplies for setting up the Red Hat Community Booth. Keeping myself immensely occupied helped in spades to shake off the sudden shock, and since Samyak Jain had tapped out of the 0930am Indian Standard Time booth presence, it was down to me alone to get things going. Deferring the cleanup of the leakage until after I was gone, I left for breakfast at around 0830am Indian Standard Time to be greeted by a (comparatively better) assortment of morning munchies. Grouped with Aaloo Bonda, Chholey Bhature, French Toasts, and Medu Vada, the menu selection was a whole lot more pronounced than the day before. I ordered myself an Uber ride at around 0900am Indian Standard Time, and within the next fifteen minutes or so, I found myself at the NIMHANS Convention Center Bengaluru.
Manifest C
Since it was Sunday, there was no flagship Bengaluru traffic to battle through, and along with me, Jaison Raju also happened to be the first one at the Red Hat Community Booth. I checked in with the likes of Rajan Shah and Deepesh Nair, who planned on coming later that day, before setting up the swags and laptops at the booth. I knew that I had to pace myself while addressing the booth visitors on that day, given how I had a numb voice and dry throat from the day before. The medicine intake allowed me to push through the pain, and I was more determined than ever to exhaust the inventory of Ceramic Branded Coffee Mugs and Round Magnet Pin Combos by the end of the day. For a change, I also brought my microphone to record our conversations with consenting community booth visitors. As an underlying principle, we were more interested in the feedback than in the contact details of the folks interacting with us.
Manifest D
Thankfully, we had a slower-moving community crowd on that day, which allowed us to stand our ground until our representational backup from the Ansible team and Tekton team arrived at around 1100am Indian Standard Time. Sudhir Dharanendraiah and Samyak came about half an hour later to help Jaison and me with the visitor interactions. Just like the day before, the swag offerings from Fedora Project ended up being indeed great conversation starters, not just for our community but also for those surrounding us. We also came upon some familiar faces from our community, like Muneer S., who used to contribute to Fedora Project at that time. Offloading conversations to Samyak and regularly keeping hydrating myself allowed us to keep going until lunchtime. Chats related to CentOS Stream's midstream value, the utility of generative tooling, and the open source software careers were, more or less, the stars of our presence on that day.
Manifest E
Right before we headed for lunch at around 0130pm Indian Standard Time, we met with Saumilli Dutta, whom we had met at DevConf.IN 2026 and GNOME Asia 2024. After meeting some more familiar faces from the Maintainer Summit and taking another round of group photographs, we headed for the lunch break, where we ran into Shivani Bhardwaj after having previously met her during FOSSAsia 2026. Finishing off our catch-up chats and okayish meals, I took the time to explore the venue offerings before heading back to our community booth. With Deepesh heading back much sooner, we were helped by Veer Kumar Patil with his professional lossless recording instrument. Using designated mics for the interviewer and interviewee allowed us to cut through the venue noise and retain a great deal of what was actually conveyed so that it could be transcribed accurately using generative tooling, once we were back.
Manifest F
After a visit from our FOSSUnited friend, Ansh Arora, we were also joined by the legal ambassadors of the Digital Personal Data Protection Act, Mrinmayee Nagarsenkar, Biju Nair and Dakshana AM, whom we felicitated with the Ceramic Branded Coffee Mugs. We had immense respect for what that they had been doing, and they also provided us valuable feedback as general-purpose computer users. With nothing significant planned for the evening, we cross-promoted our swag at the FOSSUnited helpdesk community booth who appreciated our swag supplies. At around 0530pm Indian Standard Time, it was about time for us to pack things up at our community booth, with us finally managing to finish off the offerings inventory. Connecting with Ramakrishna Yekulla, Shivraj Patil, and Gaurav Kamathe at the coffee stand, Samyak and I kept looking for an Uber ride back to the hotel to finally complete this event as a grand success.
RPMs of Redis version 8.12 are available in the remi-modular repository for Fedora ā„ 43 and Enterprise Linux ā„ 8 (RHEL, Alma, CentOS, Rocky...).
ā ļø Warning: this is a pre-release version not ready for production usage.
Packages are available in the redis:remi-8.8 module stream.
# dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %rhel).rpm # dnf module switch-to redis:remi-8.12/common
# dnf install https://rpms.remirepo.net/fedora/remi-release-$(rpm -E %fedora).rpm # dnf module reset redis # dnf module enable redis:remi-8.12 # dnf install redis --allowerasing
You may have to remove the valkey-compat-redis compatibility package.
Some optional modules are also available:
These packages are weak dependencies of Redis, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).
The modules are automatically loaded after installation and service (re)start.
The modules are not available for Enterprise Linux 8.
redis
redis-bloom
redis-json
redis-timeseries
admin )
on 2026-11-03 14:28:00 UTC
Fedora 45 is now available! 
So letās see what this new release for the Fedora Atomic Desktops variants includes for Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic.
Everything related to the Atomic Desktops now resides in the atomic-desktops organization.
The only remaining repo on GitLab.com/fedora is the one used to build the unofficial bootable container images (gitlab.com/fedora/ostree/ci-test). The migration of this repo will occur in the future, as well.
The Atomic Desktops installer ISOs now use the new Anaconda WebUI. This follows the same change that occurred for Fedora Workstation 42 and Fedora 43 Spins.
This also enables remote installation of a system using a Web browser on another machine over HTTPS.
See the Fedora Change pages for the switch to the WebUI and for Web based remote installations.
The installer images (ISO) are now built by Image Builder. While there should not be any immediate visible changes, this will help us move to the bootable container images in the future.
This also enables us to offer pre-installed disk images for Silverblue and Kinoite. Those images are currently in preview and only those variants are covered for now. They are the only ones with a first boot experience from a disk image.
See the Fedora Change page for further information.
The following changes are part of the general set of changes that come with Fedora Linux 45 and are worth noting for Atomic Desktops users:
Fedora Silverblue comes with the latest GNOME 51 release.
For more details about the changes alongside GNOME 51, see Whatās new in Fedora Workstation 45 on the Fedora Magazine.
Fedora Kinoite ships with Plasma 6.7, Frameworks 6.31 and Gear 26.08.
Plasma 6.8 is expected to land right after the release.
See also Whatās new in Fedora KDE Plasma Desktop 45 on the Fedora Magazine.
Fedora Sway Atomic comes with the latest 1.12 Sway release.
Fedora Budgie Atomic comes with the brand new version 10.10.3 of Budgie Desktop: New Favorites in Budgie Menu, re-introduced Keyboard applet with Wayland support, massive improvements to our desktop view, primary monitor selection, and more! See the 10.10.3 Budgie release announcement.
Fedora COSMIC Atomic comes with the 1.10.0 release of the COSMIC desktop.
Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora 45. Look for upcoming announcements in their Discourse.
As always, I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra media codec, out of tree kernel drivers, etc.).
If you have an interest in more security focused variants, I recommend taking a look at the secureblue project.
A lot of work is happening to make the transition to Bootable Containers as smooth as possible for our existing users. You can look at the roadmap for this transition at atomic-desktops#26.
Most of the progress in this release cycle was (again) focused on getting our bootable container images ready for general consumption in Fedora. A part of this work is being able to build them reliably in the Fedora Infra.
The people involved in the bootc, CoreOS and other Atomic variants are working on this effort as part of the new Atomic SIG. See atomic#137 and the project board.
Work is in progress to make it easier to create derived container images from the Fedora Atomic Desktops images, notably in order to comply with the logo and branding policy.
Once this is ready, we may start publishing āFedora Remixā branded container images of the Fedora Atomic Desktops. Those images will not include official Fedora branding and will thus be better suited for projects that want to layer their changes on top.
See atomic-desktops#125 and atomic-desktops#132.
If you have an interest in contributing to Fedora Atomic Desktops, here are some bugs that we will have to fix in the short term. We would greatly appreciate help with the following issues from the ticket tracker:
We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users. The following are Matrix rooms that may be of interest to potential contributors:
admin )
on 2026-11-03 14:00:00 UTC
Two legacy NetworkManager VPN pluginsāNetworkManager-vpnc and NetworkManager-fortisslvpnāare retiring and will be obsolete, starting in Fedora Linux 45. This is part of ongoing system maintenance and security cleanup.
If you use Virtual Private Networks (VPNs) to connect to remote workplace or enterprise networks, take note of this upcoming change in NetworkManager package availability.
This article contains information about what you need to know. It covers why these plugins are being retired, how this affects your current setup, and how to migrate your VPN connections to actively supported alternatives.
Both NetworkManager-vpnc and NetworkManager-fortisslvpn are unmaintained. Furthermore, the published issues allow LPE through malicious VPN profiles as well as legacy privilege-handling bugs in older VPN helper scripts, which pose security risks to local systems. Further information is available in this blog post.
To ensure Fedora Linux users remain secure and backed by active upstream maintainers, the Fedora Engineering and Steering Committee (FESCo) and NetworkManager maintainers agreed to retire these unmaintained plugins in favor of modern, secure alternatives already available in Fedora repositories.
| Retired Plugin | Protocol / Network Type | Migration Target | Status & Recommendation |
| NetworkManager-fortisslvpn | Fortinet SSLVPN | NetworkManager-openconnect | openconnect supports the older PPP-based Fortinet protocols natively and is actively maintained. |
| NetworkManager-vpnc | Cisco IPsec (IKEv1) | NetworkManager-libreswan | libreswan handles the same IKEv1 protocol family and is directly maintained by the NetworkManager team. |
If you currently rely on Fortinet SSLVPN tunnels, switch to the NetworkManager-openconnect plugin.
If you use legacy Cisco IPsec VPN tunnels, migrate your connections to NetworkManager-libreswan.
We strongly encourage all users relying on these VPN types to test and migrate their connection profiles to openconnect or libreswan as soon as possible!
admin )
on 2026-11-03 14:00:00 UTC
Fedora Silverblue isĀ an operating system for your desktop builtĀ on Fedora Linux. Itās excellent for daily use, development, and container-based workflows. It offersĀ numerous advantagesĀ such as being able to roll back in case of any problems. If you want to rebase to Fedora Linux 45 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.
Prior to actually doing the rebase to Fedora Linux 45, you should apply any pending updates. Enter the following in the terminal:
$ rpm-ostree update
or install updates through GNOME Software and reboot.
rpm-ostree is the underlying atomic technology that all the Fedora Atomic Desktops use. The techniques described here for Silverblue will apply to all of them with proper modifications for the appropriate desktop.
GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.
First thing to do is download the new image, so select the Download button. This will take some time. When it is done you will see that the update is ready to install.
Select the Restart & Upgrade button. This step will take only a few moments and the computer will restart when the update has completed. After the restart you will end up in a new and shiny release of Fedora Linux 45. Easy, isnāt it?
If you prefer to do everything in a terminal, then this part of the guide is for you.
Rebasing to Fedora Linux 45 using the terminal is easy. First, check if the 45 branch is available:
$ ostree remote refs fedora
You should see the following in the output:
fedora:fedora/45/x86_64/silverblue
If you want to pin the current deployment (meaning that this deployment will stay as an option in GRUB until you remove it), you can do this by running this command:
# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0
To remove the pinned deployment use the following command:
# 2 is entry position in rpm-ostree status
$ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora Linux 45 branch.
$ rpm-ostree rebase fedora:fedora/45/x86_64/silverblue
Finally, the last thing to do is restart your computer and boot to Fedora Linux 45.
If anything bad happens (for instance, if you canāt boot to Fedora Linux 45 at all) itās easy to go back. At boot time, pick the entry in the GRUB menu for the version prior to Fedora Linux 45 and your system will start in that previous version rather than Fedora Linux 45. If you donāt see the GRUB menu, try to press ESC during boot. To make the change to the previous version permanent, use the following command:
$ rpm-ostree rollback
Thatās it. Now you know how to rebase Fedora Silverblue to Fedora Linux 45 and roll back. So why not do it today?
Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.
Question: Can I skip versions during a rebase of Fedora Linux? For example from Fedora Silverblue 42 to Fedora Silverblue 45?
Answer: Although it could sometimes be possible to skip versions during rebase, it is not recommended. You should always update to one version prior (42->43->44->45 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I get errors during rebase. How should I do the rebase?
Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:
$ rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release
After doing this you can follow the guide in this blog post.
Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),ā¦?
Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/45/x86_64/kinoite
admin )
on 2026-11-03 14:00:00 UTC
Fedora Workstation features the latestĀ six months of meticulous polish, under-the-hood responsiveness, and security hardening for F45, based on GNOME 51. Whether you are multitasking across monitors, managing daily appointments, or organizing large sets of files, GNOME 51 brings thoughtful refinements to your daily workflow on Fedora Workstation.
One standout improvement in GNOME 51 is a reworked frame scheduling and frame delivery system in Mutter. Animations, window snapping, and desktop transitions now hold a rock-steady frame rate even when the CPU and GPU are under heavy compile or gaming loads.
In tandem with this, GNOME streamlined its graphics pipeline by retiring legacy NVIDIA proprietary interfaces in favor of the standard GBM memory management path. This makes Wayland sessions cleaner, faster, and more uniform across all hardware.
Files has picked up several subtle but indispensable touches:
Calendar feels faster than ever. The entire view-rendering engine was overhauled under the hood. This dramatically cut down the lag when scrolling through dense schedules in Month View. Reorganization within the event editor now presents a cleaner Notes section and native recognition of modern video conference links.
The quick-look File Previewer received a top-to-bottom redesign built on modern GTK 4 and libadwaita. It now seamlessly matches your desktop theme, respects Dark Style, handles fractional display scaling crisper than before, and properly previews high-resolution images at their actual native size.
Security underpins everything in Fedora Workstation. GNOME 51 introduces oo7, a modern Secret Service provider written from scratch to safely store application passwords, API tokens, and credentials.
Fedora Workstation is replacing legacy keyring daemons with a compartmentalized, sandboxed service. This provides even stronger defense against rogue applications attempting to peek at cached user credentials.
If youāre already running Fedora, upgrading through GNOME Software or via the terminal with
Share your favorite new feature or thoughts on the release over at the Fedora Discussion forum!
Disclaimer: Google Gemini, using the GNOME 51 release notes, assisted in the creation of this article. It was reviewed by humans before publishing. No apparent hallucinations were noted, however ,some content was not included.
Please read the GNOME 51 release notes for even more cool features that you can enjoy on Fedora Workstation as part of the F45 release.
admin )
on 2026-11-03 14:00:00 UTC
KDE Plasma 6.8 was released on KDE’s 30 year anniversary and we are proud to have it be the star of Fedora KDE Plasma Desktop Edition 45.
The Fedora KDE Plasma Desktop Edition is well suited for many needs. It combines the reliable and trusted Fedora Linux base with the KDE Plasma Desktop environment. It provides a selection of KDE applications that are simple by default, but powerful when needed.
KDE developers continue to release new features, fix bugs and fine-tune the desktop experience to improve on the now well-established foundation of Plasma 6. There have been two KDE Plasma releases since our last Fedora KDE Plasma Desktop Edition shipped. Some of the new features and updates include:
There is so much new stuff since our last Fedora KDE Plasma Desktop Edition was released. Check out the full release announcements for Plasma 6.7 and Plasma 6.8.
Some broader changes in Fedora Linux also directly impact Fedora KDE Plasma Desktop Edition, notably:
The Fedora KDE SIG hopes that youāll find Fedora KDE Plasma Desktop 45 to be a wonderful experience. When youāre ready to try it, click here for download links and verification instructions. If you would like to learn more, check out the Fedora KDE Plasma Desktop website.
The Fedora Project is pleased to announce the release of Fedora Linux 45!
Whether you use Fedora on your desktop, server, edge device, or cloud instance, Fedora Linux 45 brings polished desktop upgrades, powerful new installer features, and updated toolchains.
Every Fedora release is a major community effort – thank you to everyone in our community who helped build, test, and package this release!
If you are already running Fedora Linux, upgrading to the new release is simple. Our user documentation shows you exactly how to start enjoying F45 easily.
Looking for a clean install or setting up a new device? Head over to getfedora.org to grab installation media for our flagship Editions:
You can also explore our Atomic Desktops (including Silverblue, Kinoite, and Sericea) or choose from alternate desktop options via Fedora Spins (such as Cinnamon, Xfce, MATE, or COSMIC).
We have a lot of excellent content under the hood in this release. Below is only a snapshot of them. Take a spin through our release notes for individual changes, and details on each change.Ā
One of the biggest highlights in Fedora Linux 45 is integrated support for Stratis storage right inside the Anaconda installer.
Stratis brings modern enterprise storage features to local storage while wrapping device-mapper, XFS, and LUKS in an easy-to-use interface. These features include thin provisioning (over-provisioning), storage pooling, dynamic filesystem sizing, snapshots, and encryption.
Read more details about this really cool change in this article.
If you encounter any bugs or unexpected behavior after upgrading or installing, help is close at hand:
Important: Two legacy NetworkManager VPN pluginsāNetworkManager-vpnc and NetworkManager-fortisslvpnāare retiring and will be obsolete, starting in Fedora Linux 45. Please read this article for information on what you need to do to migrate your VPN connections to supported alternatives.
Weād love to hear how Fedora Linux 45 works for you! Share your thoughts, post your desktop setups, or say hi to fellow community members over on Fedora Discussion.
Enjoy Fedora Linux 45!
admin )
on 2026-11-03 09: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 ā¦
llaumgui )
on 2026-11-02 19:29:00 UTC
admin )
on 2026-11-02 14:00:08 UTC
We are happy to announce the general availability of Fedora Asahi Remix 45. This release brings Fedora Linux 45 to Apple Silicon Macs.
Fedora Asahi RemixĀ is developed in close collaboration with theĀ Fedora Asahi SIGĀ and theĀ Asahi LinuxĀ project. This release incorporates all of the exciting improvements brought byĀ Fedora Linux 45.Ā Like previous releases, Fedora Asahi Remix 45 supports Apple M1 and M2 systems. In addition, this release includes out of the box initial support for Apple M3, M3 Pro and M3 Max. Asahi Linux upstream now officially supports these new systems. The GPU drivers enabling performant 3D acceleration on the M3 systems are not included at this point. They will be available via a Mesa update in the future.
Fedora Asahi Remix offers KDE Plasma 6.8 as our flagship desktop experience. All of the new and exciting features brought by Fedora KDE Plasma Desktop 45 are included.
A GNOME variant is also available, featuring GNOME 51, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.
You can install Fedora Asahi Remix today by following our installation guide. Follow the usual Fedora Linux upgrade process for existing systems running Fedora Asahi Remix 43 or 44. Upgrades via GNOMEās Software application are unfortunately unavailable. Either KDEās Plasma Discover or DNFās System Upgrade command must be used.
Please report any Remix-specific issues in our tracker, or reach out in our Discourse forum or our Matrix room for user support.
Across the Fedora Project, the overwhelming focus is the imminent release of Fedora Linux 45, scheduled for November 3, 2026. Teams including Quality, Release Engineering, Workstation, KDE, Server, Cloud, and ARM are intensely coordinating to perform final validation testing on Release Candidates RC-1.3 and RC-1.4 while successfully triaging last-minute blocker bugs. Simultaneously, a major collaborative effort is underway among the Council, Atomic, CoreOS, Hummingbird, and IoT groups to finalize the "Atomic Fusion" Bootable Image Unification initiative. Their primary technical priority is establishing a bootable seed image for CI testing, though development has temporarily shifted to GitHub to bypass ongoing integration friction between Konflux and Forgejo. Finally, looking beyond the upcoming release, teams are managing sweeping security updatesāsuch as addressing the eMudhra Intermediate CA Compromise across the Rust ecosystem and backporting roughly 300 CVE fixes for WebKitGTK in EPEL 10āwhile FESCo prepares the community for Fedora 46 and 47 by reviewing change proposals for Python 3.16 and PHP 8.6.
Following a successful Go/No-Go meeting, Fedora Linux 45 Final is officially approved and shipping live on November 3, 2026. This milestone release brings significant user experience improvements, including modernizing the virtual console by switching to the userspace utility kmscon instead of the legacy fbcon driver, and introducing a Stratis storage configuration option in the Anaconda installer to simplify local storage management.
Looking ahead, several change proposals have been announced for future releases, offering key opportunities for community feedback and testing. For Fedora 46, proposed upgrades include rewriting the usermode package's userhelper and consolehelper in Rust to enhance memory safety, transitioning tzdata to a more efficient 'slim' data format to mitigate data bloat and 2038 bugs, and updating the PHP stack to version 8.6. Additionally, planning is already underway for Fedora 47 with a proposal to upgrade the system stack to Python 3.16. Contributors are encouraged to review these proposals and assist with early compatibility testing.
The Council focused on the "Atomic Fusion" bootable image unification effort and wrapping up the Fedora Atomic Initiative. Discussions centered around seed image creation, overcoming integration friction between Konflux and Forgejo, and transitioning development environments. The Atomic Initiative is officially winding down with the Fedora 45 release, and a retrospective has been opened to collect community feedback.
Learn more about the Council team.
FESCo announced four new Change Proposals on the forums this week: Python 3.16, Usermode2, PHP 8.6, and TzdataZicSlimFormat. The committee noted that active discussion for these proposals is now intended to take place strictly on the devel mailing list.
In ticket tracking, FESCo evaluated several pending system-wide changes, including the proposed removal of the DNF4 stack and modularity, the transition to the RPM v6 package format, and the LMDB 1.0 transition. Extensive discussions also continued regarding performance requirements and potential SLAs for alternative architectures in Koji (Ticket 3688) and the ongoing evaluation of Forgejo as a potential Bugzilla replacement (Ticket 3664).
python-authlib package to chihlee under the non-responsive maintainer policy. (URL)NetworkManager-{vpnc,fortisslvpn} in F43 and F44 instead of relying on easily-missed RPM scriptlet warnings. (URL)maxamillion. (URL)Learn more about the FESCo team.
During the week of October 26 to November 1, 2026, the Packaging Committee met and closed multiple tickets focused on standardizing versioning and clarifying cryptographic policies. The primary theme of the week was resolving confusion around snapshot packaging and ensuring that cryptographic policies strictly follow FESCo directives without unintended restrictions. Additionally, new guidelines for Emacs package packaging were proposed and remain under discussion.
<base_version>^<number>.<revision> (Issue #1578, Issue #1570).Learn more about the Packaging Committee team.
Mindshare handled several forum topics and tickets this week, focusing heavily on event preparation and budgeting for late 2026 and 2027. The committee reviewed the 2027 travel budget, allocating funds across major Q1 events like FOSDEM and FOSSAsia, and processed multiple swag and event funding requests. Additionally, Community Operations announced a shift to asynchronous team meetings, and the Mindshare Committee is considering restructuring its team representative seats, with CommOps officially resigning its seat.
Learn more about the Mindshare team.
Andrew Heath introduced himself to the Fedora Join community this week. As a Senior Platform Engineer at Red Hat IT with over a decade of enterprise Linux experience, he is looking to transition from a downstream consumer to an active upstream contributor.
He outlined his primary areas of interest for contributing, which include becoming a package maintainer, working with image building and composes (specifically osbuild), assisting with QA release validation testing, and contributing to Fedora Infrastructure automation.
Learn more about the Fedora Join team.
The Ambassadors group is actively coordinating the Fedora Project's in-person presence for the upcoming FOSSASIA 2027 summit. Community members have begun introducing themselves on the forum, expressing their eagerness to represent Fedora, detailing their current contributions, and confirming they have submitted talk proposals and updated the planning Wiki.
Learn more about the Ambassadors team.
This week, the Workstation/GNOME group focused on preparations for the Fedora 45 release, including the availability of Fedora 45 Release Candidates (RC-1.3 and RC-1.4) and their respective validation testing. Discussions also covered a drafted Fedora Magazine article for the upcoming release, a requested GNOME patch for input sources, and the need for human review in automated LLM weekly reports. Additionally, the group addressed ongoing bugs, such as ensuring unprivileged LDAP users can install updates via gnome-software following the dnf5 transition, and finalized the removal of the PyCharm COPR repository from previous Fedora releases.
Learn more about the Workstation / GNOME team.
This week, the KDE group focused on validation testing for the upcoming Fedora 45 release, with Fedora 45 Candidate RC-1.3 and RC-1.4 both provided for final testing. Key updates in these candidates include KDE 6.8.1, stratisd encryption fixes, and oo7 updates. Additionally, a new Fedora user provided feedback about system slowdowns caused by file indexing, and was advised to share this feedback directly with upstream KDE developers.
Learn more about the KDE team.
The Server working group focused heavily on validating Fedora 45 Release Candidates 1.3 and 1.4 this week. Extensive testing across various installation methodsāincluding remote/local, BIOS/UEFI, ARM SBC, and KVM environmentsāconfirmed that Fedora 45 is ready for release from the Server perspective. Minor issues regarding LVM partition types and device tables on KVM and ARM images remain but can easily be bypassed during post-installation. Additionally, the group made significant progress on the Ansible support project, successfully publishing the first ansible-collection-fedoraserver-general package to a Fedora Copr repository. Work is ongoing to improve the out-of-the-box Ansible experience and implement system backup documentation utilizing Borg and ReAR.
ansible-collection-fedoraserver-general and closed ticket #237 and ticket #238.Learn more about the Server team.
The Infrastructure team addressed several critical issues this week, including a heavy scraper attack on Bodhi that caused database load spikes and timeouts. To mitigate this, the search endpoint was temporarily blocked and specific user-agents were banned. The team also resolved a storage capacity issue on the download-ib01 mirror by removing the fedora-archive module, which was communicated to mirror admins. In other news, the team prepared for the upcoming Fedora Linux 45 final release, successfully deployed Forgejo v15.0.11 to production, and progressed on configuring Zabbix monitoring for the new staging autosign service. Persistent and sporadic 'bad credentials' errors affecting logins to accounts.fedoraproject.org remain under active investigation with upstream FreeIPA.
Learn more about the Infrastructure team.
Release Engineering focused heavily on finalizing Fedora 45 Release Candidates (up to RC 1.4) and performing stable pushes in preparation for the final release. The group coordinated extensively across Bodhi updates, resolved gating CI test failures, and addressed mirror syncing and torrent seeding issues. The F45 Blocker Review meeting successfully triaged several bugs, ensuring critical issues were flagged or handled via freeze exceptions. In addition to release tasks, the team investigated build breakagesāincluding a memory exhaustion issue for chromium on x86_64 and broken EPEL9 reposāand handled Pagure/Bugzilla assignee updates. The package unretirement tool is now fully rolled out, streamlining the process for package maintainers.
Learn more about the Release Engineering team.
The Fedora Quality team focused heavily on validating the upcoming Fedora 45 release this week. During the F45 Final Go/No-Go Meeting, the team officially declared Fedora 45 Final as a "GO" for release on November 3, 2026, using release candidate RC-1.4. Aside from release candidate validation, the QE team worked on expediting security fixes, expanding openQA test capabilities for SAS and Arabic, deploying a hotfix for Issuebot, and wrapping up preparations for the Kernel 7.3 test week starting November 1st.
Learn more about the Quality team.
This week, the team evaluated the potential impact of the Node2Shell vulnerability on the Fedora Project website in the Fedora Websites chat. They confirmed the site is safe since it uses Nuxt to statically generate HTML rather than running a dynamic Node.js server. Following this, the team successfully updated the site's Node modules. The update process hit a minor prerender error caused by a malformed German translation string on the COSMIC page, which was resolved by fixing a typo in the English source to automatically invalidate the faulty translation. Additionally, Swedish translations for the COSMIC website were updated, and a ticket for upgrading node modules was successfully completed. On the forum, a contributor reported UX confusion regarding the Fedora Project Contributor Agreement (FPCA) while trying to edit the wiki. This sparked a discussion on how to handle broken wiki links, leading to guidance on proper migration and link maintenance practices.
{{#fedoradocs: $FULL_DFO_URL}} to act as a direct redirect rather than deleting the page and causing a 404 error.Learn more about the Websites and Apps team.
This week, the Design team successfully closed several key issues. The visual assets and promotional graphics for the F45 Virtual Release Party were completed ahead of the October 30th event. Additionally, the team wrapped up the sketches and rough drafts for the F46 wallpaper and fulfilled a request for a higher resolution Fedora logo.
Learn more about the Design team.
The Docs team focused heavily on infrastructure modernization and tooling improvements this week. Key structural changes include transitioning the main site builder repository to a standard main branch workflow, retiring the old stg branches, and officially renaming the builder repository to site-builder. The team also made a significant architectural decision to consolidate all Antora documentation modules under a single ROOT component, which will allow content from various Special Interest Groups (SIGs) to be seamlessly mixed and matched into unified guides.
In addition to structural work, progress was made on migrating the UI bundle from GitLab to Fedora Forge. The team is also experimenting with a newly deployed CryptPad instance in CommuniShift to facilitate real-time collaborative writing. Content-wise, several release notes for upcoming Fedora changes were drafted and merged, including updates for the Crystal programming language, LibreOffice HTML help, and LibreOffice dictionaries.
docs-fp-o has been renamed to site-builder to better reflect its purpose (URL).prod branch was renamed to main and set as the default branch, while the old main and stg branches were deleted. A CC BY-SA 4.0 license was applied to the new main branch (URL).ROOT Antora component, which will also drop the component name from the URL (URL).ui-bundle name and using Forgejo Actions to build and publish the bundle to the package registry (URL).docsbuilder.sh as a wrapper (URL).Learn more about the Docs team.
A community member inquired if the trained model weights and vocabulary for a Japanese input method (fcitx5-slm-ime) could be packaged in Fedora as content under the CC-BY-SA-4.0 license. The Legal team confirmed that the described contents fit the 'content' category and that CC-BY-SA-4.0 is an allowed-content license under Fedora legal policy. For more details, see the original thread.
Learn more about the Legal team.
This week, the ongoing migration of COPR build results to Pulp caused some users to experience unexpectedly long pending build times. The team expects the migration of all projects to conclude before the end of November. In addition, an unrelated infrastructure issue caused temporary slowness in Pulp, which was resolved after the Pulp team intervened to clear stuck workers. Community members also discussed the legality of hosting FLOSS software with codecs unapproved by Fedora in COPR. Since COPR is subject to the same US-centric legal concerns as Fedora, it is considered unsuitable, prompting documentation updates to clarify the policy.
Learn more about the COPR team.
The EPEL community is preparing for the upcoming retirement of EPEL 10.2, which will take effect once RHEL 10.3 is released in November. Packagers are urged to push any outstanding updates to stable, as pending updates and side tags will be removed during the transition.
In other news, WebKitGTK has received a major security update in EPEL 10 that backports fixes for approximately 300 CVEs. Meanwhile, maintainers have proposed retiring pipx from EPEL 9 because the latest security releases require Python 3.12, which cannot be practically satisfied by EPEL 9's Python 3.9 baseline.
pipx from EPEL 9 because 23 high-severity security issues cannot be backported to Python 3.9.Learn more about the EPEL team.
The Atomic group heavily focused on concluding the Bootable Image Unification ("Atomic Fusion") initiative, primarily centering on the definition and creation of a new "seed image" for CI test harnesses. Because of ongoing integration limitations between Forgejo and Konfluxāspecifically missing service accounts and SSH push supportāthe group decided to temporarily host the initial seed image work on GitHub. The initiative itself is wrapping up by the end of October with plans to transition ownership of the long-term artifacts to the CoreOS Working Group.
In the forums, members clarified the synchronization discrepancies between rpm-ostree commits and Bodhi stable pushes, which temporarily exposes testing packages in stable trees. Additionally, a new proposal was introduced to implement a desktop-aware health check that would automatically roll back deployments on Silverblue and Kinoite if a graphical Wayland session fails to initialize.
rpm-ostree rollbacks if a Wayland session fails to start in Silverblue and Kinoite.aboot or systemd-boot) to the new seed image once the default GRUB/zipl base is established.Learn more about the Atomic team.
This week, the CoreOS group focused heavily on preparing for the upcoming Fedora 45 release and resolving critical system and kernel issues. In preparation for F45, team members coordinated pull requests to migrate the testing-devel stream and discussed the go/no-go final target date. A significant public service announcement was also distributed regarding a required manual intervention (update-ca-trust) for users with customized CA trust stores to properly incorporate new certificate changes, such as the eMudhra certificate distrust.
The group also made progress on the Bootable Image Unification ("Atomic Fusion") initiative, choosing to temporarily coordinate seed image work on GitHub while ironing out Konflux integration challenges. On the technical side, an upstream selinux-policy fix was merged to resolve podman-remote socket connection denials, and extensive debugging successfully identified an ext4 writeback bug causing corrupted kernel files in the /boot partition during upgrades, with a temporary workaround identified while waiting for a kernel patch.
update-ca-trust if they have customized their system CA trust store, as OS updates do not automatically regenerate it (Meeting log).bootc install to create disk images for the next stream first, followed by testing, but only after the Fedora 45 release is complete (Meeting log).nodioread_nolock mount option workaround for an ext4 corruption issue on /boot during upgrades (Issue #2234).Learn more about the CoreOS team.
The IoT Working Group met to review the testing status for Fedora 44, 45, and 46, noting that all are in good shape with Fedora 45 finalizing for its upcoming release. The team also planned a new greenboot-rs release and provided support for running Fedora IoT on NVIDIA Jetson Orin devices.
In forum discussions, the Bootable Image Unification ("Atomic Fusion") initiative met to plan their seed image creation, deciding to temporarily use GitHub to avoid service account friction in Forgejo and Konflux. The Fedora Robotics SIG also held a meeting to track packaging blockers for Fedora 44, including missing dependencies like libyuv in EPEL10.
Fedora-IoT-45-20261028.0 compose for Fedora 45 final validation ahead of the Go/No-Go meeting (Meeting Log).greenboot-rs release to roll out recent bug fixes (Meeting Log).Learn more about the IoT team.
This week, the ARM group's activities were centered around the upcoming release of Fedora 45. Adam Williamson announced the availability of Fedora 45 Candidate RC-1.4 for final validation testing. He emphasized that this candidate must pass all required test cases to meet the Final Release Criteria. Additionally, a Fedora 45 Blocker Review Meeting was scheduled to assess current Blocker and Freeze Exception bugs.
Learn more about the ARM team.
Fedora 45 Candidate RC-1.4 is now available for validation testing. This release candidate must be thoroughly tested to determine if it meets the criteria for the official Fedora 45 release.
Learn more about the Cloud team.
The Hummingbird group held discussions centering on the "Atomic Fusion" Bootable Image Unification initiative, closing out the current phase by October 31st with an upcoming public retrospective. The team has been working on a proof-of-concept seed image, focusing on integration between Konflux and Forgejo. Due to current infrastructure limitations, specifically regarding service accounts and SSH key support, they are temporarily utilizing GitHub for the seed repository work while compiling a list of deficiencies to hand upstream.
A major focus was deciding on the technical direction for the seed image, with the group agreeing to start from existing bootc base images that resemble Fedora minimal with a bootloader. Testing methodology was also heavily debated, culminating in an agreement to pursue full boot and secure boot testing via a disk image (like QCOW2), which is essential for Fedora QA processes. A live demonstration of the seed image proof of concept is planned for the upcoming week.
Learn more about the Hummingbird team.
The Fedora AI/ML SIG focused heavily on the Fedora 45 Release Party this week, delivering a live presentation covering the group's recent progress, including the Agent Skills Library, AI/ML packaging, and ROCm updates. A video recording and presentation slides are now available for the community to review.
In addition to the release party, technical work continued with the wiring of a new COPR for agent-skills, updating the ROCm installation wiki, and refreshing Colibri to version 2.0. Ongoing discussions also covered package dependency troubleshooting, integrating executorch for NPU workloads, and successfully landing gufo into Rawhide.
podman-desktop into Rawhide (Fedora Discussion).sqlfluff, a new Python-based SQL linter being integrated with pi-coding-agent (Bugzilla #2564611).Learn more about the AI team.
The RISC-V group focused heavily on finalizing Fedora 45 and ramping up the Fedora 46 rebuilds this week. The Fedora 45 final images are ready and have been successfully tested on various hardware including Jupiter, P550, K3, and Titan using the Omni kernel. Concurrently, efforts to bootstrap Fedora ELN on riscv64 are advancing well, with Koji fully configured for ELN and the LLVM toolchain modified for the new RVA23 baseline.
The team is also actively investigating a difficult-to-debug GCC build failure on K3 hardware, testing various kernel patches and memory configurations to mitigate the issue. In community news, the RISC-V devroom has been accepted for FOSDEM 2027, and the CFP announcement has been distributed. Additional details from the brief weekly sync can be found in the RISC-V meeting log.
qt6-qtwebengine package for the ongoing Qt 6.12 update.Learn more about the RISC-V team.
In the NeuroFedora Matrix room, a contributor triaged four CVEs reported against dcm2niix related to an old vendored cJSON, ruling them out but noting potential future vulnerabilities. As a result, an upstream issue was opened to address the vendored dependency. A new build of the latest dcm2niix release is being prepared exclusively for Rawhide due to documented behavior changes.
dcm2niix release will be built exclusively for Rawhide due to documented behavior changes.Learn more about the NeuroFedora team.
This week, the Gaming group's discussions centered on the Steam 64-bit beta multi-lib requirements. A community member highlighted a GitHub issue showing that despite the 64-bit Steam RT3 update, Steam's reaper binary remains a 32-bit executable, which still forces distributions to maintain 32-bit GL libraries on the host. An unofficial workaround was shared, detailing how to compile a 64-bit replacement for the reaper binary and start Steam with the -noverifyfiles flag to bypass the 32-bit dependency requirement.
Learn more about the Gaming team.
Jens-Ulrik Petersen shared a new tool called fh-unbundling to identify technical debt in Fedora Haskell caused by bundled libraries. By analyzing dependent packages, the tool highlights bundled libraries that are used by multiple dependent chains, emphasizing the need to unbundle the most impactful offenders to streamline package maintenance.
Learn more about the Haskell team.
This week, Yaakov Selkowitz bumped a pull request against perl-File-ShareDir to disable optional dependencies on RHEL by pinging a reviewer.
Learn more about the Perl team.
This week, the Python group discussed standardizing intersphinx mappings for Python package documentation. While it was acknowledged as technically feasible to upload and reference these mappings locally, concerns were raised regarding maintenance overhead. Some members noted a broader trend of Fedora packages dropping Sphinx documentation entirely due to bundling complexities. Additionally, a new community member introduced themselves and offered to help with Python backlog items and automation scripts.
Learn more about the Python team.
During the testing of the newly started Ruby 4.1 development, community members have been fixing packages that fail to build due to C API changes, such as the deprecation of the Data_Wrap_Struct macro. In the Ruby 4.1 development started thread, VĆt Ondruch thanked contributors for their fixes and noted that some older packages should likely be orphaned or retired instead of being patched.
Learn more about the Ruby team.
This week, the Rust group focused heavily on cascading security updates across the ecosystem following the end of the F45 Final Freeze. Extensive work was done to rebuild applications affected by the eMudhra Intermediate CA Compromise (RUSTSEC-2026-0381) and to update dependencies for rustls, lru, and faster-hex to address multiple security advisories. The team encountered significant friction updating the zip crate to version 9 due to unannounced upstream breaking API changes, leading to the realization that a rust-zip8 compatibility package will be required.
Additionally, a mailing list discussion clarified that packaging pre-releases of Rust crates is fully supported in Fedora; maintainers simply need to explicitly specify the pre-release version using rust2rpm (e.g., rust2rpm pcap-file@3.0.0-rc.3), though parallel major versions may still be necessary to satisfy dependent packages.
rust2rpm (e.g., @3.0.0-rc.3), as confirmed in a mailing list discussion.zip crate version 9, the group decided to introduce a rust-zip8 compatibility package rather than attempting to patch all ecosystem consumers immediately (Ticket #47).@rust-sig as a co-maintainer, the team will combine requesting co-maintainership and utilizing automated scripts to file bugs, rather than relying on provenpackager interventions (Ticket #43).rustls-webpki but not containing affected certificates will be treated as low-priority rebuilds (Ticket #46).routinator (v0.15.3) work, as it introduces new security fixes but switches its crypto implementation to aws-lc-rs via rpki 0.20, which is non-trivial to patch out (Ticket #46).@rust-sig as a co-maintainer are encouraged to add the group to facilitate automated security rebuilds (Ticket #43).zstd, zstd-safe, and zstd-sys crates needed to support the zip v9 transition (Ticket #47).Learn more about the Rust team.
kmscon-uim package to easily configure Traditional Chinese and other CJK input methods for the virtual console, which maintainers supported.hexchat package is unmaintained.live555 to accommodate a live555 soname change, and will build its consumer vlc in a side tag.ptl and usbsniff packages.Quality assurance and testing remain some of the most accessible ways for anyone to support the project. The Quality and Release teams urgently request validation testing for the Fedora 45 Candidate RC-1.3 and RC-1.4 releases. Testers are needed across ARM, Cloud, Server, and Workstation environments, with a specific focus on verifying KDE 6.8.1 bug fixes, encrypted Stratis installs, and GNOME secrets management. Additional testing opportunities include evaluating the new global search on the Forgejo testing instance, participating in the Kernel 7.3 test week, verifying WebKitGTK security updates for EPEL, or trying out the CryptPad CommuniShift instance and the pi-coding-agent local AI tool.
Contributors with strong writing, design, and communication skills can jump into several documentation and feedback initiatives. The Docs team is looking for writers to draft release notes for Libical4, IBus 1.5.35, and Fontconfig 2.18, while the Server team needs help drafting Ansible support guidelines. Reviewers can provide valuable feedback on the drafted "What's New in Fedora Workstation" Magazine article, the OpenShell usage guide, and the COPR documentation updates regarding unapproved codecs. Community members are also encouraged to participate in the Atomic Fusion retrospective, add their names to the FOSSASIA 2027 representation list, or help the Design team rebuild by creating event badges.
For those familiar with Fedora packaging standards, there is a high demand for package reviews, maintenance, and mentorship. Active contributors can guide newcomersāsuch as a new member seeking a sponsor for sysadmin toolingāor participate in package review swaps to help push items like podman-desktop into Rawhide (Ref) alongside the new AI linter sqlfluff. Maintainers can support the broader ecosystem by identifying old Ruby packages for retirement, submitting outstanding updates before the EPEL 10.2 retirement, reviewing the proposed removal of DNF4, or submitting PRs for the starting base image package set.
Contributors with coding, debugging, or system administration skills have several critical engineering challenges to tackle. Newcomers can get involved by upgrading Node.js modules for the website repositories or by following the Infrastructure Join Guide. More experienced engineers are needed to resolve intermittent IPA credential errors on Fedora accounts, add metrics to Zabbix monitoring, debug the Chromium out-of-memory build error, or assist the CoreOS team in testing an ext4 corruption workaround. Rust developers are specifically sought to patch complex cryptography dependencies for routinator and to navigate the impending zstd crate transition.
fale )
on 2026-11-01 23:00:00 UTC
During conversations at work, and outside it, Kubernetes high availability comes up. And every time that happens, the idea of stretched clusters comes up. The idea is appealing, since stretching clusters across multiple data centers ensures that even if one is lost, Kubernetes keeps running and takes the necessary actions to restore services in the surviving sites. On the surface, it seems like the Holy Grail of HA, since it is simple and highly effective. In practice, this is often not the best setup.
It's saturday morning again, so time for a recap in longer form for the weeks doings in fedora land.
The big news is that this week we got a few release candidates, and then finally on thursday a 'go' for fedora 45 release on tuesday.
This release did take a bit, but I think it really came together in the end. The composes were completely FINISHED, so no missing deliverables at all, we managed to get a plasma update in and there wasn't any proposed blockers that we reluctantly didn't take.
So, I hope f45 will be a very solid release for everyone.
So, after Fedora 45 is out next week, we are in november and the year is running out. There's the US thanksgiving holiday week at the end of november and then holidays in december.
I'm going to work on some storage cleanup in the coming weeks and we will likely do another update/reboot cycle before thanksgiving.
Aside that hopefully we can get some backlog items done. If there's some particular item you really would like me to work on before the end of the year, do let me know. :)
As always, comment on the fediverse: https://fosstodon.org/@nirik/117537261270743528
I have a Samsung Q800A soundbar. It ships with built-in support for the Apple Airplay protocol, but I’m not really an Apple kind of guy so that’s never been particularly helpful for me. So, instead, I have a Chromecast Audio plugged into it via TOSLINK, and that works fine - except for the fact that there’s no way to explicitly pick TOSLINK as the audio input. Instead, there’s a “Digital In” option that refers to both the optical in and eARC input from a TV. Not inherently a problem, given I’m unlikely to be watching TV while listening to music, but my TV is a Samsung Frame, a device that’s intended to display art whenever someone is standing nearby, and which infuriatingly generates an eARC signal even if it’s only in art mode and isn’t going to make any noise. This switches the soundbar away from optical and I get sad. I could plug a video cast device into the HDMI port on the soundbar and cast audio to that, but then the art would get replaced with album covers whenever I’m playing music, and again that’s not quite the ambience I want. Still, none of this is that important.
Until I learned that the Australian version of the soundbar does have Google Cast support. The firmware image was downloadable from Samsung support, so I grabbed that, but unfortunately found that it was encrypted. However, if I downloaded the firmware image for the US model, the encrypted blob was identical - there’s no difference in the underlying firmware between the two of them. So, how come one has support, and the other doesn’t?
I’d need an unencrypted copy of the firmware to have a real chance of figuring this out, and the easiest way to get one was to just run an ebay watch for a broken model of the same series. Once I had one in my hands I used hot air to remove the eMMC storage from the device, cleaned up the chip, and then stuck it in one of these adapters to read it on a local system. Samsung uses a weird in-house filesystem called VDFS4 on some of their devices and this was one of them, so I needed to cobble together a kernel that was compatible with their source dump for this device (not all VDFS drivers seem to be able to read all VDFS filesystems), but eventually I had it all extracted, and then I got distracted by other stuff, so let’s fast forward to this week.
Samsung makes use of a modified version of the Android Debug Bridge called sdb, which is included in the Tizen SDK. The firmware showed that this device had sdbd on it, and it would be executed if a network device called “huart0” was plugged in. Samsung does, thankfully, provide the source code for their GPLed components, so I could dig through that to discover that drivers/net/usb/usbnet.c had a bunch of references to huart (which apparently stands for “HyperUART”). If CONFIG_SAMSUNG_USBNET_HYPERUART_IFNAME is set, and if the ethernet device is using either the asix or ax88179_178a drivers, and if “/opt/etc/HyperUART_IP_Addr”1 isn’t just “0”, it sets the interface name to “huart0” and in turn triggers sdbd startup. So now I just needed to figure out how to set /opt/etc/HyperUART_IP_Addr to something else.
Some digging revealed a binary called wap-factory that referenced the file, which then led to /usr/share/mobile-mgr/jsons/com.samsung.audio.waapp-verification-test.json which mentioned a “SetUartOnOff” call, which brought me here2, which led me into a bit of a rabbit hole about the Samsung WAM protocol. Long story short, you connect to either port 55001 or 56001 and make two requests over the same connection:
|
|
and then plug in an asix chipset ethernet adapter into the USB port (which on mine is micro-B, so I needed an OTG adapter), and suddenly it’s sitting there on 192.168.250.250 and will speak sdb to you. sdb root on switches it into root mode, and sdb shell now gives you a root shell. I was in, and now I could investigate what was happening.
First up, there was a process called “com.samsung.audio.google-cast-control-app” running, which seemed like a good start. Unfortunately it wasn’t doing anything. After some tracing I found that it was making a call to Samsung at startup time, and getting back a response telling it that Cast support wasn’t available. The request (which was helpfully dumped to stdout when I ran this by hand) included the country code, in my case “US”. Repeating the request by hand with curl and changing the code to “AU” told me it was supported, so now I needed to figure out how to get the soundbar to believe it was Australian. Some digging showed it was reading this from a config variable called db/comss/countrycode, and running
|
|
got me past that gate. Now, however, it was complaining that it couldn’t provision a key. /usr/apps/com.samsung.audio.google-cast-control-app/shared/res included a bunch of encrypted blobs and an app called teeStoreKey.elf, and tracing com.samsung.audio.google-cast-control-app showed it was trying to call that, but it seemed like it was failing with a permissions issue. Running com.samsung.audio.google-cast-control-ap directly as root triggered key provisioning successfully, and a few seconds later the rest of the Cast API came up and I could talk to port 8443 with standard Cast API calls. Unfortunately it still wasn’t working as a Cast device, though - it wasn’t advertising itself via mDNS and so nothing could see it. Querying the /setup/eureka_info endpoint gave me a clue - the ’tos_accepted’ field was false. Normally this would be set as part of initial device setup, but the Samsung app wasn’t doing that because it didn’t think the device had Cast support. It turns out that POSTing some json with {“tos_accepted”: true} to setup/set_eureka_info made it work, and suddenly there was an additional Cast device available to me.
(Update: I realised I didn’t mention anything about why it was doing key provisioning in the first place! The Cast protocol doesn’t enforce cryptographic identity as such, but Google’s reference client implementation which is what almost everything uses verifies that the device is presenting an identity that chains back to Google. Unsurprisingly they don’t want the private key material to be easily extractable and used to produce clone devices, so it’s all supposed to be encrypted and only accessible to some sort of trusted execution environment, which is why keys here need to be loaded into Trustzone and never be visible in the clear to the main OS)
Mission accomplished. Unfortunately the device vanished from my Smartthings home aferwards, presumably because there’s a mismatch between its reported country code and my account country. To get around that I’d somehow need to get com.samsung.audio.google-cast-control-app to either change the query without changing the global device country, or to ignore the response from Samsung (it does this every 24 hours, ugh), and that’s made more annoying by the fact that this thing will only execute signed binaries. Although, weirdly, one of the signed binaries shipped is a full Python interpreter, so if I cared enough I could probably cobble together enough Python to execute arbitrary binaries. I currently don’t.
More modern soundbars don’t implement the listener on port 55001 or 56001. I don’t know how you get sdb working on them.
hrw )
on 2026-10-30 13:59:00 UTC
I enjoy talking to people during events. Discussions can go in many directions. And recently I spoke about how to start contributing to FOSS projects.
My first contribution was an update of the official installation guide for Debian on Amiga. Pure documentation, no code involved.
My first source code change came two years later. A few lines of C which were accepted after some changes.
At first, check which projects you are using. And then go through a simple checklist:
Nowadays, everyone can submit code to any project — all those LLM/AI tools can generate code for you in seconds. Will anyone review and accept it is another thing.
But going in the other direction is a much better way…
Check how well the project is documented. Maybe something is hard to understand due to language/grammar used — not everyone speaks/writes in the same way.
Maybe documentation is completely missing. Or describes only some parts of a project. Or is outdated.
When I got hired for my second job, my first task was to get familiar with the software I would be developing by reading its documentation. I crossed out most of screenshots and several paragraphs because they were two months old and the app got renamed in the meantime.
So check docs and send corrections. Make it up to date and complete.
Not everyone speaks English. Even when many people think that everyone should.
Software projects can be translated into other languages. Check is your project of choice available in your language. Regardless of whether you would you use that translation or not.
Maybe previous translator moved to other tasks and new version needs some new strings in your native language? Or no one translated it before?
Check translation guidelines from some larger projects like GNOME or KDE — they may have dictionaries ready to use so you do not have to reinvent new name for ‘a directory’ (folder, catalogue, drawer etc.).
Triage is the process of quick prioritisation in time-critical situations. It Came to software from the medical field, where it was used to categorise the wounded into “can wait”, “needs urgent care”, “hopeless” and “deceased”.
In software development this phrase is used to quickly review bugs. Which ones are trivial, which are worthless etc.
So go to your project’s bug tracker and take a look.
Maybe someone reported a bug with short note but without reproduction steps. If you know how to reproduce the bug: add such steps and confirm that you can reproduce it too. The developer will not have to wonder how to replicate the bug on their system (and believe me: it can be tricky).
Maybe project has some bugs marked with kind of “good first issue” label. Small changes needed to make it done but no one has time to deal with them so they leave them for new contributors.
Sometimes developers design the UI for their apps to fit their use. Which may be in violation of HIG (Human Interface Guidelines) of the desktop project it was written for.
Open a bug, point to UI mistakes, propose how it should be done (even by doing quick edits of screenshot). You do not need to know how to code to be able to do it.
Or you think that UI is overloaded and can be changed to a more readable one. Do some mockups, discuss with project.
None of things above match your background? Fine. Ask project where they need help.
It may sound strange but such needs exist. Been there, done that. Some entries more than once.
There are many non-code ways to contribute to FOSS projects. I have only listed a small subset. Which ones you choose is entirely up to you.
I am excited to let you know that I will be presenting the opening keynote at the OLF Conference in Columbus, Ohio on Saturday, November 21. “You’d better start believing in supply chains because you’re in one” will be a little bit funny, a little bit cynical, and a lot educational. Register now so you can join me in Columbus!
Abstract: āIām not a supplier!ā open source maintainers correctly say. When a large company comes in making unfunded demands, it drives volunteer maintainers away. But supply chain attacks are a reality and they donāt just affect megacorps. As an open source maintainer, you have a supply chain, too.
Improving your security improves safety for everyone. But how can volunteer maintainers who arenāt security experts do this work? This talk introduces easy practices and tools to address common software supply chain concerns. Attendees will also learn how to address supply chain and regulatory concerns from their downstreams.
Date: 21 November 2026
Location: Columbus, OH, US
The post Keynote at OLF Conference appeared first on Duck Alignment Academy.
Two weeks of links and quite a few urbanism ones, mostly about the new Oxford Street. I recommend the podcast about the “fat bikes” ban in the Netherlands.
The engineering articles about Coding Alone and small-change code reviews are very good too.
Interview with Eric Ries: AI, Founder Mode, and Why Good Companies Go Bad - “MVPs are still misunderstood, even after 15 years” - this won’t change, ever.
admin )
on 2026-10-27 17:31:42 UTC
You attended the F45 Virtual Release Party!
So I’ve been hiding a secret from you all for sometime… The Raspberry Pi 5 has worked out of the box on Fedora since the F-44 release!!
Basically I’ve just not had the time to write it up properly, but this blog on the RPi5 on bootc (why are they testing a EOL release in Oct 26?!) reminded me it was outstanding.
In short for Fedora 44 we support a MVP (Minimum Viable Product) of the Raspberry Pi 5! My previous post on the RPi5 went a little viral, there’s been thousands of downloads of the images since. I was procrastinating since the release of Fedora 44 in late April because I wanted to fix one particular issue which is now fixed in Fedora 45 and as an updated for F-44.
As a MVP there’s of course a number of caveats but the key things are working, which make it quite a usable device, as as follows:
Since the Fedora 44 release there have been more features headed upstream through various contributors, including myself, and finally there seems to be a level of contributors growing to get the Raspberry Pi 5 into usable shape. These improvements are of course making it back into Fedora so the features available have been growing since the F-44 release in May.
For Fedora 44 release you need to have a temporary workaround when booting. If you update to the latest kernel/firmware straight away this isn’t then needed beyond the first boot. The workaround isn’t needed for Fedora 45 so if you’re going to try this out I suggest you go and grab your favourite flavour of Fedora from the Fedora 45 release candidates and jump straight in there! You will get an accelerated desktop with storage/network/USB. There’s not currently any support for sound and a number of other things.
So for Fedora 45 you can just flash it as you would for any other Raspberry Pi, including on NVME. If you wish to use Fedora 44 you’ll need to flash with the following option for arm-image-installer (example is for Workstation):
Fedora 45:
arm-image-installer --resizefs --target=none --media=/dev/sdb --image=Fedora-Workstation-Disk-45-1.2.aarch64.raw.xz
Fedora 44:
arm-image-installer --resizefs --target=none --args="cma=256M@0M-1024M" --media=/dev/sdb --image=Fedora-Workstation-Disk-44-1.7.aarch64.raw.xz
We will of course to be improving things further moving forward including RPi500/CM5 support. I look forward to hearing of what people get up to with their RPi5s running Fedora!
jflory7 )
on 2026-10-27 08:00:00 UTC
Walking up to the Fedora & CentOS booth on the first day of DevConf US in Boston, I was not quite sure what to expect. Although I have attended the Czech Republic variant of DevConf several times, this was my first time attending the US event. I was there as part of Red Hatās joint Fedora and CentOS community presence. What I found over those two days was not just a chance to hand out stickers and talk to Fedora Linux users. It was a useful reminder in what the Fedora event strategy needs to become.
DevConf US is a community conference focused on developers and Red Hat technologies. Being held on the Boston University campus during the academic semester meant we knew we would see students. What I did not fully anticipate was how the increased student presence here would reshape what I thought our booth should accomplish.
Alongside my colleagues Shaun McCance, Matthew Miller, Amy Marrich, and To Hung Sze, we staffed a joint Fedora and CentOS table. We kept the booth table light, compared to other events. We did not have any laptop demos, elaborate staging, or any fancy technical displays. We brought ourselves and our trusty Pelican event box full of stickers, lanyards, pins, and swag.
Most people who stopped by the table already knew Fedora, or at least recognized the logo. Most were students, but not all. We also met faculty members, industry professionals, and contributors to other open source projects. However, there was an unmistakable pattern among the students who approached us. For nearly all of them, their first real exposure to Linux happened in university computer science labs. And in university labs, Ubuntu is almost universally the default.
For these students, Ubuntu was not simply a distribution preference. For them, Ubuntu was Linux.
What surprised me most was that they were not defensive about it. They were genuinely curious. They wanted to understand what else was out there, how different systems fit together, and why alternative distributions mattered. The subsequent conversations with those students are some of the most interesting, fun conversations to have at a Fedora booth.
That curiosity opened the door to talk about Fedoraās foundational place in the broader Linux ecosystem. When you use Fedora, you are standing directly at the upstream source of enterprise Linux everywhere.
For the curious, the pitch goes something like this. Every three years, Fedora branches to become the foundation for CentOS Stream, which in turn feeds directly into Red Hat Enterprise Linux (RHEL). However, the reach does not stop with Red Hat products, which is often unknown to most students. Downstream enterprise rebuilds like AlmaLinux and Rocky Linux trace their lineage back through CentOS Stream to Fedora. Furthermore, hyperscalers stand out as interesting downstream operating systems too. For example, Amazon Linux is derived from Fedora Linux. And this year, Microsoft announced that Azure Linux, their custom hypervisor container OS, will base its future architecture on Fedora.
So, when you study and use Fedora, you are not just learning another distribution. You are standing at the mouth of the river. You see the innovations before they flow into every major cloud provider and enterprise datacenter in the world.
The students understood that value proposition immediately. They grasped the architectural power of being upstream. However, the conversations that truly resonated were not about packaging flags or kernel versions. They were about careers.
Students were asking how to build practical skills, how to level up beyond coursework, and what industry engineering teams actually look for. A handful asked specifically about how to contribute to open source and get involved with Fedora.
That is where I realized what our booth was missing. We had no clear call to action.
We could explain the architecture, and we could illustrate the ecosystem on a whiteboard, but we could not smoothly shepherd someone from curiosity to contribution. We lacked a concrete on-ramp. We had no printed guide explaining the first three steps to take after leaving the venue. We had no five-minute interactive exercise someone could complete right at the table to earn something tangible. Instead, we offered a sprawling overview of "everything you can do in Fedora," which is paralyzing when you are just getting started.
Years ago, as a student at RIT and a Fedora Ambassador, I staffed more than a few Fedora booths at collegiate hackathons like HackMIT and Bitcamp. Back then, I learned a vital lesson about engaging students: they need hands-on, achievable activities.
Students need something doable, self-contained, and repeatable. Most importantly, they need something they can earn. A unique reward, like an event badge or a milestone achievement, creates an enduring memory. A standard sticker gets lost in a backpack; a challenge you solved at a booth creates a personal reason to stay connected to the community.
Executing a commercial trade-show booth strategy at a student-heavy venue does not work. Commercial attendees often browse passively for vendor solutions; students are actively planning their futures and want to understand how distributed engineering collaboration functions in the real world. Free Software and open source are precisely that, but we have to frame them to meet their goals.
If we want to translate curiosity into long-term community contributors, our playbook needs three tangible upgrades:
Tailored on-ramp materials: Brief, well-structured guides that explain what our sub-projects do and provide clear first tasks for beginners.
Audience-specific talking points: Equipping booth ambassadors with prompts geared toward early-career engineers, highlighting the practical career value of public upstream contributions.
Interactive booth challenges: Short, five-minute exercises that allow attendees to make a small contribution, file a test ticket, or solve a puzzle right at the table.
So, should Fedora & CentOS return to DevConf US? Absolutely. DevConf US is a fantastic venue, but next time we must arrive prepared for the audience in the room. The curiosity is already there. We just need to build the bridge that lets them cross over into upstream work.
Across the Fedora ecosystem, the primary focus this week was the final preparation for the Fedora 45 release, which saw a NO-GO decision push its target launch to November 3 due to critical blocker bugs involving eMudhra certificates and Stratis encrypted pools. Simultaneously, a major cross-team effort is driving the "Atomic Fusion" Bootable Image Unification initiative, with groups like Atomic, CoreOS, IoT, and Hummingbird actively drafting Architectural Decision Records (ADRs) and migrating workflows to the new Forgejo platform. Security and maintenance also dominated the technical SIGs, particularly within the Rust, EPEL, and CoreOS teams, who rushed to patch vulnerabilities related to the eMudhra CA compromise. Finally, community and leadership groups are already looking ahead to the project's broader future, laying the groundwork for FOSDEM 2027 planning and drafting unified themes for the upcoming Flock 2027 Call for Proposals.
Fedora 45's release is slightly delayed, as outstanding blocker bugs resulted in a NO-GO decision during the October 22 Go/No-Go meeting, pushing the target release date to November 3. When it does arrive, Fedora 45 will introduce a major technical shift by modernizing the virtual console with kmscon, moving away from the legacy kernel fbcon driver to a userspace utility for better font and keyboard layout management. Behind the scenes, package maintainers will be pleased to hear that s390x build infrastructure is receiving much-needed performance improvements, thanks to memory and CPU adjustments made in collaboration with IBM. Once the dust settles on the final release, the global community is invited to celebrate at the Fedora Linux 45 Virtual Release Party scheduled for October 30.
The latest Fedora Podcast (Episode 062) dives into the technical details of Fedora Hummingbird Linuxāa bootable container image built on an RPM channelāand the engineering team is actively soliciting real-world use cases from listeners. This request for engagement comes on the heels of the highly positive Q3 2026 Fedora Podcast Report, which highlights sustained evergreen growth, over 14,000 YouTube subscribers, and a strong audience preference for technical, contributor-focused content.
The Fedora Council met this week to discuss themes for the Flock 2027 Call for Proposals (CfP) and evaluate a request to extend the Docs initiative. For Flock 2027, the Council is drafting themes structured around the "Four Foundations" to encourage interactive discussions, panels, and collaborative sessions. Regarding the Docs team, while the formal initiative framework has been stood down, the Council acknowledged the critical need to deeply integrate Docs into Fedora's standard processes and pledged to explore alternative ways to provide support and visibility.
On the forums, discussions continued regarding the "Atomic Fusion" Bootable Image Unification efforts. Agendas were published to address Architectural Decision Records (ADRs), Konflux integration, tenant setup, and the migration of base image work to Forgejo. Reminders were also shared for the Fedora 45 Final go/no-go meeting and the upcoming F45 release party.
Learn more about the Council team.
This week, FESCo held a meeting and processed multiple tickets, primarily focusing on system-wide changes, Bugzilla replacements, and infrastructure performance. The committee officially approved system-wide changes for the Crystal programming language and Libical4, and granted a FastTrack update exception for gedit 51.0 in Fedora 45.
Discussions continued around the future of Fedora's issue tracking system and the potential transition away from Red Hat Bugzilla, with planning meetings rescheduled for November. FESCo also reviewed Koji architecture performance metrics for non-x86 builds, discussing potential thresholds to prevent bottlenecking the build system.
crystal-rpm-macros, cr2rpm, vim-crystal, crystal-lang, and shards). The requester is open to doing review swaps.Learn more about the FESCo team.
This week, the Packaging Committee focused on establishing packaging guidelines for the Crystal programming language and updating system CryptoPolicies. Following FESCo's approval of the System-Wide Change for Crystal in Fedora 46, contributors have readied the draft packaging guidelines for final committee review, supported by successful Copr test builds and several submitted Stage 1 package reviews.
Additionally, a pull request was submitted to align the aws-lc CryptoPolicies exception with a recent FESCo decision. The proposed change clarifies the guideline text to ensure that using aws-lc-rs and aws-lc-sys for low-level cryptography and enabling TLS functionality via Rustls is explicitly permitted.
aws-lc-sys and aws-lc-rs for low-level cryptography and TLS functionality via Rustls, which the committee is currently documenting in the guidelines (FESCo Ticket #3679).Learn more about the Packaging Committee team.
Mindshare finalized expense reimbursements and event reports for several recent gatherings, including Software Freedom Day Bukidnon 2026, IndiaFOSS 2026, and LinuxDays 2026 in Prague. Governance restructuring is also a major focus this week, as the committee assesses which community subprojects should fill newly vacant representative seats.
In broader community news, contributors engaged in a detailed forum discussion regarding the ethical, legal, and operational trade-offs of integrating generative AI models into Fedora workflows. The conversation highlighted the tension between hardware-efficient open-weight models (like Nemotron) and strict adherence to Free Software principles (like Olmo), alongside potential EU AI Act liabilities if the project provides centralized inference services.
Learn more about the Mindshare team.
This week, the Fedora Join group focused on refining their onboarding processes and finalizing their platform migration. The team successfully merged a rewritten onboarding issue template (issue #348) and updated it to automatically tag team members on new welcome tickets (issue #353). Ongoing efforts include identifying missing components for the Forgejo migration and coordinating the "Beginners Guide" brochure update.
Additionally, the group welcomed a new contributor, Blu3 (Usman), who is studying computer engineering and building a PipeWire-based audio daemon. They are interested in contributing to Workstation Quality Assurance, packaging, and IoT.
S: User contributes upstream) was created to accurately track newcomers who ultimately decide to contribute directly to upstream projects instead of Fedora, acknowledging this as a positive outcome for the broader open-source community (issue #350).@join/Members and @join/Owners to ensure the team is immediately notified of new contributor tickets (issue #353).!welcome Zodbot command to finalize their migration to Forgejo. Anyone familiar with Fedora's matrix-bot playbooks or repositories is encouraged to help on issue #319.Learn more about the Fedora Join team.
Planning for FOSDEM 2027 is officially moving forward, with a formal call for participation now open to the community. Applications for a Fedora stand and the Distributions DevRoom have been successfully submitted for the January event in Brussels, co-owned by Justin Wheeler and Daniel Mellado.
Additionally, a shared hotel block for Fedora and CentOS contributors is being organized at the DoubleTree by Hilton Brussels City. Community members interested in attending are encouraged to review the available assistance and stay connected for updates on the FOSDEM 2027 Wiki.
The Ambassadors are looking for contributors to help support Fedora's presence at FOSDEM 2027. You can get involved by replying on the mailing list or the Fedora Discussion topic. Opportunities include:
Learn more about the Ambassadors team.
This week, the Workstation/GNOME group focused on preparations for the Fedora 45 release and potential desktop feature improvements. The Working Group published the agenda for their October 20 meeting, highlighting topics such as Fedora 45 blockers, AppStream data automation, DNF 5 updating without wheel privileges, and the inclusion of AI tools like Newelle. Additionally, Fedora QA announced the upcoming Fedora 45 Blocker Review Meeting to evaluate remaining issues before the final release.
In broader desktop news, a community member shared a proposed modern implementation for restoring Google Drive integration in GNOME. Instructions are available for Fedora 43 and 44, and user feedback is highly requested to help get the feature upstreamed.
Learn more about the Workstation / GNOME team.
This week, the KDE group focused heavily on preparing for Fedora 45 and the upcoming Plasma 6.8 release. Significant packaging work is underway, including rebuilding several packages due to a libplasma soname bump, addressing FTBFS (fails to build from source) issues, and drafting the Fedora 45 release magazine article. Additionally, a major milestone was reached as the group announced the complete retirement of Plasma X11, removing associated packages for Plasma 6.8.
Meanwhile, users were warned about a severe compatibility bug with KeepassXC on Wayland, and QA preparations for the Fedora 45 final release are actively calling for community participation in blocker bug reviews.
kwin-x11 and plasma-workspace-x11 (Ticket #733).kcm_wacomtablet and kgamma packages will no longer receive updates starting in Plasma 6.8 (Ticket #727).Learn more about the KDE team.
The Server Working Group reviewed Fedora 45 Release Candidate (RC) testing, confirming that the longstanding KVM image issue is resolved in RC 1.2. The group also addressed the growing size of distribution images and continued coordinating the setup of test environments for the Ansible support project.
On the mailing list, the agenda for the October 21 meeting was circulated, and Adam Williamson announced the F45 Blocker Review meeting scheduled for October 26. Members were also reminded of a temporary one-hour meeting time shift due to daylight saving time differences.
Learn more about the Server team.
This week, the Fedora Infrastructure team managed several intermittent service disruptions, including FAS/IPA login issues where users received "bad credentials" errors but were able to log in after multiple attempts. The team also mitigated DDOS attacks affecting fedorapeople.org and Koji s390x builders, deployed two new NA proxies to handle high connection loads, and quickly addressed spam waves on the mailing lists. Additionally, the staging instance of Fedora Docs was successfully transitioned to build from the new docs/site-builder repository on the staging Forge.
In other news, a community member is developing a link-checking tool for Fedora Docs, which sparked discussions about prioritizing the triage of legacy Wiki content rather than attempting to maintain it. The team is also evaluating solutions for a captive portal detection issue affecting KDE Plasma users, caused by the fedoraproject.org domain being on the HSTS preload list. Finally, a new Digital Still Photography Device SIG requested infrastructure resources.
mirrors.wcupa.edu EPEL mirror was temporarily removed from the mirror list until its incomplete TLS chain issue is resolved. (Issue #13632)docs/site-builder repository on the staging Forge. (Issue #13624)nightdrive, was created to own a Copr group project. (Issue #13630)ai-code-review used for LLM code reviews on Forgejo. (Forum post)Learn more about the Infrastructure team.
This week, the Release Engineering team focused heavily on preparing for the upcoming release, successfully generating the first Fedora 45 Release Candidates (including RC2) after executing necessary stable pushes. Several blocker review meetings were held to evaluate critical bugs, including those affecting desktop environments and installation processes. In addition to routine maintenance tasks like processing package unretirement requests and resolving stuck Koji builders, the team completed stable pushes for Fedora 43 and 44 to deliver important updates for PHP and ca-certificates.
The community also engaged in forward-looking infrastructure discussions. Notably, there was a proposal to test and potentially integrate a highly optimized, Rust-based alternative to createrepo_c called kiritan. Furthermore, preparations have begun for implementing Post-Quantum Cryptography OpenPGP Signatures for Fedora 48, with tickets opened to coordinate staging and deployment.
initial-setup occasionally missing on serial console) as Fedora 45 Final Blockers (Review Meeting).gnome-shell-extension-dash-to-panel upgrades, flare-im CVE mitigation, and mkvtoolnix buffer overflow mitigation.python3-blessings, urdfdom, fcl, python-yaspin, retext, python-markups, and bup.subatomic and kiritan (a faster, memory-efficient, Rust-based alternative to createrepo_c) is seeking feedback and invites collaboration with Fedora to test and potentially integrate these tools into Fedora's infrastructure (Join the discussion).Learn more about the Release Engineering team.
The Quality team focused heavily on evaluating Fedora 45 Release Candidate 1.2 for the Final release. During the F45 Final Go/No-Go meeting, the team declared the release a NO-GO due to outstanding blockers, particularly related to eMudhra certificates and Stratis encrypted pools. Consequently, the F45 Final release date has been pushed to target date #2 (November 3, 2026).
In addition to release management and blocker review meetings, QE worked on release validation and expanded openQA testing with Turkish and Arabic webUI install tests. The community also coordinated ongoing and upcoming Test Days, including testing for GRUB EFI for confidential computing, Podman Conmon-v3, and the upcoming Kernel 7.3 release.
ip= on s390x) and Bug 2552449 (Stratis root drops to emergency mode after unanswered prompt) were rejected as blockers.Learn more about the Quality team.
This week, the Websites and Apps team resolved a caching issue on the Fedora CoreOS download page. By implementing stricter cache-control headers, the team ensured that new releases are displayed correctly to users without delay, which was discussed in the Fedora Websites Matrix room. The team also discussed a community suggestion to add an announcements section to the main Fedora homepage, prompting conversations about better visibility for the Fedora Start page and potential collaborations with the Design team. Additionally, an inquiry was raised about the Nuxt-based website's potential vulnerability to the Node2Shell exploit (CVE-2026-111497).
On the forums, contributors discussed the current status of the Fedora Wiki, clarifying that while it is no longer used for actively maintained documentation, it remains crucial for change proposals, event organization (such as FOSDEM 2027), and historical reference. In a separate thread, feedback regarding the verbosity of LLM code reviews on Forgejo was addressed by pointing contributors to the upstream ai-code-review tool.
Cache-Control: no-cache, no-store, must-revalidate header to fix caching issues on the Fedora CoreOS download page, ensuring users always see the latest release data (Matrix Chat).fedoraproject.org/start page under the "Connections -> News & Publications" section of the website footer. (Matrix Chat)Learn more about the Websites and Apps team.
The Fedora Design team canceled their weekly meeting due to a scheduling conflict with "We Are Red Hat Week." Meanwhile, a developer from the Anaconda project requested co-maintainer access to the design packages repository to help manage branding CSS updates for the new WebUI. They also submitted a pull request adding a Makefile target for tarball creation and plan to tag the main branch for the 46.0.0 release. The team plans to meet to discuss repository maintainership topics moving forward.
Learn more about the Design team.
The Docs team had an active week focused on consolidating and standardizing their documentation pipeline, discussing site architecture improvements, and preparing for the upcoming Fedora 45 release. Major technical themes included plans to unify preview and production builds into a single container image to streamline local authoring, standardizing on Podman for local builds, and exploring Arm64 architecture support to aid contributors using Apple Silicon or other AArch64 hardware. Discussions also progressed on adopting new CI tooling to identify broken anchor links across the documentation site.
Administratively, the team discussed their representation on the Mindshare Committee and reviewed their ticketing strategy, ultimately deciding that compartmentalizing issues into repository-specific trackers is preferable to a monolithic ticket queue. Several Fedora 45 release notes were merged, including documentation for new LibreOffice dictionaries and Emacs 31, while team members noted that the Fedora 45 release date has slipped to at least October 27, though the Release Party date remains firm.
prod branch to main across repositories, and confirmed that documentation content will be licensed under CC BY-SA-4.0 (Issue #19).site-builder to better communicate its scope and purpose to contributors (Issue #20).docs organization's issue trackers, rather than tracking the team's Matrix chat channel directly (Issue #63).bruce, a newly developed tool that crawls documentation for broken links and anchors, into the CI pipeline for nightly reports (Issue #69).Learn more about the Docs team.
This week, the EPEL team focused heavily on package maintenance and addressing critical security vulnerabilities. Notably, important updates for uv (0.13.x) and ruff (0.17.x) have been sent to testing for the EPEL10 leading branch to address several Rust security advisories and the eMudhra intermediate CA compromise. Additionally, contributors are evaluating a potential upgrade of ffmpeg to resolve a high-severity Heap-buffer-overflow vulnerability and opened pull requests to patch djvulibre (CVE-2025-53367) across multiple EPEL branches.
The team is also tracking efforts to bring incus 7.0.0 and mailman3 to EPEL10, along with preparing for the EPEL 10.2 retirement process. Furthermore, new documentation regarding EPEL build tagging was officially completed and published.
uv and ruff will be pushed to stable in the EPEL10 leading branch after at least one week in testing, bringing security fixes and minor breaking changes.ffmpeg to confirm if version 7.1.5 is genuinely vulnerable before undertaking an incompatible rebase to version 9.0.mailman3 packages in EPEL10 to ease the Release Engineering workload as Mailman is migrated to RHEL10 infrastructure.incus package (version 7.0.0 LTS) into EPEL 10; tracking bugs for dependencies raft and cowsql have already been opened.Learn more about the EPEL team.
The ELN SIG held a meeting to discuss the status of RISC-V integration and boot.iso image building. For RISC-V, riscv-koji is now configured for ELN with the RVA23 baseline defined. However, a glibc build failure occurred because valgrind does not support RVA23, which requires addressing %valgrind_arches before proceeding further. Additionally, work is ongoing to resolve technicalities with creating a boot.iso using image-builder.
Due to upcoming contributor absences, the group evaluated their meeting schedule and chose to skip the following week, reconvening in early November.
Learn more about the ELN team.
This week, the Atomic group made significant progress on the Bootable Image Unification initiative, successfully closing out their migration from GitLab to the new Fedora Forgejo under the "Atomic" organization. Discussions heavily focused on setting up new build pipelines, finalizing Architectural Decision Records (ADRs) for tier systems, and establishing a bootable seed image to serve as a foundational testing layer across different architectures.
Additionally, community members raised technical questions regarding rpm-ostree stable commits temporarily bundling packages from updates-testing before they hit stable repositories. A separate packaging request for crun-krun resulted in the recommendation to utilize system extensions (sysexts) to maintain the current policy of keeping virtualization software out of the core system.
crun-krun will be kept out of the core system for now, with system extensions (sysexts) established as the preferred delivery method.aboot or systemd-boot) are needed to help drive the creation and testing of alternative seed images.crun-krun for container management isolation are invited to contribute to creating a Fedora system extension (sysext).Learn more about the Atomic team.
This week, the CoreOS group held a community meeting to review the Fedora 45 Release Schedule, verifying readiness for the final target date. They also prepared agendas for the Bootable Image Unification ("Atomic Fusion") meetings and published the weekly newsletter to highlight recent community contributions.
On the development side, several significant updates were processed on the tracker. The team enabled aarch64 support for kubevirt image builds and addressed an upstream LVFS CDN outage affecting CI. Furthermore, they made progress investigating a kernel file corruption issue on ext4 upgrades, released fixes for a ppc64le NETLINK_AUDIT rootless container bug, and updated Konflux to handle override lockfiles directly.
ca-certificates in response to the eMudhra intermediate certificate compromise (also discussed in the meeting).aarch64 kubevirt image builds moving forward, allowing users building or consuming aarch64 images to get kubevirt artifacts matching existing x86_64 coverage.nodioread_nolock) to prevent ext4 kernel file corruption during FCOS upgrades.Learn more about the CoreOS team.
This week, the Fedora IoT group focused heavily on the ongoing Bootable Image Unification ("Atomic Fusion") efforts and final release preparations. Contributors discussed the agendas for the bootable image unification meetings and subsequent follow-ups, prioritizing Architectural Decision Records (ADRs), migrating base image work from GitLab to Forgejo, and configuring Konflux integrations. The group is actively exploring how a tiered image system will function, generally leaning toward utilizing lower-tier images as base layers in subsequent builds.
On the engineering front, the Fedora 45 IoT Final candidate compose was successfully created and published for testing. Additionally, contributors are engaged in a technical evaluation regarding device-specific Fedora ARM images. There is an active debate on the trade-offs of shipping pre-built, device-specific images for popular hardware like the Raspberry Pi or AI SOM devices at the build stage, versus maintaining the current user-side arm-image-installer workflow to avoid the overhead of maintaining hundreds of unique image variants.
Learn more about the IoT team.
Adam Williamson announced the upcoming Fedora 45 Blocker Review Meeting, scheduled for October 26, 2026, at 16:00 UTC on Matrix. The team will be evaluating one proposed blocker and two proposed freeze exceptions for the Final release to determine if they violate any release criteria.
Learn more about the ARM team.
The Hummingbird group continued discussions regarding the bootable image unification effort (also known as "Atomic Fusion"). During the October 22 meeting, the agenda focused on Architectural Decision Record (ADR) updates, the ongoing migration of base image work from GitLab to Forgejo, seed work proposals, and setting up Konflux integration for service accounts.
Additionally, in a follow-up to the October 8 meeting, participants clarified the proposed image tiering system. While the exact mechanisms are still being formalized in ADRs, it was noted that lower-tier images will likely be used as the base container (FROM) for subsequent builds by next-tier owners.
Learn more about the Hummingbird team.
The Kernel group saw activity across two main mailing-list discussions this week. Justin Forbes announced the regular rebase of the kernel-ark os-build branch, a process that aligns with every upstream release to ensure carried patches remain up to date, though it requires outstanding merge requests to be rebased.
Additionally, Michel Lind provided an update on the RFC to split perf out of the kernel packaging. Lind noted that while the split might not drastically affect Rawhide, it would allow stable releases to receive perf updates faster and prevent perf dependencies from polluting the kernel build. Lind plans to follow up with the CentOS/RHEL teams to ensure packaging does not diverge.
kernel-ark os-build branch has been rebased to align with the latest upstream release, which invalidates outstanding merge requests and requires contributors to rebase them.Learn more about the Kernel team.
The AI group had a productive week centered on infrastructure expansion, preparing for the Fedora 45 release, and debating the integration of AI models in the distribution. Community CI hardware arrived and is currently being installed. Meanwhile, packaging and integration efforts advanced with the addition of agentic AI tools like openclaw and pi-coding-agent into Fedora, tying into existing ollama or llama-cpp packages. Additionally, ROCm was updated to version 7.2 in preparation for future releases, and a fix for ROCm's __noinline__ problem was backported to F44.
The SIG also engaged in a broader philosophical and technical discussion regarding which LLM models align best with Fedora's Free Software foundations. Members weighed the performance of open-weight models against licensing transparency, environmental impact, and potential regulatory liabilities (like the EU AI Act) when providing centralized inference infrastructure. The group is exploring model-agnostic harnesses to allow shared infrastructure experimentation without locking the community into a specific, potentially non-compliant model. Finally, the AI-ML SIG was successfully added to the Fedora Engineering Teams documentation page.
Learn more about the AI team.
The RISC-V group successfully generated and is actively testing the Fedora 45 final images, including custom "Omni" kernel builds (v7.3) that support newer hardware like the Milk-V Titan and K3. Concurrently, progress continues on the Fedora ELN bootstrap and Fedora 46 image generation. In community news, the RISC-V devroom has been accepted for FOSDEM 2027 as a half-day track.
Additionally, the team is heavily focused on debugging hardware-specific build issues that impact broader Linux ecosystems. This includes cross-distribution collaboration with Debian developers to troubleshoot a GCC build failure on K3 caused by vector register state corruption, as well as investigating glibc crashes on Titan that reliably trigger on certain packages.
pthread_mutex_cond_lock crashes on Titan hardware, which are consistently causing build failures for packages like opam and python-astropy.Learn more about the RISC-V team.
The Go SIG met this week to troubleshoot a build failure on ppc64le architectures caused by a PIE issue involving the golang-x-sys package. The issue has caused cascading failures in downstream projects, including rootlesskit, chezmoi, and any package relying on fatih/color. A repository query revealed that approximately 231 packages bundling golang-x-sys on ppc64le could be impacted.
During the meeting, participants discussed a failed pull request and a COPR build SIGSEGV error. The group concluded that fixing the root cause directly within the golang-x-sys package should safely resolve the downstream breaks.
x/sys package for ppc64le to address the downstream breaks and notify the SIG once resolved (see meeting logs).Learn more about the Go team.
This week, the Perl group focused entirely on routine maintenance and package updates, generating 17 mailing-list posts. Contributors Jitka Plesnikova and Michal Josef Å paÄek submitted and successfully merged a series of pull requests to keep the ecosystem secure and up to date.
Notable activities included creating an EPEL10 version for cpanspec and updating several core Perl packages. The bumps included version updates for perl-DBI, perl-URI, perl-DBD-MySQL, perl-Mozilla-CA, perl-Dist-Zilla, and perl-XML-Twig.
cpanspec package.perl-Mozilla-CA, ensuring root certificates are up to date.perl-DBI, resolving bug rhbz#2554771.perl-URI.perl-DBD-MySQL.perl-Dist-Zilla.perl-XML-Twig.Learn more about the Perl team.
The Ruby group is actively testing the newly started Ruby 4.1 development. Initial ecosystem rebuilds against the C API have uncovered a few issues, including a test failure in rubygem-ffi linked to an upstream Ruby bug, and build failures in older packages due to the Data_Wrap_Struct macro deprecation.
Additionally, standard libraries net/pop and net/ftp have been removed from Ruby 4.1's bundled gems. This change breaks dependencies for several major packages, including Ruby on Rails (via rubygem-mail), notmuch, and Vagrant-related packages, necessitating the creation of new standalone packages for these gems to restore ecosystem functionality (discussion).
rubygem-net-pop as a standalone gem, which is required to fix failing dependencies for Ruby on Rails and notmuch (discussion).net/ftp to resolve dependency issues for Vagrant-related packages.Data_Wrap_Struct macro to the newer TypedData_Wrap_Struct (as was recently done for rubygem-eventmachine).Learn more about the Ruby team.
A major focus this week was addressing numerous security advisories across various Rust crates, particularly concerning outdated TLS and cryptographic libraries. Contributors have been actively rebuilding and patching packages to mitigate vulnerabilities in rustls (updating to v0.23.46), webpki-roots (addressing the eMudhra CA compromise), ruzstd, zip, and faster-hex.
In conjunction with these security updates, a mailing list proposal was introduced to completely drop older, vulnerable versions of reqwest (\<0.12) and rustls (\<0.23) from the repository. This cleanup aims to remove CA bundles that are known to be broken and TLS libraries that are no longer receiving patches, which will require porting or dropping several dependent applications.
zip crate to address high and critical security flaws will be deferred until the rustls and webpki package updates have stabilized to avoid conflict and capacity issues (Issue #47).webpki-roots 1.0.11 to mitigate the eMudhra Intermediate CA Compromise (Issue #46).rust-onefetch, helix, and stgit, were rebuilt with faster-hex v0.10.1 to address a security advisory (Issue #45).reqwest (\<0.12) and rustls (\<0.23) to eliminate unresolved security issues (Mailing list thread).rustls v0.22 or v0.21 to newer, secure versions (Issue #43).basic-toml and toml v0.5 need to be updated or cleaned up, as basic-toml is now officially marked unmaintained (Issue #19).mdsh package has been offered up to be orphaned or retired due to its obsolete structopt dependencies, providing an opportunity for a new maintainer to step up or for the package to be formally retired (Issue #22).zip crate to address multiple security advisories once earlier updates stabilize (Issue #47).Learn more about the Rust team.
whatsapp-desktop, an independent desktop client, and is still seeking a package reviewer and sponsor for the source-only application.stdexec (required for hpx-2.0), with Cristian Le suggesting that patching CMake to use find_package and packaging rapids-cmake would be the best approach.%gpgverify macro with %openpgpverify for the Fedora 45 Sequoia transition, advising maintainers to update expired upstream keys and refresh keyrings.shim-unsigned-riscv64 package for Fedora RISC-V, seeking package review and offering to sponsor its creator.perf out of kernel packaging, packaging advice for a module structure change in PyMuPDF 2.0, a license change in perl-Test-Simple-1.302226, audit logging plans for an Unprivileged eBPF RBAC Daemon change proposal, an upcoming F45 Blocker Review Meeting, outcomes from the Fedora Council Bi-Weekly Agenda, and updates across the Fedora Docs Matrix chat.slic3r since it is upstream dead, proposing to package SuperSlicer or OrcaSlicer instead.libfyaml because they no longer use it.grpc is severely outdated, causing package conflicts and blocking F45 upgrades, which led to a broader discussion about unresponsive maintainers and failing rebuild attempts in COPR.uv (0.13.x) and ruff (0.17.x) across F43-F45 and EPEL10, noting that these versions fix a recent CA compromise issue and have updates policy exceptions.dnf offline-upgrade to prevent system breakages.ddcutil update to 3.0.2, noting a backward-compatible soname bump that did not break dependent packages like fastfetch and powerdevil.python-reportlab 5.1.0 for F44+ and EPEL10, asking maintainers to verify compatibility with dependent packages.Community members are highly encouraged to help test upcoming software and architectural changes, a crucial skill that requires no prior group membership. Testers are needed to validate the proposed restoration of Google Drive integration in GNOME and to participate in the Kernel 7.3 Test Week. You can also provide critical feedback on system-level components by evaluating alternative bootloaders for Atomic images, testing Fedora 45 final images on RISC-V hardware, and verifying ROCm AI/ML builds on AMD GPUs. Furthermore, anyone can evaluate release criteria by testing and voting on proposed Fedora 45 blocker bugs and freeze exceptions across editions like Workstation, KDE, Server, and ARM.
Developers and software packagers can jump into several active initiatives across various ecosystems. Reviewers are actively sought for the Stage 1 package reviews of the new Crystal Language toolchaināwith review swaps offeredāand the whatsapp-desktop application. The Rust SIG needs assistance updating dependencies like reqwest and rustls or adopting orphaned packages like mdsh, while the Ruby community is seeking maintainers for rubygem-net-pop. If you prefer coding for infrastructure and automation, pull requests are welcome to improve the output formatting of the AI code review tool on Forgejo, help is needed to fix a Matrix bot playbook migration, and volunteers are sought to write an Ansible playbook for tracking groups.
Contributors with technical writing and design skills have multiple avenues to leave their mark. The Documentation team invites first-time contributors to refactor the Quick Docs contribution guide to prioritize local authoring setups, and needs writers for upcoming Fedora 45 release notes. You can also review the current draft of the "What's New in Fedora KDE" magazine article, submit pull requests to the new CoreOS newsletter repository, or collaborate on updating the beginner's joining brochure. On the web side, the Websites and Apps team is coordinating a homepage redesign to add an announcements section and needs help updating the global site footer.
Finally, you can help shape Fedora's strategic direction and global presence through community organizing and providing architectural feedback. The Council is looking for comments on the Flock 2027 Call for Papers themes, and community members are invited to evaluate Bootable Image Unification architectural records. If you are passionate about community representation, there are open seats on the Mindshare Committee for underrepresented subprojects like AI or Moderation. Event enthusiasts can volunteer to support Fedora at FOSDEM 2027 by speaking, running the distributions devroom, or staffing the Fedora booth.
Scrapers are DDOsing version fedoraproject applications.
We are working to mitigate things. Some endpoints may be unavailable as we work to mitigate the attack.
renich )
on 2026-10-24 08:25:00 UTC
Yesterday I was auditing a batch of Crystal projects on my Fedora workstation, and it hit me how much the day-to-day code review threat model has shifted.
For years, if you wrote Crystal, your static analysis workflow was straightforward: you ran the compiler for type safety and Ameba for style and code smells. And la neta, Ameba is fantastic at what it does. It catches unused variables, cyclomatic complexity, and formatting drift before they pollute your repository.
Today, however, you face two problems that a style linter was never designed to solve:
That is where flaw comes in. Created by kdairatchi, flaw is a fast, zero-dependency static security and code-hygiene scanner built specifically for Crystal. Even better, I just packaged it natively for Fedora Linux inside the renich/crystal Copr repository as part of the ongoing push to bring the entire Crystal ecosystem into official Fedora and EPEL repositories.
In gemology, a flaw is an internal fracture or inclusion inside a crystal that you spot by holding the stone up to the light. Let me show you how flaw holds your Crystal codebase up to the light, how its AST and taint engine works under the hood, and how you can install it on Fedora in ten seconds flat.
You do not need to clone git repositories or compile toolchains by hand on every workstation or CI runner. Both crystal-flaw and ameba are pre-built for x86_64 and aarch64 in the renich/crystal Copr repository.
Enable the repository and install crystal-flaw with dnf:
# as root
dnf -y copr enable renich/crystal
dnf -y install crystal-flaw
Warning
Make sure you install crystal-flaw and not flaw! Fedora's official repositories already ship an existing package named flawāa top-down wizard battle game from SourceForge. Installing crystal-flaw ensures you get the Crystal static security analyzer instead of a wizard arena game.
Verify your installation right away:
# Verify installed version and rule catalog
flaw version
flaw rules
Note
Because flaw is compiled to a native binary against Fedora's system libraries such as libyaml, pcre2, and gc, startup time is practically instantaneous. You can drop it into local pre-commit hooks without adding noticeable latency to your workflow.
When I inspected flaw's source code before packaging crystal-flaw, I appreciated how pragmatic its architecture is. Instead of forcing every check through a heavyweight compiler pass or relying purely on brittle regular expressions, flaw uses a two-tier scanning pipeline coordinated by Flaw::Scanner:
Tip
If a file contains incomplete syntax while you are actively editing it, Flaw::AstBackend.parse catches the parse exception and gracefully falls back to Tier 1 regex rules without aborting the scan.
The biggest headache with naive security scanners is false positives. If a tool yells at you every time you call Process.run or db.query, you will eventually mute the tool and move on.
flaw avoids this trap through Flaw::Analysis::BindingCollector and Flaw::Taint. Before dispatching AST rules on a parsed syntax tree, flaw walks Crystal::Assign nodes to build a per-file map of local variable bindings. When FLAW001 inspects a system, backtick, or Process.run call containing a Crystal::StringInterpolation, it traces each interpolated expression up to a recursion depth of 3 against known taint sources and sanitizers:
Look at the difference in practice. If you pass user input directly into a shell command or SQL query, flaw catches it red-handed:
# vulnerable_example.cr
def handle_ping(host : String, db : DB::Database, id : String)
output = `ping -c1 #{host}`
db.query_one("SELECT * FROM users WHERE id = #{id}") { |rs| rs.read(String) }
end
Running flaw scan on that snippet produces pinpoint diagnostics with line, column, severity, and remediation advice:
# Output of: flaw scan vulnerable_example.cr
vulnerable_example.cr
3:11 [critical] FLAW001 OS command built from interpolated input
Command built via string interpolation ā pass Process.run an argv array or taint-check the inputs
ā output = `ping -c1 #{host}`
4:15 [high] FLAW003 SQL built by string interpolation or concatenation
SQL built via interpolation ā use parameterised queries
ā db.query_one("SELECT * FROM users WHERE id = #{id}") { |rs| rs.read(String) }
flaw: 2 findings (1 critical, 1 high)
Once you refactor Process.run to pass an argv array, which bypasses /bin/sh entirely, and switch db.query_one to parameterized placeholders like WHERE id = ?, the AST node changes from Crystal::StringInterpolation to Crystal::StringLiteral and flaw passes with zero noise.
Out of the box, flaw 0.1.0 ships with 30 rules split into two distinct namespaces, each mapped to CWE and OWASP Top 10 identifiers for compliance and SARIF reporting.
The FLAW0xx series targets real vulnerabilities that should break your CI build immediately:
| Rule ID | Severity | CWE | Vulnerability Detected |
|---|---|---|---|
| FLAW001 | critical | CWE-78 | OS command built from interpolated input via system, backticks, or Process.run |
| FLAW002 | high | CWE-798 | Hardcoded secret literal via prefix match and Shannon entropy >= 3.5 |
| FLAW003 | high | CWE-89 | SQL built via string interpolation or + concatenation |
| FLAW004 | high | CWE-338 | Non-cryptographic RNG such as rand or Random.new near security-sensitive identifiers |
| FLAW005 | medium | CWE-502 | YAML.parse called on untrusted input |
| FLAW006 | high | CWE-22 | File access with user-controlled path allowing path traversal |
| FLAW007 | medium | CWE-601 | Open redirect to user-supplied URL without allowlist |
| FLAW008 | high | CWE-502 | Unsafe deserialization of untrusted data |
| FLAW009 | high | CWE-328 | Weak hash MD5/SHA1 used for passwords or integrity |
| FLAW010 | high | CWE-295 | TLS certificate verification disabled via OpenSSL::SSL::VerifyMode::NONE |
| FLAW011 | high | CWE-918 | Outbound HTTP request to user-controlled URL enabling SSRF |
| FLAW012 | medium | CWE-208 | Secret compared with == instead of Crypto::Subtle.constant_time_compare |
| FLAW013 | medium | CWE-377 | Tempfile created without atomic O_EXCL |
| FLAW014 | high | CWE-611 | XML parsed without disabling external entities, risking XXE |
| FLAW015 | medium | CWE-915 | Privilege field exposed through Serializable mass assignment |
| FLAW016 | medium | CWE-326 | TLS minimum version pinned to deprecated SSLv3, TLSv1.0, or TLSv1.1 |
| FLAW017 | low | CWE-1333 | Regex pattern with nested quantifiers, risking ReDoS |
| FLAW018 | high | CWE-532 | Secret-named value written to log or stdout |
| FLAW019 | medium | CWE-1004 | Cookie set without Secure, HttpOnly, or SameSite flags |
| FLAW020 | high | CWE-327 | ECB cipher mode used, leaking plaintext block structure |
| FLAW021 | high | CWE-329 | Hardcoded initialization vector, nonce, or salt |
| FLAW022 | high | CWE-22 | Archive entry extracted without path normalization, enabling zip-slip |
| FLAW023 | critical | CWE-347 | JWT accepted with alg: none or verification disabled |
| FLAW024 | high | CWE-942 | CORS wildcard Access-Control-Allow-Origin: * with Allow-Credentials: true |
This is where flaw enters uncharted territory that no other Crystal linter touches. When you pair-program with AI agents or review community pull requests generated with LLMs, certain failure patterns show up over and over again. The FLAW1xx rules specifically hunt down unedited AI artifacts:
Warning
FLAW105 is a lifesaver when working with autonomous coding agents. When an LLM struggles to mock an authentication token in a spec, its favorite shortcut is to comment out the auth guard in your controller so the test turns green. Running flaw scan --fail-on high stops that regression cold before it ever reaches code review.
To configure flaw for a repository, scaffold a default .flaw.yml at the project root:
# Generate .flaw.yml configuration stub
flaw init config
You can exclude directories, disable specific rules, or override rule severities per project:
# .flaw.yml
version: 1
exclude:
- spec/
- lib/
- vendor/
rules:
FLAW002:
ignore:
- "examples/fake-keys.cr"
FLAW004:
severity: critical
Adopting flaw in an existing codebase with legacy technical debt does not require fixing fifty historical warnings on day one. Generate a baseline snapshot so CI only blocks on new findings:
# Record current findings into .flaw-baseline.json
flaw baseline --out .flaw-baseline.json
# Gate CI strictly on new medium+ findings not present in the baseline
flaw scan . --baseline .flaw-baseline.json --fail-on medium
# Emit JSON for automated agent consumption or SARIF 2.1.0 for code scanning
flaw scan src/ --format json
flaw scan . --format sarif > flaw.sarif
Packaging flaw for Fedora in crystal-flaw was a great stress-test for the Shard-as-RPM packaging macros in crystal-rpm-macros.
In Fedora, build environments like Koji and Mock run in strict network isolation. Calling shards install over the network during %build is forbidden, and bundling unvetted third-party dependencies violates Fedora policy. Under the Shard-as-RPM model, every Crystal library is packaged as its own RPM under %{_datadir}/crystal/shards/, and applications build 100% offline using declarative macros.
Look at how clean crystal-flaw.spec is using crystal-rpm-macros:
# crystal-flaw.spec
%bcond_without debug
%bcond_without check
%{!?crystal_arches: %global crystal_arches x86_64 aarch64}
%global shard_name flaw
Name: crystal-%{shard_name}
Version: 0.1.0
Release: 1%{?dist}
Summary: Static security analysis and flaw detection for Crystal
License: MIT
URL: https://github.com/kdairatchi/flaw
Source0: %{url}/archive/v%{version}/%{shard_name}-%{version}.tar.gz
ExclusiveArch: %{crystal_arches}
BuildRequires: crystal-rpm-macros
BuildRequires: crystal >= 1.21.0
BuildRequires: shards
BuildRequires: libyaml-devel
%description
Flaw is a fast static analysis tool for finding security flaws and vulnerabilities
in Crystal source code.
%prep
%crystal_setup -n %{shard_name}-%{version}
%build
mkdir -p bin
%crystal_build -o bin/%{shard_name} src/main.cr
%install
%crystal_install -b bin/%{shard_name}
%check
%if %{with check}
%crystal_check
%endif
%files
%license LICENSE
%doc README.md
%{_bindir}/%{shard_name}
%changelog
* Sun Sep 06 2026 RĆ©nich Bon ÄiriÄ <renich@evalinux.com> - 0.1.0-1
- Initial package for Fedora
Because Fedora already has the flaw wizard battle game in the official repositories, keeping the package name prefixed as crystal-flaw avoids a package namespace collision with Fedora's base repos.
Here is what those four macros do for you behind the scenes:
Having crystal, shards, ameba, crystal-flaw, cr2rpm, and core shards like kemal, db, pg, sqlite3, and mysql running natively from renich/crystal Copr is just the beginning. My goal is to take the Fedora Crystal SIG across the finish line and make Crystal a first-class, officially supported language in Fedora 43+ and EPEL.
If you write Crystal, maintain shards, or love Fedora packaging, I would love to have you on board as a founding contributor to the SIG. Here is how you can jump in right now:
Together, you and I can make Fedora the best Linux distribution on the planet for Crystal developers, no?! ;)
I’ve used Ansible for more than 10 years, and one problem I’ve seen everyone deal with is handling secrets in Ansible. Many people put them in the code, but since Ansible code often ends up in Git, that means adding secrets to Git repositories, which you should avoid at all costs.
Ansible Vault is a good solution, since it lets you encrypt files. I’ve used Ansible Vault for many years, but I think it has 2 major limitations.
t0xic0der )
on 2026-10-23 18:30:00 UTC
Hello travelers!
Loadouts for Genshin Impact v0.1.20 is OUT NOW with the addition of support for recently released characters like Vesna and Vodyanitsa and for recently released weapons like Beyond the Chrysalis, Breezeborne Refrain, Hymn of the Maelstrom, New Bough, Silver Light and Winter's Heavy Heart from Genshin Impact v7.1 Phase 2. Take this FREE and OPEN SOURCE application for a spin using the links below to manage the custom equipment of artifacts and weapons for the playable characters.
Besides its availability as a repository package on PyPI and as an archived binary on PyInstaller, Loadouts for Genshin Impact is now available as an installable package on Fedora Linux. Travelers using Fedora Linux 42 and above can install the package on their operating system by executing the following command.
$ sudo dnf install gi-loadouts --assumeyes --setopt=install_weak_deps=FalseInstallation command for Fedora Linux
Sapwood Blade by @gridhead in #677Moonpiercer by @gridhead in #678Forest Regalia by @gridhead in #679Vesna to the roster by @gridhead in #691Vodyanitsa to the roster by @gridhead in #692CharName StrEnum with __charmaps__ dict by @gridhead in #694Breezeborne Refrain to the GI Loadouts roster by @sdglitched in #700Winter's Heavy Heart to the GI Loadouts roster by @sdglitched in #701Silver Light to the GI Loadouts roster by @sdglitched in #702New Bough to the GI Loadouts roster by @sdglitched in #703Hymn of the Maelstrom to the GI Loadouts roster by @sdglitched in #704Beyond the Chrysalis to the GI Loadouts roster by @sdglitched in #705Cashflow Supervision by @sdglitched in #706Two characters have debuted in this version release.
Vesna is a sword-wielding Anemo character of five-star quality.
Vesna - Workspace and Results
Vodyanitsa is a catalyst-wielding Hydro character of five-star quality.
Vodyanitsa - Workspace and Results
Six weapons have debuted in this version release.
Dance of Wings Unbound - Scales on Crit DMG.
Viper's Ballad - Scales on Crit Rate.
Rondo of Slumber - Scales on HP%.
Wildgrowth - Scales on Crit DMG.
Radiance on the Water - Scales on ATK%.
Secrets of Frost - Scales on Crit DMG.
While allowing you to experiment with various builds and share them for later, Loadouts for Genshin Impact lets you take calculated risks by showing you the potential of your characters with certain artifacts and weapons equipped that you might not even own. Loadouts for Genshin Impact has been and always will be a free and open source software project, and we are committed to delivering a quality experience with every release we make.
With an extensive suite of over 1626 diverse functionality tests and impeccable 100% source code coverage, we proudly invite auditors and analysts from MiHoYo and other organizations to review our free and open source codebase. This thorough transparency underscores our unwavering commitment to maintaining the fairness and integrity of the game.
The users of this ecosystem application can have complete confidence that their accounts are safe from warnings, suspensions or terminations when using this project. The ecosystem application ensures complete compliance with the terms of services and the regulations regarding third-party software established by MiHoYo for Genshin Impact.
All rights to Genshin Impact assets used in this project are reserved by MiHoYo Ltd. and Cognosphere Pte., Ltd. Other properties belong to their respective owners.
remi )
on 2026-10-22 12:58:00 UTC
RPMs of PHP version 8.5.12 are available in the remi-modular repository for Fedora ā„ 43 and Enterprise Linux ā„ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.4.27 are available in the remi-modular repository for Fedora ā„ 43 and Enterprise Linux ā„ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.3.36 are available in the remi-modular repository for Fedora ā„ 43 and Enterprise Linux ā„ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.2.35 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 2 critical security bugs (CVE-2026-109618, CVE-2026-109619), 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 (thanks to Jitka Plesnik for the updates):
ā ļø To be noticed :
ā¹ļø Information:
Base packages (php)
Software Collections (php83 / php84 / php85)
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
RPMs of PHP version 8.4.27RC1 are available
ā¹ļø 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:
Software Collections (php84, php85)
Base packages (php)
remi )
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 :
ā¹ļø Information:
Base packages (php)
Software Collections (php83 / php84 / php85)
czanik )
on 2026-10-22 07:22:56 UTC
One of the core dependencies of syslog-ng is the ivykis library. We have a few FreeBSD specific fixes in our ivykis fork, however the syslog-ng port uses ivykis from ports instead of the bundled version. I am now working on making it selectable. Testing and help are welcome.
Read more at https://www.syslog-ng.com/community/b/blog/posts/building-syslog-ng-with-bundled-ivykis-on-freebsd
thisisyaash )
on 2026-10-21 06:22:02 UTC
I tried running a Fedora 42 bootc image on a Raspberry Pi 5. Itās a partial success, but I got far enough to learn a lot. The Pi 5 boots and I can log in, but the stock kernel canāt see the Ethernet chip, the Wi-Fi chip, or most other drivers. Only the USB ports work.
disk.raw image with bootc-image-builder from Raspberry Pi 5 itself. (I know QEMU exists, but I couldn’t get it working due to my lack of knowledge with QEMU) *shrugsdd.EFI/ folder.
Last Sunday I spent my day at the third Audio Expo in Budapest. Yet again it was fantastic. And yet again, my favorite audio experience was in the NCS Audio room, even if I listened to lot more expensive systems.
Made in Hungary audio rivals the rest of the world in quality, while often being available at a much more affordable price. My favorite of the show was the NCS Audio / Qualiton / Pixel cables room, all made in Hungary. 72 Audio was also perfect, as usual. Heed Audio Helikon with Zellaton speakers could fill the largest show room with lively sound. A pair of Popori Acoustics speakers sounded beautiful with a prototype Natural Distortion DAC and amp.
This year I visited the Audio Expo with someone who prefers headphones. In her experience speakers cannot give you the level of dynamics and detail that a good pair of headphones can provide. In the NCS Audio / Qualiton / Pixel cables room this suddenly changed.
We listened to almost all the systems on the seven floors of the exhibition building. This was the one where we returned for a second round of listening. No matter the type of music we listened to, it had extreme clarity, even in the bass section. We were looking for where the band is hiding, as it sounded like an actual band was there, not just a pair of speakers.
Best of all: this was one of the most affordable systems at the expo, beating many more expensive systems in listening experience.
Last year 72 Audio presented my favorite music experience at the Audio Expo. This year they presented a lot more affordable system. Still, it was one of the best sounding ones. Or, if you ask my partner, it was the best.
Their products are still just a prototype, but they definitely sound fantastic. A miniature DAC and amp were driving a pair of huge Popori Acoustics speakers and provided one of the most detailed sound experiences at the expo.
We listened to some church organ music. The pedals sounded a bit weak, but for the rest I felt as if I was sitting in the church and was listening to the performance live. It is very rare that organs sound natural to me from speakers.
While Natural Distortion sounded perfectly natural, systems with room correction sounded completely distorted. One of the demo songs was organ music, and the presenter of the demo explained how all the hard work of DSPs ensures the perfect sound. There was more than enough bass, still the whole thing sounded to me a kind of unbalanced and processed. While listening, I did not have the illusion of sitting in the church at all.
I was looking forward listening to some of most hyped new devices developed here in Hungary. The DAC and active speakers sounded OK, but as the door of the listening room was wide open and fixed in that position, there was no chance to hear the details. Much of the music was lost in the noise coming from outside.
When it comes to music, size does not matter. There were quite a few huge speakers at the event, but most of them were just loud, without providing an enjoyable listening experience. Even my good old speakers at home provide a lot more detail than some of the giants at the event.
Talking about oversize speakers. This year the VisegrƔd room, the largest show room of the building, had a Heed Helikon as amp, and a pair of Zellaton speakers. In earlier years I was always disappointed in this room. Loud and slightly distorted music on a pair of very expensive speakers: not something for an extended listening session. This year the room was full of perfectly sounding music, and I only left because I wanted to visit each and every room before closing time. As an added bonus, we had Lucina Yue on site, talking about her latest album: https://tidal.com/album/450279864
Another setup on my favorites list was put together by Limar Audio. They used a pair of miniature bookshelf speakers from Paradigm, but they could fill the room with beautiful music.
I prefer speakers, but as I was with someone preferring headphones, we also listened to some. We saw some odd-looking oversize headphones at a HydraSound stand in the hall. The HEDD headphones sounded fantastic, but obviously listening to an open back headphone in a busy environment is far from optimal. After a while we learned that the stand was actually about cables, the headphones were not for sale :-)
We also visited the MUZIX stand in the basement and listened to several Final Audio headphones. Navigating a Japanese tablet was a kind of a challenge. Luckily I use TIDAL enough to be able to search all different kinds of music for testing. Final Audio excelled with each of them.
Obviously, we did not have a chance to hear all systems with all the different types of music we listen to: everything from classical to metal, jazz, electronica, progrock and even some pop occasionally. So, all experience depended on not just the systems, but also on the music played at the time of visit. Still, I suspect that there would not have been major changes in my review if we had had a chance for more thorough listening.
See you again next year!
Across the Fedora ecosystem, the primary immediate focus is managing the final stages of the Fedora 45 release, which is currently in a "NO-GO" status targeting October 27, prompting groups like Release Engineering, Quality, Workstation, and Server to rapidly evaluate late-stage blocker bugs and freeze exceptions. Simultaneously, a massive structural shift is underway as the Bootable Image Unification effort concludes the Atomic Initiative, transferring ownership to the CoreOS Working Group and establishing a highly minimal atomic-seed image as the foundation for future immutable builds. In tandem with these initiatives, infrastructure modernization is a shared priority, with multiple teams actively migrating workloads from GitLab to the new Fedora Forgejo instance, adopting Konflux for continuous integration, and restructuring documentation under a unified root component. Finally, looking beyond the current final freeze, steering committees and Special Interest Groups are actively laying the groundwork for Fedora 46āincluding major system-wide proposals like the transition to RPM v6 and the removal of the legacy DNF4 stackāwhile advancing cross-architecture support for RISC-V and deploying vital language stack updates.
Fedora 45's final release is currently a NO-GO with the next target date set for October 27, though the community is still invited to celebrate at the virtual release party scheduled for October 30. In community news, the latest Fedora Podcast breaks down the differences between Fedora Hummingbird Linux and standard container images, asking users to share their specific real-world use cases.
To avoid disruptive surprises, contributors are explicitly reminded of the scope of provenpackager privileges, with warnings against modifying packages (such as converting to %autorelease) without maintainer consent. On the technical front, Fedora 45 will modernize the virtual console by replacing fbcon with kmscon. Looking ahead, a massive wave of Fedora 46 Change Proposals has been announced: major system-wide updates include transitioning to the RPM v6 package format, the complete removal of the legacy DNF4 stack and modularity, and introducing a daemon for unprivileged eBPF access. Additional F46 proposals cover an LMDB 1.0 transition, migrating the libvirt network filter to NFTables, updating to libchewing 0.14, and standardizing Emacs package packaging with new RPM macros and dependency generators.
The Council held a meeting regarding the Bootable Image Unification (Atomic Fusion) effort. Key discussions focused on Architectural Decision Records (ADRs) involving monorepos, debates over migrating legacy builds from GitLab to Forgejo, and organizing the atomic tracker backlog into structural tiers.
A major outcome of the meeting was defining the architecture for new bootable images, which will begin with an extremely minimal "seed" image meant for internal team use and as a foundation for layered products. Additionally, it was announced that the Atomic Initiative will officially shut down on October 31st, 2026, marking the successful transfer of ownership to the broader group.
atomic-seed repository was created on Forgejo (under the MIT license) to build a foundational seed image containing only a strict minimal package set: the kernel, systemd, SELinux policy, Podman, and bootc. (Source)Learn more about the Council team.
This week, FESCo held one meeting and handled an exceptionally high volume of system-wide and self-contained Change Proposals on the forums for Fedora 45, 46, and 47. Major topics of discussion included the retirement of DNF4 and Modularity, transitioning to the RPM v6 package format, moving the SELinux policy store to /etc/selinux, and updating various language stacks and tools.
In their meeting and ticket discussions, the committee addressed several administrative and policy items. They finalized a membership change, approved and published a policy reminder regarding the boundaries of provenpackager access, and processed the final status of incomplete changes for the upcoming Fedora 45 release. Additionally, they began determining how to safely phase out highly vulnerable NetworkManager VPN plugins without severely disrupting existing users.
%autorelease or %autochangelog) without prior maintainer consent (Ticket #3687, Meeting).NetworkManager-{vpnc,fortisslvpn} plugins by first publishing a Fedora Magazine article to warn users on how to migrate, before eventually pulling the packages from the base layer of atomic installs (Ticket #3693, Meeting).lkundrak, transferring heavily utilized packages (like NetworkManager and wpa_supplicant) to new volunteers and orphaning the remainder (Ticket #3681).duffy from FESCo and onboarding maxamillion to serve the remainder of the vacant seat's term (Ticket #3689, Ticket #3695).NetworkManager-{vpnc,fortisslvpn} plugins and guiding users on how to migrate. (Meeting)Learn more about the FESCo team.
The Packaging Committee held a meeting this week but didn't reach a quorum, meaning no official decisions could be finalized. The primary topic of discussion centered around procedural rules for ticket votes and quorum requirements, particularly in relation to the pending "snapshot ticket."
Members debated whether ticket votes should eventually pass by majority after a certain timeframe or if they must always be resolved during a live meeting when blocking negative votes exist. The snapshot ticket remains deferred due to the lack of quorum and an ongoing disagreement over the best way to indicate a snapshot within a string. The committee will attempt to resolve the issue at their next meeting in two weeks.
Learn more about the Packaging Committee team.
This week, the Mindshare group focused heavily on event planning, governance, and infrastructure adjustments. A major priority was organizing the upcoming Fedora Linux 45 Release Party, scheduled for October 30, 2026. The committee also reviewed several event sponsorship requests, including IndiaFOSS, LinuxDays Prague, and a high school game jam in Spokane, alongside discussions about revamping the large event funding process and acquiring new physical event boxes.
Additionally, the group tackled operational bottlenecks and community representation. With the Fedora Design team at capacity, Mindshare established new policies for event badges, requiring proposers to supply their own designs with a 30-day lead time. Governance discussions centered on reallocating the vacant CommOps representative seat on the Mindshare Committee to other active SIGs, and the team initiated tests using Buffer to decentralize and expand community access to Fedora's social media channels. High-level philosophical discussions also took place regarding the alignment of LLM-gen-AI models with Fedora's open-source foundations.
Learn more about the Mindshare team.
This week, the Fedora Magazine team welcomed a new prospective contributor who brings technical writing experience and an eagerness to explore and write about open-source software. In their welcome messages, existing community members shared onboarding documentation and emphasized that the Magazine is actively looking for more writers.
Learn more about the Magazine team.
This week, the Fedora Join group focused on improving onboarding processes and updating community navigational resources. A community member made significant progress analyzing the outdated apps.fedoraproject.org portal, successfully running the environment locally on Fedora 43. Key issues were identified for resolution, including broken icons, 404 errors on legacy SOP links, and stale application references that require updates in the infrastructure's Ansible repository.
Additionally, the team discussed ways to improve ticket visibility by updating the "Welcome to Fedora" issue templates. The goal is to automatically tag team members and owners to ensure reliable notifications for new onboarding tickets, though further testing is needed to confirm if tagging functions correctly within the templates.
@join/Members) function correctly when embedded inside issue templates.Learn more about the Fedora Join team.
The Ambassadors group has initiated planning for the Fedora Project's in-person presence at the FOSSASIA 2027 Summit. FOSSASIA is a major open-source technology conference in the Asia Pacific region, and the group is actively calling on contributors to help organize and represent Fedora at the upcoming event.
Learn more about the Ambassadors team.
The Workstation/GNOME group's activities this week centered around preparations for the upcoming Fedora 45 release, including identifying and addressing release blockers and freeze exceptions. Notable technical discussions focused on resolving a regression introduced in Fedora 44 where non-wheel users cannot install updates via GNOME Software due to a dnf5 limitation, as well as ongoing efforts to fully automate the generation of appstream-data metadata for software centers.
In community support, members clarified why certain KDE Frameworks (kf6-*) libraries are preinstalled on GNOME systems, tracing the requirement back to dependencies in background base packages. The Working Group also set their weekly agenda, touching on upcoming initiatives such as LLM-based summaries and Atomic Workstation discussions.
appstream-util for AppStream metadata validation (Ticket #507).Learn more about the Workstation / GNOME team.
The KDE SIG has made KDE Plasma 6.8.0 and KDE Apps 26.08.2 available via a combined COPR to accommodate the Fedora 45 final freeze. Users testing this prerelease are advised that a soname bump in libplasma requires the temporary removal of certain apps (such as Merkuro, KWeather, KClock, and KAlgebra), and developers are actively tracking upstream fixes for bugs expected to be resolved in Plasma 6.8.1 or 6.8.2.
In other discussions, community members clarified why KDE Frameworks (kf6-*) packages are preinstalled on GNOME-based Fedora 45 beta systems, tracing the requirement back to background packages rather than direct Qt application dependencies. There is also an ongoing discussion to reintroduce the bup package to Fedora to fully support the kup backup features newly integrated into Plasma 6.8.
bup in the Fedora repositories to enable versioned backups for the new Plasma 6.8 kup utility (Ticket #732).Learn more about the KDE team.
This week, the Server Working Group focused heavily on Fedora 45 (F45) release testing and advancing its Ansible support initiatives. During F45 testing, a known release-blocking issue resurfaced involving the KVM image and initial-setup due to a Kiwi configuration conflicting with partition type specifications. Additionally, the F45 aarch64 netinst image exceeded its 1.4G size limit, prompting a proposal to increase the limit to 1.5G.
On the development front, the group made progress on Ansible integration, successfully merging idempotency pull requests and claiming the fedoraserver namespace on Copr for future packaging. Members also expressed enthusiasm for the Cockpit team's upcoming GUI for Ansible, which aligns perfectly with the server automation goals. Finally, the group initiated early explorations into system resilience and snapshot-based backups utilizing LVM2, with plans to support BTRFS via snapper integration.
fedoraserver group alias on Copr to centralize the group's Ansible collection and utility RPM packaging efforts. (Source)Learn more about the Server team.
This week, the Infrastructure team operated under the Fedora 45 final infrastructure freeze, which culminated in a "no-go" decision during the F45 Final Go/No-Go Meeting. Major operational tasks included troubleshooting network reachability timeouts between Red Hat-hosted Fedora infrastructure and packages.redhat.com (which temporarily broke Copr builders), and replacing a failing Power9 hypervisor due to hardware controller issues.
On the development side, the Forgejo migration effort saw significant progress. The team tested and merged several backend features for private issues, updated the API, and began packaging Forgejo 15.0.10. Meanwhile, several staging environment adjustments were completed, including restoring API access for bots on discussion.stg and successfully transitioning docs.stg builds to pull directly from the new staging Forge repository.
vmhost-p09-copr03 Copr builder was permanently swapped with a spare machine rather than being reinstalled again, due to a degrading disk controller.mote script, which sorts meeting minutes into teams (Ticket #12873).ai-code-review tool to change the default output format or add configuration options, as discussed on the forum.Learn more about the Infrastructure team.
The Release Engineering team is currently navigating the Fedora 45 Final Freeze. A significant portion of the week was dedicated to evaluating blocker bugs, managing stable pushes, and generating Final Release Candidate (RC) composes. The most recent Fedora 45 Go/No-Go meeting resulted in a "No-Go" decision, so further RC composes and fixes are being integrated before the final release.
In addition to release preparation, the team managed several infrastructure and package updates. This included processing package unretirement requests, generating detached signatures for the ignition 2.28.0 release, and resolving build issues by adjusting Koji tags for packages like python-nanobind and rawhide-gcc-snapshot-build. Discussions are also ongoing on the forum regarding a potential transition to a new Rust-based repository generation tool.
python-nanobind-3.1.0-1.fc46 from Rawhide to prevent build failures for dependent packages, as detailed in issue 13556.rawhide-gcc-snapshot-build Koji tag to inherit from f46-build/rawhide-build to ensure packages correctly target Rawhide, as detailed in issue 13554.updates-testing for Fedora 45 and prepared the final fedora-release and fedora-repos updates, documented in issue 13550 and Bugzilla 2547462.createrepo_c that significantly reduces memory usage and execution time.Learn more about the Release Engineering team.
The Quality team focused on the impending Fedora 45 release, evaluating late-stage blockers and freeze exceptions. Due to the absence of a suitable Release Candidate, the team declared an automatic NO-GO for F45 Final, shifting the targeted release to October 27. Consequently, discussions opened regarding a proposal to bump the Server aarch64 netinst image size limit to 1.5G to handle the F45 image growth.
The team also conducted the Podman Conmon-v3 Test Day and finalized preparations for the upcoming GRUB EFI for Confidential Computing Test Day. A Cockpit Test Day planned for this cycle was pushed back to the next release. Additionally, after debates in the blocker review meeting, a new initiative was launched to formulate a clear strategy for handling CVE-related freeze exception requests on packages absent from release media.
updates-testing is disabled. A new ticket was created to establish a long-term strategy for these scenarios.Learn more about the Quality team.
The Websites and Apps team focused heavily on website maintenance and user experience improvements this week. A significant effort went into refining download pages: the team added macOS direct download links for the Fedora Media Writer to the workstation download page to bypass confusing GitHub repository links, successfully implementing API caching to avoid build rate limits. Additionally, they fixed a caching bug on the CoreOS download page that was displaying stale release data to end users, ensuring it now fetches live updates dynamically.
Other discussions revolved around infrastructure and translation tooling. The team removed the broken PeerTube video feed from the Fedora start page after persistent errors. On the community side, members discussed refining translation configurations to prevent translating names and terms of service in Weblate, clarified the expected behavior of Fedora Badges permission checks, and noted user reports regarding a confusing login loop and UI bug when accessing the Fedora Wiki.
start.fedoraproject.org until a suitable replacement is found, due to persistent "502 Bad Gateway" errors (Ticket #436)._) to automatically exclude them from Weblate localization.ai-code-review tool by submitting a pull request to make the LLM review output format less verbose and more configurable._) to correctly remove them from Weblate.Learn more about the Websites and Apps team.
The Design team is finalizing visual assets and promotional graphics for the F45 Virtual Release Party (design#86), having successfully tested a new SVG generation workflow utilizing Claude, which will be detailed in an upcoming blog post. Additionally, developers from the Anaconda project have submitted a pull request to add CSS branding for the new WebUI installer and are seeking co-maintainer access to the design/packages repository to efficiently manage ongoing updates.
Internally, the team is actively restructuring their workflow by setting up automated ticket due dates in a sandbox environment and implementing a new labeling system to separate feature improvements from operational tasks. They are also clearing out stale backlog tickets and expanding documentation, including a newly submitted guideline for JPEG XL and an updated documentation repository for the Design Suite.
feature/improvements label to categorize strategic suggestions, preventing the standard ticket queue from becoming an unverified idea repository. (Meeting Log)Learn more about the Design team.
This week, the Docs team focused heavily on documentation infrastructure architecture and preparing release notes for Fedora Linux 45. A major structural shift is underway to consolidate various documentation repositories under a single root component. This long-term change will significantly improve content discoverability by allowing documentation modules from different Special Interest Groups (SIGs) to be displayed together seamlessly, while allowing each team to maintain their own source repositories.
Concurrently, the team finalized important user-facing release notes, prominently featuring the transition to native LibreOffice spell-check dictionaries. On the maintenance front, preparations are in motion to modernize branch naming conventionsāspecifically transitioning from prod to maināand to establish more robust continuous integration testing for staging environments.
ROOT component; this will allow the inclusion of modules across different repositories while automatically dropping the component name from the generated URLs to prevent link breakage. (Issue #66)prod branch to main and moving the stg environment to a dedicated builder repository on the staging Forge to facilitate better pre-merge testing. (Issue #61)DOCS_REPO_BRANCH, ensuring OpenShift jobs do not break during the upcoming branch renaming transition. (Issue #64)libreoffice-dict-<lang> packages will need to use --allowerasing, which will explicitly remove legacy hunspell-<lang> and libreoffice-langpack-<lang> packages. (Issue #434)prod to main to ensure continuous compatibility with their workflows.Learn more about the Docs team.
This week, the COPR community reported a couple of service-related issues on the mailing list. Jean-Marc LIGER observed that several builds have been stuck in a "pending" state for multiple days, noting a curious pattern where affected accounts start with the letter 'L' and pointing out a stalled Pulp migration. Additionally, Ian Pilcher reported that builds were failing due to curl timeout errors when attempting to reach packages.redhat.com.
Learn more about the COPR team.
The EPEL team has been actively managing package updates and refining documentation this week. A major update to qt6 (from 6.6.2 to 6.10.3) in EPEL 9 is currently underway, which required rebuilds for several dependent packages like obs-studio, qcoro, and qt-creator. Additionally, version updates for uv (to 0.13.x) and ruff (to 0.17.x) are planned for the EPEL 10 leading branch and newer Fedora releases following the Fedora 45 Final Freeze.
On the procedural side, community members have proposed new documentation for build-tagging to clarify processes introduced with EPEL 10. Routine maintenance also saw updates to Noctalia, contributions to packaging guidelines, and investigations into the impact of retiring Bugzilla.
uv (0.13.x) and ruff (0.17.x) will not be shipped to Fedora 43 because the release is nearing End-of-Life and the updates contain minor breaking changes. The updates will still proceed for F44, F45, and the EPEL 10 leading branch.qt6 update in EPEL 9 (which includes packages like obs-studio, obs-studio-plugin-vkcapture, qcoro, and qt-creator) to ensure no breakages or missing dependencies went unnoticed.Learn more about the EPEL team.
During their October 13 meeting, the ELN SIG discussed preparations for building boot.iso with image-builder (tracked in this pull request) and assigned ownership to investigate a bug where KDE Discover is failing in ELN (issue #633). The team also noted that recent ELN Extras pull requests have been merged, leaving the Extras repository in better shape.
In broader Linux news, the group is making significant progress on introducing ELN to the RISC-V architecture. The team is preparing to begin bootstrapping soon and plans to target RVA23 as a baseline. To prevent any disruptive surprises for existing contributors, the group clarified that these new RISC-V builds will take place on the Fedora RISC-V alternate Koji, keeping them separate from the main Fedora Koji.
Learn more about the ELN team.
The Atomic group is undergoing a major transition as the Fedora bootc initiative officially concludes on October 31, 2026, at which point ownership will transfer to the CoreOS Working Group. During the October 15 unification meeting, the team laid the groundwork for merging Fedora CoreOS and Atomic efforts, including the proposal of a new foundational "seed image" architecture to serve as a baseline for user consumption and derivative products.
Significant infrastructure shifts are also underway as the group transitions away from GitLab. The team is actively migrating base image workloads to the new Fedora Forgejo and pushing to establish Konflux as the group's production-level CI/CD tool. Ongoing debates include whether to adopt a monorepo approach for atomic images to streamline future builds and how to best provide standardized "bootimages" for users exploring Image Mode.
atomic-seed repository was created on Forgejo under an MIT license to build the foundational seed image, starting with a minimal five-package set (kernel, systemd, Podman, selinux-policy, bootc) before deciding on further additions like bootloaders (Epic #144, Meeting Notes).Learn more about the Atomic team.
This week, the CoreOS team officially announced that the Atomic Initiative will conclude on October 31st (following the Fedora 45 release), having successfully transferred ownership to the group. The community also approved migrating the automated engineering newsletter tool into the official CoreOS GitHub organization. A major deprecation was announced for the Linux community: the legacy quay.io/coreos/fcct container registry is now deprecated and will no longer receive updates; users must migrate to quay.io/coreos/butane.
Technically, the team is actively investigating a corrupt kernel file issue on ext4 /boot partitions linked to large-folio writeback bugs during upgrades. Other key initiatives include proposing poll-based Jenkins imports for Konflux-driven streams, syncing firmware updates to other ESPs in RAID setups, and adopting chunkah to split container images for enhanced layer reuse.
quay.io/coreos/butane to receive future updates.Learn more about the CoreOS team.
This week, the Fedora IoT Working Group reviewed the status of Fedora 44, 45, and Rawhide builds, noting a persistent greenboot issue across stable and freeze branches. A Go/No-Go meeting for Fedora 45 was anticipated to serve as a blocker review due to the lack of a release candidate. In parallel, the Bootable Image Unification ("Atomic Fusion") group discussed creating a monorepo for atomic images and shaping the architecture for a new baseline "seed" image to support layered products.
On the tracker, several older tickets were closed, notably confirming that the Fedora ROS2 testing repository is now available in the official ROS2 documentation, concluding collaborative work with the Robotics SIG. New spike tickets were also opened to evaluate device-specific ARM images and VM-based hardware testing, prompting active discussion about the necessity and implementation of these approaches compared to existing generic images and OpenQA tests.
atomic-seed repository was created on Forgejo to build a highly minimal image (containing only the kernel, systemd, SELinux policy, Podman, and bootc) without a bootloader, testing it directly via QEMU for internal foundational use (Bootable Image Unification Meeting Agenda).Learn more about the IoT team.
The ARM group was notified of the Fedora 45 Blocker and Freeze Exception Review meeting, scheduled for October 12, 2026, at 16:00 UTC on Matrix. The agenda included reviewing 4 proposed blockers and 7 proposed freeze exceptions for the Final release to determine if they violate the Fedora Release Criteria.
Community members were encouraged to review the proposed blockers and cast their votes asynchronously before the meeting to help expedite the review process.
Learn more about the ARM team.
The Hummingbird group held two key meetings this week. The Bootable Image Unification meeting focused on defining a new architectural baseline via a minimal "seed" image and migrating base image repositories from GitLab to Forgejo. The group also announced the official sunsetting of the Atomic Initiative on October 31, 2026, as ownership successfully transfers to the community.
In broader Linux news, the Hummingbird Community Meeting highlighted that Fedora Hummingbird Linux is now powering Project Bluefin's new "Utah" alpha release and the upstream bootc-operator. Community discussions also explored practical applications of hardened images, bound images for specific workloads (such as PostgreSQL appliances), and new soft reboot capabilities for bootc-based artifacts.
atomic-seed repository was created on Forgejo under an MIT license, and the team will target bootc directly without utilizing an rpm-ostree tree in the process (Bootable Image Unification Meeting).atomic-seed repository (Bootable Image Unification Meeting).Learn more about the Hummingbird team.
This week, the AI/ML SIG reached a milestone by integrating ROCm 10.1 into Fedora Rawhide, closing gaps in older AMD GPU support and enabling better local AI testing. The infrastructure team successfully resolved network routing and SSL issues on the gpu01 hardware testing farm, ensuring CI pipelines for ROCm packaging remain functional. Additionally, contributors explored and packaged various local inference tools, including OpenClaw and Gufo, to optimize local model performance.
Strategically, the group participated in a cross-ecosystem leadership meeting to discuss AI model alignment with Fedora's open-source foundations. The consensus emphasized prioritizing model-agnostic tools and FOSS runtime engines over locking into specific models, while acknowledging the need for shared community inference infrastructure to ensure contributors with low-end hardware are not gated out of AI-augmented workflows. As a result of this strategy, proposals to exclusively deploy the fully-open but compute-heavy OLMo model were deferred until such shared infrastructure is realized.
wontfix for now, as the current AMD hardware is reserved strictly for Continuous Integration (CI) workloads.#alerts-ai-ml:fedoraproject.org Matrix room (Ticket #42).Learn more about the AI team.
The RISC-V group focused on finalizing Fedora 45 readiness, exploring kernel updates (including testing the 7.3 kernel), and advancing the Fedora ELN bootstrap for the RVA23 architecture. Contributors performed extensive debugging for various packages, successfully resolving LLVM 21.1.1 test suite failures, rebuilding Python packages for the 3.15 migration, and addressing nodejs, mysql, and cmake build issues.
Additionally, the team conducted build performance benchmarks comparing the SpacemiT K3 (RVA23) against older hardware like the P550, demonstrating significant speed improvements. Ongoing hardware stability investigations include debugging persistent glibc crashes on Milk-V Titan builders and testing transparent huge page (THP) disablement to fix GCC build failures on K3 boards.
mesa.spec to identify and enable missing hardware acceleration drivers.pthread_mutex_cond_lock) that are currently breaking builds on Milk-V Titan hardware.Learn more about the RISC-V team.
This week, NeuroFedora officially closed its long-standing initiative to rethink its Python packaging strategy, as the new test-suite is now fully implemented and running regularly (Ticket #580). Following this strategy, the team is actively identifying leaf Python packages to orphan, such as python-interface-meta and potentially python-poetry-dynamic-versioning, while keeping others like python-dunamai until they are no longer required by the dependency chain (Matrix chat).
Additionally, the SIG is investigating packages that are failing to install in the test-suite for Python 3.14 and 3.15 (Ticket #588). Many of these failures are due to missing wheels for Python 3.15, which has sparked discussions on whether the test-suite should be limited to testing wheels only. The group also confirmed that they have provided all necessary approvals to be included in automated weekly reports (Ticket #587).
python-interface-meta will be orphaned as it appears to be a leaf package, which may also allow python-poetry-dynamic-versioning to be orphaned (Matrix).python-dunamai will be retained by the SIG until it becomes a leaf package (Matrix).Learn more about the NeuroFedora team.
This week, the Gaming group discussed the upcoming 64-bit Steam client beta and its impact on multi-lib support. A community member inquired whether the new client would resolve previous concerns that had sparked discussions about potentially dropping support for Steam. It was clarified that while the 64-bit client itself will not require 32-bit librariesārunning instead inside the same runtime container used by the gamesā32-bit support (such as Mesa and glibc) will still be necessary for older 32-bit games to access graphics hardware.
Learn more about the Gaming team.
Between October 12 and October 18, 2026, the Perl group focused exclusively on routine package maintenance and version bumps. Contributors successfully updated several Perl packages to their latest versions across various branches, including perl-Net-CardDAVTalk, perl-ExtUtils-Typemaps-Default, and perl-CPAN-FindDependencies.
Additionally, there was minor ongoing coordination regarding disabling optional dependencies for perl-File-ShareDir on RHEL. Overall, the week saw smooth and rapid integrations of pull requests without any major disruptions or sweeping policy changes.
perl-Net-CardDAVTalk to version 0.13 (PR #5 and PR #6).perl-ExtUtils-Typemaps-Default to version 1.07 across multiple branches (PR #2, PR #3, PR #4, and PR #5).perl-CPAN-FindDependencies to version 4.01 to address rhbz#2547436 (PR #3).Learn more about the Perl team.
The Python group's activity this week centered around a call for new maintainership for a highly utilized package. Miro HronÄok announced that he is seeking a new primary maintainer for python-hypothesis. Due to the upstream practice of releasing on every commit, keeping up with updates has become unmanageable for a single primary contact.
However, because python-hypothesis is a critical dependency required by over 100 packages (including pytest) during build time, it will not be orphaned. The current maintainer will remain available to assist whoever steps up to take over the primary duties.
python-hypothesis will not be orphaned to avoid disrupting the builds of over 100 dependent packages in the broader ecosystem.python-hypothesis. The current maintainer will remain available to provide assistance and ensure a smooth transition.Learn more about the Python team.
Jarek Prokop announced the start of Ruby 4.1 development, beginning with a snapshot build based on upstream Git revision ad29ad7ad8. The initial Rawhide builds have completed successfully without any major surprises.
Continuous builds for Fedora are now available in a dedicated Copr repository, with the corresponding source code maintained in the 4.1 branch of Prokop's fork.
Learn more about the Ruby team.
This week, the Rust group focused heavily on resolving security advisories and cleaning up obsolete compatibility packages. Significant effort was directed toward addressing RUSTSEC advisories for crates like faster-hex (Issue 45), rustls (Issue 43), and ruzstd (Issue 42), which involved mass updates, creating side-tags, and coordinating rebuilds for dependent applications.
In addition, maintainers successfully concluded multiple package cleanups. Several old compat packages were officially retired, and progress was made on migrating applications away from unmaintained libraries like structopt, rustls-pemfile, and older versions of env_logger, itertools, and the gtk4-rs stack.
faster-hex update (rust-cargo-semver-checks, rust-onefetch, and rust-cargo-c) will be delayed until the Fedora 45 Final Freeze lifts and side-tag updates stabilize (Issue 45).rust-itertools0.11 compat package has been officially retired after backporting the final dependent package (Issue 11).rust-signal-hook0.1 compat package was retired following the porting or retirement of its dependencies (Issue 23).serial_test v0.5 compat packages were retired as their remaining dependencies were cleared (Issue 24).qmassa GPU monitoring tool for Fedora, starting from the Non-crate Rust project spec file template (Issue 44).rustls v0.23.46 in the available Bodhi side-tags (Issue 43).structopt users to clap/derive (Issue 22), rustls-pemfile to rustls-pki-types (Issue 5), and bincode to modern serialization alternatives (Issue 6).akonadi-search, newsboat, or dnsdist) that may be affected by the cxx RUSTSEC-2026-0202 vulnerability (Issue 36).Learn more about the Rust team.
unbreq Mock plugin on all Fedora packages. The report identified false positives related to hook ordering in %prep sections, which KonÄek plans to address in a future fix or through a new LD_PRELOAD implementation.-ffat-lto-objects with thin objects (%global _lto_cflags %slim) to reduce memory exhaustion and build times on Koji. However, some developers doubted this would solve linking memory issues on 32-bit architectures like i686./var to assist with rollbacks. Reviewers pointed out that upcoming versions of libselinux will support loading policies from /usr, which is preferred by developers.java-devel mailing list, Kenz S announced a New Fedora Forgejo repository for the Java Lounge matrix group. Maintainers are coordinating the addition of Java team members and planning to migrate documentation to Forge to improve integration with Fedora Docs.libteam mailing list, patches were successfully merged to factor out lacp_port_synced() and related functions in the teamd daemon.For community members looking to jump right in, software testing and quality assurance offer immediate and highly impactful ways to contribute without requiring specialized group membership. Volunteers are urgently needed across multiple groups to review and vote on Fedora 45 blocker bugs via the blockerbugs app or through specific mailing lists for Desktop, Server, and ARM. Opportunities abound for general QA, including participating in the GRUB EFI and Podman Conmon-v3 Test Days, testing the KDE Plasma 6.8.0 and Apps 26.08.2 COPR release, and providing feedback on the new Fedora 45 nightlies for IoT. You can also help by testing the newly updated design-suite-docs locally, evaluating kiritan & subatomic as a performant alternative to createrepo_c, or investigating a keyring invalid content type bug.
If your strengths lie in communications, writing, or media, several teams are actively recruiting creative talent. The Fedora Magazine is seeking new writers, and FESCo specifically needs someone to draft an article explaining the migration away from vulnerable NetworkManager plugins. Documentation writers are invited to refine a Git cheat sheet for non-developers or assist with EPEL build-tagging instructions. On the design and media front, Mindshare is looking for volunteers to draft social media content and edit YouTube videos for the upcoming release party, as well as recruiting a brand new volunteer team dedicated to Fedora Badges. Those interested in community building can help brainstorm themes for Flock to Fedora 2027 or apply to organize and represent the project at the FOSSASIA 2027 Summit.
Developers looking to submit code patches have numerous approachable entry points. A great introductory task exists in the Infrastructure team to add error checking to the mote script, while the CoreOS team is looking for help rewriting a Python PoC newsletter tool into Golang and adding unit tests to Ignition's Azure logic. Web developers can assist by fixing a Wiki login loop UI bug, reviewing CSS for the WebUI installer, or submitting a pull request to the upstream ai-code-review tool to configure the verbosity of Forgejo LLM outputs. Additionally, Rust programmers are encouraged to help port applications away from obsolete crates.
For experienced contributors, there is a strong demand for package maintainers and architectural strategy reviewers. A large roster of orphaned packages needs adoption, and specific roles are open, such as primary maintainer for python-hypothesis, packaging the bup backup utility for KDE, or reviewing the Gufo AI package. Contributors are also invited to engage in package review swaps. Finally, at a higher structural level, members from any technical background are highly encouraged to review and comment on ADR-0003, which proposes a unified monorepo strategy for atomic image configurations and CI/CD pipelines.
For decades, the Linux virtual console has relied on the kernel fbcon driver, to draw the framebuffer, to manage fonts, and to handle keyboard layout. Starting with Fedora 45, we’re switching to a userspace utility called kmscon. Depending on your usage of virtual console, this may impact your workflow.
If you’re not a developer or a system administrator, chances you probably never heard about fbcon or virtual terminal (VT), in this case you’re probably not impacted.
You can still read the rest if you’re curious about minimal text interfaces, and maybe you’ll start using it.
Most of the graphic sessions runs in tty1 or tty2. So press Ctrl+Alt+F3 to switch to tty3, and you will get a login prompt. This is the virtual console we’re talking about. To go back to your graphic session, press Ctrl+Alt+F1 (or F2 or F7 depending on your desktop environment).
The legacy fbcon driver runs directly in the kernel space, and has significant drawbacks:
kmscon is split into multiple subpackages, so you have a minimal installation without graphic/font dependencies for servers, and optional packages for more features.
The configuration file for kmscon is /etc/kmscon/kmscon.conf
you can copy the example with this command:
sudo cp /etc/kmscon/kmscon.conf.example /etc/kmscon/kmscon.conf
Here are the most common options to change:
verbose: enable more logs, if you have issues with kmscon. To get the logs, use
journalctl -u kmsconvt*
font-engine: defaults to freetype (if available) or unifont (fallback). You can also use pango, or psf (the format used by the kernel fonts)
font-name: The name of the font (for pango, freetype, and psf). As kmscon runs as root, the font must be installed in /usr/share/fonts, not in your home directory. You can find the exact name to use with fc-list. You can install Cascadia fonts, that are good for non-latin languages with
sudo dnf install cascadia-fonts-all
If you want fancy icons, Nerd fonts are good, but not available in the default Fedora repository. For psf font, font-name is the path to the font file.
font-size: The font height in pixels. By default kmscon tries to scale the font to have about 120×40 characters.
multi-monitor: multi-monitor configuration, the terminal is the same on all monitor. The default is scaled which will scale the font to avoid too much black border. Other options are clone, which will center the terminal on each monitor, and largest which will only use the largest monitor.
dpms-timeout: The timeout (in second) after which the monitor will be turned off. default to 600 (10 minutes). 0 means disabled.
no-mouse: This disable the mouse support. It can be useful to disable touchpad on some laptops.
palette: Change the default color palette for your terminal. You can define each color if none of the provided default palette suits you.
We hope you will enjoy using kmscon in Fedora 45. You may use it occasionally, or use it as your main session for some specific usage, like Veronica Explains for a writerdeck https://www.youtube.com/watch?v=E7vFdy4BEAY.
If you encounter any bugs, have feature ideas, or want to contribute to development, the upstream repository is at https://github.com/kmscon/kmscon.
fale )
on 2026-10-18 22:00:00 UTC
In the last couple of years, most companies have adopted some kind of AI. Most of them have done so by buying API access from a small number of frontier labs. This approach has the lowest barrier to entry and is often the preferred starting point, but it’s problematic because of the huge, unmanageable costs it creates, the shrinking, potentially useless gap in capabilities with open-weight models, and many sovereignty issues.
It’s October, and you know what that means…Its Hallow…. no… its the start of curling season!!!!!!!!!
Jef, what does this have to do with the scope of this blog? Well at the start of curling season, back in Alaska I’d always get together with my other sort of technology nerdy friend Jon and we’d nerdsnipe each other. We’d talk about cool little curling use case technology projects we’d like to try to build. I’m in the headspace right now thinking of small silly curling projects I could start ( I’m not promising to finish them) and in doing so learn more about the local language model as a technology.
Now the obvious thing to do isn’t even really LLM relevant, its vision machine learning. I’ve sort of already explored that topic when I was learning about machine vision so it’s not an interesting problem space for me right now. But if you want to know sort of the state of the art of DIY curling rock detection, check out the codetrick blog series. If I’m reading the blog correctly he’s making use of a variety of tools licensed under a mix AGPL BSD and Creative Commons. If you are interested in visual machine learning and not “chatbot” style LLMs, it's a really good read as a blog series.
I however am currently interested in learning LLMs, so I’m trying to figure out some curling related silliness that will let me explore the LLM inference technologies I can run locally. I’ve thought up some vibe coding projects that I can hopefully build a prompt for and compare the outputs of different models with. But I’m also interested to see if I can do any interesting boutique small language training with the small iron I have sitting under my desk. Can I describe curling games in a compact “language” similar to how chess games (hey they call curling chess on ice) and train a curling strategy bot and have it call strategy during a real game? I don’t expect it to be good. In fact I definitely want it to be not good…because it’ll be funnier. But I do want to understand the training process first hand and this fits my idiom.
What I don’t know how to do is create enough real world training material to sufficiently train such a thing. How many different curling games do I need to describe in a compact language of my own design? Can I simulate games using a simplistic Markov process and train with that? Can I train from real games? And how would I actually automate the transcript of games into my language? Which brings me back to the rock detection blog series I pointed out earlier. If I could point that vision system not at live games, but at the video recordings on youtube of all the livestream cameras from clubs that livestream their leagues and events and have it provide compact language descriptions of the evolution of the games… I might have a lot of low quality training data…to create my low quality strategy bot..and I can have a ton of fun with that during the wacky rules social spiel later in the season.
Anyways… like I said, it's that time of year when I think about stuff like this. First curling game of the season is Monday.
vedranm )
on 2026-10-18 00:00:00 UTC
Photo source: Lukas Seitz (@lukasseitz) | Unsplash
It has been three months since we published our preprint, and it has now passed 500 downloads. That seems like a good occasion to write about how I ended up working on molecular simulations and scientific software after leaving a promising assistant professorship.
I have tried to write about that decision several times, but the drafts kept growing and none reached publication. There was always more to explain. This time, I will focus on what led to the decision and what came of it.
Hello again to any readers out there. Its been a bit.
Last week I was out going to a concert ( rush, they were great! ) and next week I am going to be out again ( visiting friends in New Mexico ). So, today, lets go over a few things from the last two weeks and look ahead to next week.
A few weeks ago we managed to get in touch with some IBM folks who were willing and eager to help us out with our s390x setup. The problem is basically that we don't have enough resources to handle times when there's a lot of larger builds happening at once.
We quickly divided up things: Short term, they would help with any tuning that they could do to get things in a better place, then medium term they would look for additional resources for us and finally of course long term we would want to be in a place where we have all the resources we need.
The last few weeks focused on the short term performance improvements. I got them a ton of data (sysstat, sosreports) and explained how we had setup our lpar and how things worked.
Out of all that:
They tuned the "cpu entitlement distribution" on our lpar. My understanding is that this controlls how much of real cpus the virtual cpus in the lpar get by priority.
I allocated more cpus to each guest. I had been conservative on cpus as I was unsure what the effect of oversubscribing would be but 1.25x oversubscription should apparently be fine. This means that builders have 3 cpus where they had 2 before.
They added more memory. This allowed us to boot on new/latest/7.x kernels. With the memory we had before, the lpar would boot on newer kernels, but then OOM kill all the guests. This increased memory allowed everything to boot up normally on the 7.x kernels. It also allowed adding memory to all the guests.
I think this has had a real impact, but we will see over the coming weeks exactly how much. Medium and Longer term efforts are ongoing.
I decided to upgrade my home servers to Fedora 45 (as I often do it in the weeks before a release to catch any last minute things).
On one server this went completely smoothly. No problems at all. The 1G fiber link made short work of the downloads too, so it was quite fast and easy.
However, things did not go as well on my main server. It was cruising along and applying updates and... it got a MCE and killed the update in the middle. I'm not sure why it got the error. It's not had any before or since. I sure hope it's not becoming unstable.
Luckily I was able to get in, remove some duplicate packages, reinstall a few more, run some remove --duplicates and then distro-sync again. In the middle of that I messed up and remove both the old and new dnf versions and so I had to download packages and use rpm to install them back.
Finally everything in place and... for some reason it didn't activate the lv's in my secondary raid. I am still trying to see why it didn't do that, but in the mean time I activated them manually and everything was back up and on f45.
It amazes me how messed up something can be and you can still cleanly recover from it and go back to a good state.
As always, comment on the fediverse: https://fosstodon.org/@nirik/117457857359345126
Just a small one for myself (and anyone else looking to build the zellij terminal multiplexer on Fedora 44).
During the build of zellij, cargo will try to build openssl-sys. I always end up adding the required operating system packages one by one in a repeating trial and error to make the build work. So for the next time I (or someone else) runs into this:
sudo dnf install openssl-devel perl-Time-Piece perl-File-Copy \
perl-File-Compare perl-IPC-Cmd perl-FindBin
Then cargo build zellij should just work. Enjoy ;-)
admin )
on 2026-10-16 16:06:49 UTC
Fedora Linux 45 is almost here! Developers, packagers, and quality assurance engineers are hard at work putting the remaining polish on Fedora 45, which means it’s time for our Global Virtual Release Party! It is almost time to celebrate! If all goes according to plan, we will celebrate Fedora 45 just after its actual final release.
To mark the occasion, we are hosting the Fedora Linux 45 Virtual Release Party on Friday, October 30, 2026.
Regardless of the final calendar date of any Fedora Linux release, every release represents months of hard work, testing, and collaboration from our global community. Whether you are a long-time package maintainer, a dedicated documentation writer, a creative graphic artist, or a brand-new user, this release belongs to you.
Join us for a half-day of live sessions, recorded deep-dives, and community socialization. We’re busy filling the upcoming schedule with updates from the Fedora Project Leader and behind-the-scenes looks at new features.
The event is 100% free and open to everyone, but registration is required to access the virtual venue. We will continue using Element, our chat communication platform, as the virtual venue for the Global Virtual Release Parties. Thanks Element & Matrix.org for providing us the great tools to bring our global community together!
Register for the Fedora Linux 45 Release Party live event on Matrix! 
Donāt miss out on the chance to connect with the people who build Fedora. Grab your ticket, share the link with your friends, and get ready to celebrate Fedora Linux 45.
The trend is definitely going towards a smaller Engineering and a bigger AI section. I don’t like that. This week, have a look at John Cutler’s Feature Factory Retrospective and the No Man Is an Island post. If you want a podcast and like engineering, check out “Building resilient systems”.
TBM 445: The Feature Factory: A 10-Year Retrospective - “First, you ARE working in a feature factory. So you donāt need any signs.”