Element Matrix services will be upgrading our fedora.im and fedoraproject.org servers to use the new Matrix Authentication Server. This will allow clients to use the new element X and similar clients.
During the outage matrix servers will be unavailable, but messages will be received after the outage is …
admin )
on 2025-12-10 08:00:00 UTC
Generative AI systems are changing the way people interact with computers. MCP (model context protocol) is a way that enables generate AI systems to run commands and use tools to enable live, conversational interaction with systems. Using the new linux-mcp-server, let’s walk through how you can talk with your Fedora system for understanding your system and getting help troubleshooting it!
Large language models (LLMs) can be an invaluable tool when investigating an issue on a Linux system. However, this can involve a lot of copy/pasting of information from the Linux terminal into a web based interface to an LLM model.
The model context protocol (MCP) acts as a bridge, enabling LLMs to interact with external tools and data sources. The linux-mcp-server utilizes this protocol to give LLMs the ability to interact with a Fedora Linux system. Instead of you manually copying and pasting terminal output, the linux-mcp-server enables the LLM to directly query system information and log entries.
By enabling an LLM direct access to system information and logs, it is transformed into an active part of the investigation process when troubleshooting an issue. It empowers an LLM to directly query the system state, allowing it to help identify performance bottlenecks, and identify important log entries that might be missed by a manual review.
Anthropic introduced MCP in November 2024 as an open standard for LLM tool use. This provides a way for LLMs to interact with outside systems and data sources.
Prior to MCP, there wasn’t as strong a standard and ecosystem for LLM systems to call tools. LLMs were thus frequently limited to have only the information contained in their training. They were isolated from the outside world. For example, if you asked an LLM “what is the weather going to be next week”, the LLM would respond with a message indicating that it doesn’t know what the weather will be, as it doesn’t have access to that information. MCP helps solve this problem by enabling a standardized way for an LLM to access an outside data source, such as the weather forecast.
At a high level, users can use an AI agent application, such as Goose (open source), or Claude Desktop, and specify which MCP servers they would like to use. The AI agent application informs the LLM that there are tools available via these MCP servers that can be used to help answer the requests from the user. The LLM model can then decide when to invoke these tools.
MCP is an open standard. You have the flexibility to use MCP servers, such as linux-mcp-server, with either open source-licensed LLM models, or hosted proprietary LLM models.
The linux-mcp-server is a project started by Red Hat’s RHEL Engineering team. It provides a number of tools that enable an LLM to query information from a Linux system, such as system info, service information and logs, process information, journald and other logs, network information, and storage and disk information. For a full list of the tools provided, refer to the project’s Github page.
These tools, provided by linux-mcp-server, are focused on providing the LLM access to read-only information. In the future, we’ll be exploring expanding past these read-only use cases.
The linux-mcp-server can be used to interact with the local Fedora Linux system that it is running on. It can also be used to interact with remote Fedora Linux systems over SSH. For example, if you have SSH key authentication setup with the remote systems, you could make a request to your AI agent application such as “Determine the current memory usage on the fedora1.example.com, fedora2.example.com, and fedora3.example.com servers”.
The main components needed are an AI agent application, access to LLM model inference, and the linux-mcp-server.
There are a number of options for the AI agent application, both open source and proprietary. An example of an open source AI agent is Goose, which provides an RPM that can be installed on Fedora.
There are several LLM model inference options, ranging from locally hosted open source models, to proprietary hosted LLM models. If hosting a model locally, you generally need to have GPU/accelerator hardware available. Open source tools that can be used to locally host LLM models include RamaLama, llama.cpp, and Ollama. There are a number of open source LLM models capable of tool calling. These include models such as gpt-oss-20b and Granite 4 small.
Once you’ve installed your preferred AI agent application, the next step is to install the linux-mcp-server and configure your AI agent application to use it. The linux-mcp-server Github page includes installation instructions, and configuration details for Goose and Claude Desktop.
Has this happened to you? Time to hop on a call and give a demo. You’re pumped. It’s your go-time aaaaand… your system starts lagging. Folks on the call say your video is choppy or they can’t understand you. OH NO.
You’ve got to assess what’s up, quickly. Run `top`, check `dmesg`, check your network connection (read the man page for `netstat` because you can’t remember the flag you want), check `journalctl`, cross-reference what you’re seeing, then start killing processes, restarting services, reloading kernel modules willy-nilly based on hastily-crafted theories, see if it improves…
This is a case where you could actually ask the system to tell you why it’s slow and give it the ability to do the analysis via linux-mcp-tools. The LLM you connect with won’t just run the commands through the MCP server; it will understand what the numbers it gets means in context and be able to explain in human terms.
So let’s start working with a relatively new laptop. It’s a Thinkpad T14S with the AMD Ryzen
AI Pro 7 ( Ryzen AI 360 chip.) Recently one of the wifi networks it must connect to regularly was upgraded. It now has issues with the network connection stability. So let’s talk to Goose + gpt-oss:20b + linux-mcp-server about it. Here’s the initial prompt I used:
My Wifi doesn't work very well. It cuts out after a few minutes. Help me fix it. Can you find the error messages in the system logs and diagnose the problem?
It responded with the following:
I'll help you diagnose your WiFi connectivity issues by examining the system logs for error messages related to your network interfaces and wireless connectivity. Let me start by gathering information about your system and checking the relevant logs.
It then made a series of tool calls, including Get System Information, Get Network Interfaces, Get Journal Logs, Get Hardware Information, Get Service Status service_name:NetworkManager, Get Service Status service_name:wpa_supplicant, Read Log File. The result was this analysis, which is the actual problem I was hoping it could find!
Problem SummaryYour ATH12K PCI (Qualcomm 802.11ax) wireless card repeatedly reports
ath12k_pci 0000:c2:00.0: failed to enqueue rx buf: -28
every few minutes, which triggers a drop of the wireless link. The driver is trying to enqueue an RX buffer for the hardware but fails with errno ‑28.
‑28 →
(out‑of‑memory for the driver buffer); the kernel cannot allocate a DMA‑coherent RX descriptor.-ENOMEM
Likely Root Causes| Cause | Evidence / Typical Scenario | Fix / Work‑around |
|---|---|---|
| Driver bug or missing patch | The kernel’s ath12k driver has had a long‑running issue with RX ring management in older 5.15/5.4 series. | Update the kernel or apply the latest patch from the
linux ath12k |
| Out‑of‑memory in the driver | The error itself is “‑28” – a memory‑allocation failure inside the driver. | Reduce the number of RX descriptors, or enable fast‑RX disabled mode (
modprobe ath12k_pci ath12k_pci_disable_fast_rx=1 |
| Firmware mismatch / corruption | Old firmware (
ath12k_hwgen |
Reinstall firmware from your distro (
sudo apt‑install --reinstall linux‑firmware |
| System memory pressure | If many big processes run, DMA‑coherent memory pool can be exhausted. | Free RAM, close memory‑heavy apps, or add swap. |
| ACPI/PCIe power‑management quirk | Some laptops throttle the Wi‑Fi device after idle, resetting the buffer queue. | Add
pci_bus_reset = off ath12k_pci_disable_ps=1 |
| Hardware issue (e.g., faulty PCIe slot or NIC) | Persistent failure after multiple driver/kernel upgrades. | Test on another machine/PCIe slot or replace the card. |
Diagnostic Checklistuname -r
modinfo ath12k_pci | grep ^version:
cat /sys/module/ath12k_pci/parameters/*
– See if
ls /lib/firmware/ath12k/ath12k/ar9009/ | grep wlan0 | head
– If the files are missing or older than the driver, copy newer ones from
sudo dmesg --ctime | grep -A3 'ath12k_pci 0000:c2:00.0'
– Observe if there are any other “-ENOMEM” or “resource exhaustion” messages.
free -h
vmstat 1 5
sudo lspci -vvv -s c2:00.0 | grep -iE "link|latency"
Quick‑Fix Path (Try in this order)| Step | Command | What it does |
|---|---|---|
| 1 |
|
Refresh firmware to the latest distro version. |
| 2 |
|
Apply latest kernel with patched ath12k driver (or switch to 5.18+ if still on 5.15). |
| 3 |
|
Force the driver to use a more conservative RX scheme. |
| 4 | Reboot and monitor:
dmesg -T | grep ath12k_pci |
Verify the error disappears. |
| 5 | Optional: test on another machine or use a USB‑WiFi dongle (USB 802.11ax / 802.11ac) as a temporary workaround. | Ensure the issue is not hardware‑specific. |
**Tip:** After reboot, you can also verify driver parameters:
Advanced Debugging (if basic fixes don’t help)sudo bash -c 'echo 1 > /sys/module/ath12k_pci/parameters/debug'
sudo dmesg -T | grep ath12k
sudo lspci -vv -s c2:00.0
sudo ethtool -S wlp4s0
grep -i 'ath12k' /var/log/syslog
Bottom LineThe “failed to enqueue rx buf: –28” is an internal driver allocation failure that typically follows one of two paths:
If you're still stuck after following the quick‑fix path, it's worth capturing more detailed logs with the above diagnostic commands and sharing them. We can then cross‑reference the exact kernel version/driver commit to see if a known patch exists.
Feel free to let me know which step you’ve tried or if you encounter any new log messages, and we’ll dig deeper!
Not too bad an analysis and set of debugging steps! I’ll follow up in the comments and let you know if the solution works.
Trawling through `du` on the command line, converting the numbers in your head, sorting them – it can be tedious. We even have graphical tools like `baobab`, but it takes time to load in the results and explore the data. And sometimes you might have questions it can’t answer in terms of the risk of deleting a specific directory, or the age of a specific file. It’s easier to be sloppy and just let the disk fill up. But there comes a time where that is no longer an option.
You can ask the system using the linux-mcp-server to analyze your disk usage, give you a hitlist of the top space-eating places on the file system, and give you advice with a risk analysis of how to clean it up.
Here’s my prompt:
I need help analyzing disk usage on my system. Can you: 1. Show me the current disk usage across all filesystems using get_disk_usage 2. Use list_directories_by_size to show me the 10 largest directories (this will help identify where disk space is being consumed) 3. Check if there are any large log files consuming space using get_journal_logs or read_log_file 4. Review running processes with list_processes to see if any are consuming excessive resources or creating temporary files After gathering this information, help me identify potential space-saving opportunities and assess the safety of cleaning up specific directories. Please don't only examine top-level directories. I want you to go deep if needed to find out where the largest files are!
I ran this prompt on my Fedora 42 system using linux-mcp-server with Goose connected to locally-served gpt-oss:20b, and here’s the output I got:
Disk‑space overview (as of Nov 24 2025 15:21)
| Filesystem | Size | Used | Avail | Use % | Mounted on |
| /dev/mapper/luks‑61cedb0e… | 952.3 GB | 548.9 GB | 399.6 GB | 57.9 % | / |
| /dev/mapper/luks‑61cedb0e… | 952.3 GB | 548.9 GB | 399.6 GB | 57.9 % | /home |
| /dev/nvme0n1p2 | 973.4 MB | 462.8 MB | 443.4 MB | 51.1 % | /boot |
| /dev/nvme0n1p1 | 598.8 MB | 19.3 MB | 579.6 MB | 3.2 % | /boot/efi |
Overall usage is comfortably below 60 % of a 952 GB volume, so immediate capacity pressure isn’t a concern. The biggest contributors to disk space today are in the ~/. hierarchy.
| Path (relative to the mount point) | Size (≈) | Notes |
| ~/ – User home (2 mounts: /home + /) | 1 TB total | 57 % used; the bulk of the space is in ~/ |
| ~/duffy/.local/share | 238 GB | Containers sub-dir, followed by Trash (7GB) – typical podman/docker container images |
| ~/duffy/.local/share/containers | 238 GB | Container layers, images, root filesystems – the prime candidate for cleanup |
| ~/duffy/.local | 266 GB | share (237 GB) dominates it |
| ~/duffy/.local/share/containers (inside share) | 238 GB | Same as above – just a different view |
| ~/duffy/.local/lib | 13 GB | Likely a virtual‑environment library set |
| ~/duffy/.local/bin | 4 GB | Helper binaries |
| ~/duffy/.local/share/Trash | 7 GB | User‑deleted items still resident on disk |
| ~/duffy/.local/share/containers (nested) | 238 GB | Same as above; redundant listings from recursive depth‑1 scans |
| ~/duffy/.local/share (top‑level) | 238 GB | containers is the absolute largest item |
Take‑away – 75 % of the 238 GB live inside three nested directories:
| Category | Recommendation | Rationale |
| Containers | podman system prune -a (or docker system prune -a if Docker is in use) | Removes unreferenced images, containers, and caches. This can reclaim 200–250 GB if most containers are outdated or no longer referenced. |
| Trash | gio trash –empty | The 7 GB in Trash is still taking physical space; simply emptying it will free that amount. |
| Large libs/binaries | Check ~/duffy/.local/lib – 13 GB, and ~/duffy/.local/bin – 4 GB | If these are not actively used by a project, consider uninstalling or moving them to a secondary, less‑frequented store. |
| Ramalama & UV | 9 GB (ramalama), 8 GB (uv) | Possibly temporary files or caches from development tools. Inspecting the contents of these directories (du -h) can reveal if they are still needed. |
| Other caches | pnpm store prune, virtualenv or pip cache purge | Development tool caches often accumulate; they’re usually safe to delete once you’re done with the current development sessions. |
| Logs | The system journal shows normal activity, and syslog access is blocked by policy. | Systemd journal stores are rotated automatically; no urgent action required. |
| Boot partitions | Not relevant – they’re low‑usage (boot/efi only 3 % used). | No action needed. |
# 1. Empty Trash
gio trash --empty
# 2. Prune unused containers/images
podman system prune -a # or docker system prune -a
# 3. Remove leftover caches
pnpm store prune # if pnpm is installed
pip cache purge # for Python
virtualenv --clean # optional
# 4. Inspect large “RAM” directories manually if you need deeper cleanup
du -h --max-depth=1 ~/duffy/.local/share/containers
Tip: After each step run df -h /home or du -sh ~/duffy/.local/* to see the impact.
| Action | Why it’s safe (or risk) |
| Emptying Trash | Deletes only user‑deleted files; confirm you don’t need the content. |
| podman system prune -a | Deletes container images, containers, and volumes that are not referenced by any running or stopped container. Verify with podman ps -a before pruning. |
| Removing lib/bin from .local | Only safe if you’re sure those libraries/bin files aren’t part of a running application. |
| Caution with tmpfs or moving large directories | If you move a directory on‑the‑fly, ensure no running application depends on that path. |
Feel free to ask what next steps you’d like to dig into (e.g., detailed contents of the containers dir, specific application logs, or targeted pruning commands).
So you may have noticed a little detail above – the system is a Fedora 42 system… and Fedora 43’s been out a month now! 
So, time to upgrade.
This example shows where we have some tools missing from the set provided in the linux-mcp-server. We’re including it for two reasons:
Here’s the prompt I started with, with the same Goose + gpt-oss:20b + linux-mcp-server combination:
You are a Linux system administrator assistant analyzing a Fedora system for upgrade readiness. TASK: Examine this Fedora 42 system and provide a comprehensive upgrade readiness report for Fedora 43. ANALYSIS CHECKLIST: 1. Check current Fedora version: cat /etc/fedora-release 2. Review system updates status: dnf check-update 3. Identify third-party repositories: dnf repolist 4. List installed packages from non-Fedora repos: dnf list installed | grep -v @fedora 5. Check for broken dependencies: dnf check 6. Review disk space on root partition: df -h / 7. Check for unsupported or deprecated packages 8. Identify custom kernel modules: lsmod | grep -v "^Module" 9. Review SELinux status: sestatus 10. Check for pending system updates: dnf upgrade --refresh --assumeno REPORT FORMAT: # Fedora 43 Upgrade Readiness Report ## Current System Status - Fedora version: [version] - Kernel: [kernel version] - Updates status: [current/outdated] ## Potential Issues [List blocking issues with HIGH/MEDIUM/LOW severity] ## Third-Party Software [List non-Fedora packages that may need attention] ## Recommendations [Specific pre-upgrade steps needed] ## Overall Readiness: [READY/NEEDS ATTENTION/NOT READY] Run the necessary commands and provide this analysis. Be specific about any issues found and give actionable recommendations.
Now, right away the model came back to me to complain it doesn’t have access to `dnf`, `cat`, etc. And that’s expected here. What it did was give me a list of homework to run for it to complete the analysis… for example, `dnf check-update` and `cat /etc/fedora-release`. I had a little back and forth in Goose with the model where it would ask me to run a command and I’d copy the output into the context. This resulted, finally, in the following report:
Analyzed System – Fedora 42 (Kernel 6.17.7‑200.fc42.x86_64)
Date – 2025‑11‑24
| Item | Value |
| Fedora release | 42 (Adams) |
| Kernel | 6.17.7‑200.fc42.x86_64 |
| Root filesystem | 953 GB LUKS, 58 % used (411 GB free) – > 15 % free |
| /var /usr | Same as root partition (mounted the same LUKS device) |
| SELinux | enabled (policy targeted), currently permissive |
| System‑wide packages | No held packages (dnf versionlock list empty) |
| System modules | No modules held. |
TL;DR – The base system is clean; the kernel is up‑to‑date for 42, there is ample disk space, and there are no version‑locked packages.
| Repository | Description | Current dnf repolist status |
| rpm-fusion-free, rpm-fusion-nonfree, rpm-fusion-updates | Widely used RPM‑Fusion components | Enabled |
| google-cloud-cli | Google Cloud SDK (RPM built for EL 10) | Enabled |
| visual-studio-code | Microsoft VS Code RPMs | Enabled |
| command‑line‑assistant, google‑chrome, PyCharm, unsupported‑fedora‑packages, goose, leaktk | Various Copr builds (mostly Fedora‑42 based) | Enabled |
What we need to verify
| Issue | Severity | Why it matters | Immediate Remedy |
| Non‑Fedora packages (e.g., google‑cloud‑cli) | MEDIUM | May contain packages built for EL 10; could conflict with Fedora 43 libs. | Verify if a Fedora 43 build exists or plan to remove/re‑build it. |
| Third‑party repos without 43 builds | MEDIUM | dnf system-upgrade pulls all enabled repos; lacking 43 packages causes transaction failure. | Disable such repos temporarily (dnf config-manager –set-disabled <repo>) or enable the 43 stream when available. |
| Custom kernel modules | LOW | Modules compiled against 42 kernel won’t load on 43; services may drop. | Re‑compile or patch modules after upgrade. |
| Broken dependencies reported by dnf check | HIGH | Would block the upgrade transaction. | Run sudo dnf check now; fix any reported issues. |
| Insufficient disk space | HIGH | Upgrade scripts need > 15 % free. | Not an issue (58 % free). |
Current High‑Risk Items – None detected yet.
Next Action – Confirm each third‑party repo has 43‑compatible packages and set SELinux to enforcing.
| Step | Command | Purpose |
| Confirm 43‑stream packages | `dnf list –available * | grep <repo-id>` |
| Verify SELinux enforcement | sestatus | Should show enforcing. |
| Check for broken dependencies | sudo dnf check | No errors should appear. |
| Refresh all repos | sudo dnf upgrade –refresh | Pull latest metadata. |
| Dry‑run upgrade | sudo dnf system-upgrade download –releasever=43 –allowerasing | Detect any missing packages or conflicts. |
| Optional: Disable problematic repos | sudo dnf config-manager –set-disabled <repo> | Prevent upgrade crash if a repo has no 43 build. |
| Persist SELinux config | sudo sed -i ‘s/SELINUX=permissive/SELINUX=enforcing/’ /etc/selinux/config | Make enforcement permanent. |
| Criteria | Status | Comment |
| Disk space | Ready | 58 % free |
| Package health | Ready | No held or broken packages |
| Third‑party repos | Conditional | Verify 43‑compatibility |
| Custom modules | Pending | Need to identify modules and re‑compile |
| Final verdict | READY (after addressing above points) |
Next step – Run the three verification commands below and share the output with me:
sudo dnf check
sudo dnf repolist
dnf list installed | grep -v @fedora
With those outputs I can pinpoint any remaining blockers and give you a final, ready‑to‑proceed plan.
Happy upgrading!
You can see from these few examples that tool calling with LLMs is a valuable tool for troubleshooting Linux systems. We could use your help building this and making it awesome! How can you help?
Join us upstream at https://github.com/rhel-lightspeed/linux-mcp-server! And come chat with us in the Fedora AI/ML SIG chat room on Matrix!
admin )
on 2025-12-10 07:00:00 UTC
This outage impacts the Fedora Copr Frontend. Seems like these bots were attracted by our outage announce: Baudispider, YandexBot, ClaudoBot, AmazonBot, Presto, https://openai.com/bot TikTokSpider, which are currently DDoSing us and causing performance degradation.
admin )
on 2025-12-09 08:00:00 UTC
Apply now for the Flock to Fedora 2026 Call for Proposals (CfP) at cfp.fedoraproject.org. This year, the submission deadline for the Flock CfP is Monday, February 2nd, 2026.
Last month we announced that we’ll be convening again in Prague for Flock 2026 in June. Everyone interested in attending can head over to the Flock 2026 website and register today! For those of you who want to contribute to Flock by presenting your thoughts and ideas in front of your fellow contributors, we’ve got some inspiration for you in the form of updated proposal themes.
This year’s proposal themes are inspired by Fedora’s four foundations:
These themes are here to help get you thinking about topics you’d like to present. If you have something you want to talk about that doesn’t quite fit neatly into these themes, but you feel it belongs at Flock, go ahead and submit anyways! The reviewers are open to alternative topics. They are on the look out for topics that Fedora contributors are interested in discussing.
Financial travel assistance applications are now open as well. When you go to register to attend on the Flock 2026 website, you should also see links on how to apply for travel assistance if you need it. Financial assistance will be open until March 8th (several weeks after CfP closes on Febuary 8th). This is to give those with accepted talks an opportunity to figure out if they’ll need travel assistance.
admin )
on 2025-12-08 13:00:00 UTC
We will be powering off hardware in our rdu2 datacenter, it will be deracked and moved to our rdu3 datacenter, reracked, and reconfigured for the new network.
retrace/abrt/faf will be down and not accepting user reports smtp-auth-cc-rdu01 will be down and not accepting emails download-cc-rdu01 will be down …
admin )
on 2025-12-06 16:30:00 UTC
There is heavy scraper activity cauing high load and slow load times on https://src.fedoraproject.org.
We are investigating and trying to mitigate it.
The issue was scrapers hitting /history/ and /blame/ endpoints recursively. We have at least for now blocked those endpoints. Please git clone locally if you …
admin )
on 2025-12-05 15:43:00 UTC
TL;DNR: The Fedora Linux 43 Election schedule has been extended. Voting will now take place from 15 December 2025 through 7 January 2026.
Due to unforeseen delays in the interview coordination process, we are adjusting the election timeline. To ensure all candidates have ample opportunity to present their platforms and the community has sufficient time to vote, the election period will now extend through the year-end holidays.
Please mark your calendars with the following new critical dates:
New Election ScheduleTransparency is an important value of the Fedora Project, and I want to provide context on why this shift was necessary. I recently returned from two weeks of bereavement leave on Wednesday, 3 December. During my absence, the coordination work required to collect and process nominee interviews for the Fedora Engineering Steering Committee (FESCo) did not occur as originally planned.
Consequently, we missed the window to launch the elections today, Friday, 5 December. Rather than rushing the process, we are opting to extend the timeline. This ensures that our candidates are properly featured and that the election remains fair and accessible to all voters, despite the holiday season overlap.
The official Fedora schedule calendar is being updated to reflect these changes shortly. Thank you for your patience and understanding.
The post Important Update: Fedora Linux 43 Election Schedule Extended appeared first on Fedora Community Blog.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: December 1 – December 5 2025
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
Updates of the team responsible for Fedora Forge deployment and customization.
Ticket tracker
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 49 appeared first on Fedora Community Blog.
Planned Outage - pagure.io migration - 2025-12-03 21:00-23:00 UTC
We will be migrating pagure.io to a new network in our rdu3 datacenter. All services on pagure.io will be taken down, all data synced, and then services will be restored on the new server/datacenter. IP addresses for …
admin )
on 2025-12-02 12:00:00 UTC
The FreeIPA WebUI became new interface for freeipa
The post Test Day:2025-12-02 FreeIPA-WebUI Test Day appeared first on Fedora Community Blog.
We're updating Copr servers to F43
This outage impacts the copr-frontend and the copr-backend.
It’s finally here. We have an end date for OpenID in Fedora. The date is 1st May 2026. You can see it on the banner on https://id.fedoraproject.org/openid and it will be shown to you every time when trying to authenticate with OpenID. The date 1st May 2026 should give anybody still using OpenID authentication enough time to migrate to OpenID Connect.
We started our move to OpenID Connect and away from old OpenID authentication 4 years ago. This was a long road with plenty of obstacles on the way. We first ported all apps we own in Fedora Infrastructure to OpenID Connect. That took time, but we had at least control over these applications.
After porting all our applications we started to look at the application using OpenID authentication outside of Fedora ecosystem. This proved to be really difficult as those clients don’t need to register with Fedora Authentication System.
After some failures to contact the projects that we at least identified to use OpenID in Fedora, we decided that the best course of option is to separate the OpenID authentication system (the service that is providing it is called Ipsilon, which we want to decommission as well). I spent the last two months working on separating the OpenID authentication from OpenID Connect and SAML2. You can see the result on https://id.fedoraproject.org/openid.
This will now allow us to replace Ipsilon for both OpenID Connect and SAML2 and as most of the separation logic is in proxies, we should have no issue to reuse that for the new solution. This should resolve plenty of issues we are experiencing with current authentication system and let us remove one service from the portfolio of services we own in Fedora Infrastructure. We are looking forward to brighter future!
The post End of OpenID in Fedora appeared first on Fedora Community Blog.
admin )
on 2025-11-21 15:38:20 UTC
You attended the F43 Virtual Release Party!
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 17 November – 21 November 2025
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
Updates of the team responsible for Fedora Forge deployment and customization.
Ticket tracker
Minor update of FMN from 3.3.0 to 3.4.0
Minor update of FASJSON from 1.6.0 to 1.7.0
Minor update of Noggin from 1.10.0 to 1.11.0
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 47 appeared first on Fedora Community Blog.
We will be updating and rebooting various servers. Services will be up or down during the outage window.
admin )
on 2025-11-20 12:00:00 UTC
Hi,
I’m Jef, the Fedora Project Leader.
As FPL I believe Fedora needs to be part of a healthy flatpak ecosystem. I’d like to share my journey in working towards that over the last few months with you all, and include some of the insights that I’ve gained. I hope by sharing this with you it will encourage those who share my belief to join with me in the journey to take us to a better future for Fedora and the entire ecosystem.
First, my immediate goal is to get the Fedora ChangeProposal that was submitted to make Flathub the default remote for some of the Atomic desktops accepted on reproposal. I believe implementing the idea expressed in that ChangeProposal is the best available option for the Atomic desktops that help us down the path I want to see us walking together.
There seems to be wide appeal from both the maintainers of specific Fedora outputs, and the subset of Fedora users of those desktop outputs, that using Flathub is the best tradeoff available for the defaults. I am explicitly not in favor of shuttering the Fedora flatpaks, but I do see value in changing the default remote, where it is reasonable and desirable to do so. I continue to be sensitive to the idea that Fedora Flatpaks can exist because it is delivering value to a subset of users, even when it’s not the default remote but still targeting an overlapping set of applications serving different use cases. I don’t view this as a zero-sum situation; the important discussion right now is about what the defaults should be for specific Fedora outputs.
There is a history of change proposals being tabled and then coming back in the next cycle after some of the technical concerns were addressed. There is nothing precedent-setting in how the Fedora Engineering Steering Committee handled this situation. Part of getting to the immediate goal, from my point of view, was doing the due diligence on some of the concerns raised in the FESCo discussion leading to the decision to table the proposal in the last release. So in an effort to get things in shape for a successful outcome for the reproposal, I took it on myself to do some of the work to understand the technical concerns around the corresponding source requirements of the GPL and LGPL licenses.
I felt like we were making some good progress in the Fedora discussion forums back in July. In particular, Timothee was a great help and wrote up an entirely new document on how to get corresponding sources for applications built in flathub’s infrastructure. That discussion and the resulting documentation output showed great progress in bringing the signal to noise ratio up and addressing the concerns raised in the FESCo discussion. In fact, this was a critical part of the talk I gave at GUADEC. People came up to me after that talk and said they weren’t aware of that extension that Timothee documented. We were making some really great progress out in the open and setting a stage for a successful reproposal in the next Fedora cycle.
Okay, that’s all context intended to help you, dear reader, understand where my head is at. Hopefully we can all agree my efforts were aligned with the goal leading up to late July. The next part gets a bit harder to talk about, and involves a discussion of communication fumbles, which is not a fun topic.
Unfortunately, at GUADEC I found a different problem, one I wasn’t expecting to find. Luckily, I was able to communicate face to face with people involved and they confirmed my findings, committed on the spot to get it fixed, and we had a discussion on how to proceed. This started an embargo period where I couldn’t participate in the public narrative work in the community I lead. That embargo ended up being nearly 3 months. I don’t think any of us who spoke in person that day at GUADEC had any expectation that the embargo would last so long.
Through all of this, I was in communication with Rob McQueen, VP of the Gnome Foundation, and one of the Flathub founders, checking in periodically on when it was reasonable for me to start talking publicly again. It seems that the people involved in resolving the issues took it so seriously that they not only addressed the deficiencies I found -missing files- but committed to creating significant tooling changes to help prevent it from happening again. Some characterized that work as “busting their asses.” That’s great, especially considering much of that work is probably volunteer effort. Taking the initiative to solve not just the immediate problem, but building tooling to help prevent it is a fantastic commitment, and in line with what I would expect from the volunteers in the Fedora community itself. We’re more aligned than we realize I think.
What I’ve learned from this is there’s a balance with regard to embargos that must be struck. Thinking about it, we might have been better served if we had agreed to scope the embargo at the outset and then adjusted later with a discussion on extending the time further, that also gave me visibility into why it was taking additional time. It’s one of the ideas I’d like to talk to people about to help ensure this is handled better in the future. There are opportunities to do the sensitive communications a bit better in the future, and I hope in the weeks ahead to talk with people about some ideas on that.
Now with the embargo lifted, I’ve resumed working towards a successful change reproposal. I’ve restarted my investigation of corresponding source availability for the runtimes. We lost 3 months to the embargo, but I think there is still work to be done. Already, in the past couple of weeks, I’ve had one face to face discussion with a FESCo member, specifically about putting a reproposal together, and got useful feedback on the approach to that.
So that’s where we are at now. What’s next?
I am still working on understanding how source availability works for the Flathub runtimes. I think there is a documentation gap here, like there was for the flatpak-builder sources extension. My ask to the Fedora community, particularly those motivated to find paths forward for Flathub as the default choice for bootc based Fedora desktops, is to join me in clarifying how source availability for the critical FLOSS runtimes works so we can help Flathub by contributing documentation that all Flathub users can find and make use of.
Like I said in my GUADEC talk, having a coherent (but not perfect) understanding of how Fedora users can get the flatpak corresponding sources and make local patched builds is important to me to figure out as we walk towards a future where Flathub is the default remote for Fedora. We have to get to a future where application developers can look at the entire linux ecosystem as one target. I think this is part of what takes the Linux desktop to the next level. But we need to do it in a way that ensures that end users have access to all the necessary source code to stay in control of their FLOSS software consumption. Ensuring users have the ability to patch and build software for themselves is vital, even if it’s never something the vast majority of users will need to do. Hopefully, we’re just a couple more documents away from telling that story adequately for Flathub flatpaks.
I’ve found that some of the most contentious discussions can be with people with whom you actually have a significant amount of agreement. Back in graduate school, when my officemate and I would talk about anything we both felt well-informed about and were in high agreement on: politics, comic books, science, whatever it was.. we’d get into some of the craziest, heated arguments about our small differences of opinion, which were minor in comparison to how much we agreed on. And it was never about needing to be right at the expense of the other person. It was never about him proving me wrong or me proving him wrong. It was because we really deeply wanted to be even more closely aligned. After all, we valued each other’s opinions. It’s weird to think about how much energy we spent doing that. And I get some of the same feeling that this is what’s going on now around flatpaks. Sometimes we just need to take a second and value the alignment we do have. I think there’s a lot to value right now in the Fedora and Flathub relationship, and I’m committed to find ways both communities can add value to each other as we walk into the future.
The post A statement concerning the Fedora and Flathub relationship from the FPL appeared first on Fedora Community Blog.
You dropped by the Fedora booth at FOSDEM '26
admin )
on 2025-11-14 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 10th – 14th November 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 46 2025 appeared first on Fedora Community Blog.
admin )
on 2025-11-14 08:00:00 UTC
We did it again, Fedora at Kirinyaga university in Kenya. This time, we didn’t just introduce what open source is – we showed students how to participate and actually contribute in real time.
Many students had heard of open source before, but were not sure how to get started or where they could fit. We did it hands-on and began with a simple explanation of what open source is: people around the world working together to create tools, share knowledge, and support each other. Fedora is one of these communities. It is open, friendly, and built by different people with different skills.
We talked about the many ways someone can contribute, even without deep technical experience. Documentation, writing guides, design work, translation, testing software, and helping new contributors are all important roles in Fedora. Students learned that open source is not only for “experts.” It is also for learners. It is a place to grow.
After the introduction, we moved into a hands-on workshop. We opened Fedora Docs and explored how documentation is structured. Students learned how to find issues, read contribution instructions, and make changes step-by-step. We walked together through:
By the end of the workshop, students had created actual contributions that went to the Fedora project. This moment was important. It showed them that contributing is not something you wait to do “someday.” You can do it today.
“This weekend’s Open Source Event with Fedora, hosted by the Computer Society Of Kirinyaga, was truly inspiring! 
Through the guidance of Cornelius Emase, I was able to make my first pull request to the Fedora Project Docs – my first ever contribution to the open-source world. 
”
– Student at Kirinyaga University
Huge appreciation to:
And to everyone who played a part – even if your name isn’t listed here, I see you. You made this possible.
The students showed interest, curiosity, and energy. Many asked how they can continue contributing and how to connect with the wider Fedora community. I guided them to Fedora Docs, Matrix community chat rooms, and how they can be part of the Fedora local meetups here in Kenya.
We are introducing open source step-by-step in Kenya. There is a new generation of students who want to be part of global technology work. They want to learn, collaborate, and build. Our role is to open the door and walk together(I have a discourse post on this, you’re welcome to add your views).
This event is part of a growing movement to strengthen Fedora’s presence in Kenya. More events will follow so that learning and contributing can continue.
We believe that open source becomes strong when more people are included. Fedora is a place where students in Kenya can learn, grow, share, and contribute to something global.
We already had a Discourse thread running for this event – from the first announcement, planning, and budget proposal, all the way to the final workshop. Everything happened in the open. Students who attended have already shared reflections there, and anyone who wants to keep contributing or stay connected can join the conversation.
You can check the events photos submitted here on Google photos(sorry that’s not FOSS:))
Cornelius Emase,
Your Friend in Open Source(Open Source Freedom Fighter)
admin )
on 2025-11-12 13:18:27 UTC
Today, the Fedora Project begins the nomination period during which we accept nominations to the “steering bodies” of the following teams:
This period is open until Wednesday, 2025-11-26 at 23:59:59 UTC.
Candidates may self-nominate. If you nominate someone else, check with them first to ensure that they are willing to be nominated before submitting their name.
Nominees do not yet need to complete an interview. However, interviews are mandatory for all nominees. Nominees not having their interview ready by end of the Interview period (2025-12-03) will be disqualified and removed from the election. Nominees will submit questionnaire answers via a private Pagure issue after the nomination period closes on Wednesday, 2025-11-26. The F43 Election Wrangler (Justin Wheeler) will publish the interviews to the Community Blog before the start of the voting period on Friday, 2025-12-05.
The elected seats on FESCo are for a two-release term (approximately twelve months). For more information about FESCo, please visit the FESCo docs.
The full schedule of the elections is available on the Elections schedule. For more information about the elections, process see the Elections docs.
The post F43 election nominations now open appeared first on Fedora Community Blog.
admin )
on 2025-11-10 12:00:00 UTC
We have ongoing intermittent issues with the communication between the Fedora proxies and the backend services. This manifests as intermittent 502 / 503 errors when talking to services such as Koji, Src, and so on.
We are working with the networking team to track it down, see the Pagure ticket for …
admin )
on 2025-11-07 17:00:00 UTC
Many services at our main datacenter are down/unresponsive. There seems to be a networking event going on. We are working with networking to track down and mitigate things. Updates as they become available.
All services have been restored.
admin )
on 2025-11-07 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you with both an infographic and a text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in-depth details, look below the infographic.
Week: 03rd – 07th November 2025
The purpose of this team is to take care of day-to-day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces, etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 45, 2025 appeared first on Fedora Community Blog.
admin )
on 2025-11-07 08:00:00 UTC
The Fedora community is coming together once again to celebrate the release of Fedora Linux 43, and you’re invited! Join us on Friday, November 21, 2025, from 13:00 to 16:00 UTC on Matrix for our virtual Fedora 43 Release Party.
This is our chance to celebrate the latest release, hear from contributors across the project, and see what’s new in Fedora Workstation, KDE, Atomic Desktops, and more. Whether you’re a long-time Fedora user or new to the community, it’s the perfect way to connect with the broader community, learn more about Fedora, and hang out in Matrix chat with your Fedora friends.
We have a lineup of talks and updates from across the Fedora ecosystem, including updates directly from teams who have been working on changes in this release. We’ll kick things off with Fedora Project Leader Jef Spaleta and Fedora Community Architect Justin Wheeler, followed by sessions with community members like Timothée Ravier on Atomic Desktops, Peter Boy and Petr Bokoč on the new Fedora Docs initiative, and Neal Gompa and Michel Lind discussing the Wayland-only GNOME experience. You’ll also hear from teams across Fedora sharing insights, demos, and what’s next for the project.
Registration is free but required to join the Matrix event room. Once registered, you’ll receive an invitation in your Matrix account before the event begins.
Sign up on the Fedora Linux 43 Release Party event page. We can’t wait to see you there to come celebrate Fedora 43 with us!
admin )
on 2025-11-04 08:00:00 UTC
The official dates and location are set for Flock to Fedora 2026, the premier annual conference for Fedora Project contributors. The event will take place from 14-16 June 2026, in Prague, Czechia.
For Flock 2026, we are returning to the Vienna House by Wyndham Andel’s Prague, located at:
Stroupeznickeho 21
Prague, 150 00
Czech Republic
While all three days will be full conference days, the arrangement of the schedule will change slightly in 2026. Sunday, 14 June, will be designated as Day 0, featuring workshops, team meetups, and hands-on contributor sessions. The main conference activities, including streamed content, the opening keynote, and other sessions, are scheduled for Monday, 15 June, and Tuesday, 16 June.
Following community feedback from last year, Flock 2026 has been scheduled to align more closely with DevConf.CZ. The conference will conclude just before DevConf.CZ begins in Brno (18-20 June 2026). This compressed travel schedule is intended to make it easier for community members who wish to attend both events.
The Call for Proposals (CFP) for Flock 2026 will open in early December 2025 and close shortly after FOSDEM 2026 (31 January – 1 February). Speaker confirmations are scheduled to be sent in March 2026.
For Flock 2026, we are taking a more focused approach to session content. The Fedora Council, FESCo, and the Mindshare Committee are shaping key themes for the CFP. All presentation and workshop submissions should align with one of these themes. More details will be shared when the CFP opens.
Here is what you need to know to plan your attendance:
The official Flock to Fedora 2026 Matrix room, #flock:fedoraproject.org, is the best place to connect with organizers and other community members. We encourage you to join the channel for the latest updates and to ask any questions you may have.
We recognize that returning to the same city and venue for a second consecutive year is a departure from Flock’s tradition. This decision was made intentionally with two key goals in mind.
First, by working with a familiar venue, our organizing team can optimize its processes and plan further in advance. This stability for Flock to Fedora 2026 will give us more opportunity to improve our internal processes and explore new ways to incorporate community input into the design of Fedora’s flagship contributor conference.
Second, this allows us to plan for a significant change in 2027. The Flock organizing team is committed to exploring new locations for Flock 2027, with a particular focus on regions outside of North America and Europe. We acknowledge the travel difficulties many of our contributors in regions like LATAM and APAC face. We learned valuable lessons from past planning cycles and are eager to achieve this goal, while also recognizing that unforeseen circumstances can impact our plans. We will work with community members in these regions to explore possible options and conduct thorough research on pricing and availability for 2027.
We look forward to seeing you in Prague for Flock 2026, 14-16 June.
— The Flock to Fedora Planning Team
admin )
on 2025-10-31 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 27 October – 31 October 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 44 appeared first on Fedora Community Blog.
You helped solidify the core for the Fedora 43 rebase!
admin )
on 2025-10-28 13:56:28 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 43 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 43, 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 43. 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 43 using the terminal is easy. First, check if the 43 branch is available:
$ ostree remote refs fedora
You should see the following in the output:
fedora:fedora/43/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 43 branch.
$ rpm-ostree rebase fedora:fedora/43/x86_64/silverblue
Finally, the last thing to do is restart your computer and boot to Fedora Linux 43.
If anything bad happens (for instance, if you can’t boot to Fedora Linux 43 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 43 and your system will start in that previous version rather than Fedora Linux 43. 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 43 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 rebase of Fedora? For example from Fedora 40 Silverblue to Fedora 43 Silverblue?
Answer: Although it could sometimes be possible to skip versions during rebase, it is not recommended. You should always update to one version above (40->41->42->43 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/43/x86_64/kinoite
I’m excited to announce my very first Fedora Linux release as the new Fedora Project Leader. Fedora Linux 43 is here! 43 releases! Wow that’s a lot. I was thinking about proposing special tetracontakaitrigon stickers to celebrate this release, but I’m not sure anyone would notice they weren’t circles.
Thank you and congrats to everyone who has contributed to Fedora to this release, and in all the releases leading up to this one. I’m grateful to be back with a chance to take stewardship of the collaboration as the Fedora Project leader. I’ve been getting my feet under me as much as I can in these first few months. I’m looking forward to writing up some longer missives about where I want to steer this ship, but for right now I just want to highlight some of the changes you should expect to encounter in the latest release of Fedora Linux. Read the highlights below to find out more. Or if you are ready just jump right in!
If you have an existing system, Upgrading Fedora Linux to a New Release is easy. In most cases, it’s not very different from just rebooting for regular updates, except you’ll have a little more time to grab a coffee.
If this is your first time running Fedora Linux, or if you just want to start fresh with Fedora, download the install media for our flagship Editions (Workstation, KDE Plasma Desktop, Cloud, Server, CoreOS, IoT), for one of our Atomic Desktops (Silverblue, Kinoite, Cosmic, Budgie, Sway), or for alternate desktop options (like Cinnamon, Xfce, Sway, or others).
As usual, with Fedora, there are just too many individual changes and improvements to go over in detail. You’ll want to take a look at the release notes for that.
There are, however, a few notable user visible changes in this release. For those of you installing fresh Fedora Linux 43 Spins, you may be greeted with the new Anaconda WebUI. This was the default installer interface for Fedora Workstation 42, and now it’s the default installer UI for the Spins as well.
If you are a GNOME desktop user, you’ll also notice that the GNOME is now Wayland-only in Fedora Linux 43. GNOME upstream has deprecated X11 support, and has disabled it as a compile time default in GNOME 49. Upstream GNOME plans to fully remove X11 support in GNOME 50.
Beyond the user-visible changes, there are a couple of significant bits of plumbing that should go unnoticed for most users but are a big deal, nonetheless.
Fedora Linux 43 will be the first release with RPM 6.0. Like I said, this should go unnoticed to end-users, but it is a significant change. RPM 6.0 provides some interesting security enhancements, like multiple key signing of packages. This should help future-proof package signing as we transition to post-quantum-crypto OpenPGP keys in future releases.
We’re also moving forward with our bootc enablement story. Fedora CoreOS is now buildable from a Fedora base bootc image using a Containerfile, instead of needing to be composed with a custom tool. That means anyone with podman can build the Fedora CoreOS image, whether manually or via CI/CD automation.
Fedora CoreOS (FCOS) is also changing how it’s issuing updates to users in Fedora 43. Instead of using an OSTree repository, FCOS updates will be delivered exclusively as OCI images. FCOS 42 provided both OSTree repository and OCI registry as a transition for users. In FCOS 43, the OSTree updates are disabled entirely.
To celebrate all this incredible community work, we’ll be hosting a virtual Fedora Linux 43 Release Party! Please save the date for Friday, 21 November. We’re still finalizing the schedule and speakers, so registration isn’t open just yet, but more details will be shared soon. You can keep an eye on the Fedora Linux 43 Release Party Schedule wiki page for the latest updates!
If you run into a problem, visit our Ask Fedora user support forum. This forum includes a category where we collect common issues and solutions or work-arounds.
Drop by our “virtual watercooler” on Fedora Discussion and join a conversation, share something interesting, and introduce yourself. We’re always glad to see new people!
Below are a few noteworthy changes in the latest release of Fedora Workstation that we think you will love. Upgrade today from the official website, or upgrade your existing install using GNOME Software or through the terminal with dnf system-upgrade.
Fedora Linux 43 Workstation also ships with the brand-new GNOME 49 release, bringing a host of refinements to your desktop. This update introduces significant enhancements for multiple display setups, an improved and streamlined workflow for taking screenshots and screen recordings, and a new “Focus Mode” to help you minimize distractions. Under the hood, resource-smart background throttling improves performance and battery life, while the Settings app has been polished with a refined UI. These are just the highlights. Check out the official GNOME 49 release notes to find more information about all the new features.
One significant change we want to forewarn you about is that Fedora Linux 43 is removing the GNOME X11 packages from the Fedora repositories. All users of the GNOME X11 session will be migrated to the GNOME Wayland session with the upgrade to Fedora Workstation 43.
The transition to the GNOME Wayland session in Fedora Workstation 43 has been in the works for nearly a decade. There have been several prior steps toward this goal, such as the work in Fedora Linux 41 to remove legacy X11 dependencies from core media components.
Wayland has been the default GNOME session on Fedora Workstation for many years, but this release completes the change. The legacy gnome-session-xsession packages have been removed from the Fedora Linux 43 repositories.
This change will unlock a new level of performance and hardware compatibility. You’ll immediately notice smoother, cleaner visuals thanks to triple buffering, which dramatically reduces screen tearing. This change also improves support for a range of hardware, including enhanced drivers for Intel Xe graphics and improvements for systems using NVIDIA Optimus and Hybrid Mode.
The default video player has been changed from Totem to Showtime. Showtime is built on the newer GTK 4 and Libadwaita libraries.
The Noto Color Emoji fonts have released some new files with the COLRv1 format. The COLRv1 format is a color scalable font compared with the previous color bitmap fonts. This new scalable font format should have better or similar rendering results compared to the old bitmap font format. See the change notes for more details.
If you are an app developer, you might be interested in the upgrade to Peas 2. Peas is a gobject-based plugins engine that is used by several GNOME applications.
Be sure to check out the Fedora Linux 43 Change Set wiki for even more details about all the features and changes that went into Fedora Linux 43. Use the Fedora Discussion forum or Fedora’s Matrix chat server if you want to converse with the Fedora community about this new release!
admin )
on 2025-10-28 13:55:32 UTC
Fedora Linux 43 has been released! So, let’s see what is included in this new release for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
Alongside the rest of Fedora, we are now compressing our initrds with the Zstandard (zstd) algorithm. This should make the initrd a bit smaller and the boot a bit faster.
See the Fedora Change request and the tracking issue atomic-desktops-sig#34.
Along with the rest of Fedora, systems will install with a 2GB /boot partition. This should make things easier with the growing initrd sizes (mostly due to firmwares). Existing systems will require a backup and re-install to benefit from this change.
See the Fedora Change request.
We are adding the wireguard-tools to all variants. Users will still need to use the graphic interface in their desktop environment to configure WireGuard connections. However, it should now be easier to debug issues using the wg tool. This change was decided too late to be included in the installation ISO but it will come via an update.
See silverblue#390 and kde-sig#381.
We removed plocate from all variants.
Fedora Silverblue comes with the latest GNOME 49 release.
For more details about the changes that alongside GNOME 49, see What’s new in Fedora Workstation 43 on the Fedora Magazine.
We temporarily removed the Third Party page shown during the first boot as it was causing issues. Users will be asked if they want to enable Third Party repositories when they open GNOME Software.
This will be re-enabled once we figure out where the bug is.
See silverblue#650 and atomic-desktops-sig#74.
We added the openssl command line tool to Silverblue, to make the GSConnect extension work without having to resort to package layering or sysexts.
See silverblue#201.
Fedora Kinoite ships with Plasma 6.4, Frameworks 6.18 and Gear 25.08.
See also What’s New in Fedora KDE Plasma Desktop 43? on the Fedora Magazine.
Updates will now be automatically applied on a weekly basis, for Flatpaks and the system. You can configure the frequency or disable auto-updates in the system settings.
See the Fedora Change request and the tracking issue kde-sig#342.
Fedora Sway Atomic comes with the latest 1.11 Sway release.
Fedora Budgie Atomic comes with the latest 10.9.3 Budgie release. Budgie 10.9.3 is a bug-fix and GNOME 49 compatibility release.
Fedora COSMIC Atomic comes with the latest beta release of the COSMIC desktop.
Starting with Fedora 43, we will no longer build XFCE Atomic & LXQt Atomic unofficial images.
Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora 43. 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.).
The next major evolution for the Atomic Desktops will be to transition to Bootable Containers. See also the Fedora bootc documentation.
We have established a roadmap (atomic-desktops-sig#26) and we need your help to make this a smooth transition for all of our existing users.
We have moved the systemd system extensions (sysexts) to a new GitHub organization. The sysexts are now split between those built exclusively from Fedora packages and those built from various community sources. Make sure to update your systemd-sysupdate configs to point to the new URLs.
Now that Fedora’s new forge is available, we will start moving our repos there. You can find the new organization at forge.fedoraproject.org/atomic-desktops. We will likely start by moving the documentation and then issue tracker and the sources.
We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.
admin )
on 2025-10-27 19:39:05 UTC
Fedora has released Fedora KDE Plasma Desktop Edition 43 to the public.
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.
Fedora KDE 43 ships with Plasma 6.4.5 featuring:
Beyond the updates to KDE Plasma 6.4, there are some Fedora KDE updates that have happened with Fedora Linux 43.
Some of the key updates occurred in the core components of Fedora Linux 43, which directly impact the KDE Plasma Desktop Edition, include:
The Fedora KDE SIG hopes that you’ll find the Fedora KDE Plasma Desktop 43 to be a wonderful experience. When you’re ready to try it, click here for download links and verification instructions. If you’d like to learn more, check out the Fedora KDE Plasma Desktop website.
admin )
on 2025-10-24 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 20th – 24th October 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 43 2025 appeared first on Fedora Community Blog.
Participated in the Fedora 43 Elections!
Participated in the Fedora 47 Elections!
Participated in the Fedora 46 Elections!
Participated in the Fedora 45 Elections!
Participated in the Fedora 44 Elections!
admin )
on 2025-10-21 10:00:00 UTC
We in the CLE team and wider Fedora infra space have been talking about the future of Fedora’s development infrastructure for a while. Now it is starting to take shape, as Ryan outlined in the soft launch blog post: Both staging and production Forgejo instances are up and running in the RDU3 datacenter. That means the work of moving away from pagure.io is no longer theoretical. It is happening.
If you have a project on Pagure, you can already open a migration ticket, as described in the Forge documentation, and we will help you move it over. But this is not just about swapping one forge for another. Forgejo gives us a chance to modernize some of the core parts of Fedora’s packaging workflows, such as how we handle ownership, where we store artifacts, and how we integrate automation.
Let us take a closer look.
One of the first questions we hear is: What about CI/CD?
Forgejo upstream recommends Woodpecker/Raven, which are full CI/CD systems. These are powerful, but they are also heavy and expensive to maintain. Fedora is going to take a different approach.
We are focusing on Forgejo Actions, which are somehow API compatible with GitHub Actions(It is not a 1:1 replacement).
This allows contributors to:
For those who want to run heavy workloads, such as large test suites or extensive CI pipelines. You can connect your own self-hosted runners, while the shared Fedora infrastructure will stay lightweight, stable, and dependable. The CLE team won’t provide resources within Fedora’s Forgejo infrastructure.
There was an engaging discussion about dist-git at this year’s Flock, and one message came through clearly: as we move forward, we should take the opportunity to improve the model rather than simply replicate it. The conversation focused on three key areas: package ownership, artifact storage, and Packit integration.
A central theme of our discussion was how we manage permissions and contributions in a way that is both secure and efficient. The goal is to leverage Forgejo’s powerful features to refine our processes.
Right now, all Fedora packages officially belong to the Fedora Project, but the daily reality is a patchwork of individual maintainers and teams. This works, but it leaves gaps.
Forgejo lets us improve this. With its more flexible permissions, we can introduce roles such as maintainer, co-maintainer, or limited contributor. Groups can own packages as first-class entities.
Today, the package build process relies on the Lookaside Cache. It is simple, but it is also dated. It struggles with very large artifacts, it separates code and artifacts, and it does not integrate well with modern workflows.
Several options are on the table:
This is a complex decision with long-term implications. No decision has been made yet. We are committed to a transparent process and will submit a formal Change Proposal to the Fedora Engineering Steering Committee (FESCo) before any major architectural change is implemented, ensuring the entire community can weigh in.
Packit is essential for connecting upstream projects to Fedora packaging. It automates updates, tests, and workflows that save maintainers huge amounts of time.
On Pagure, Packit integration was always custom. On GitHub and GitLab, it is native. This gap created extra work and sometimes rougher edges for Fedora contributors.
The Packit team already prototyped Forgejo support during Google Summer of Code. The service is called Avant, and it’s in our sights as one of the first integration testing areas in staging deployment.
The next steps are:
The long-term goal is clear. Packit in Forgejo should feel natural and seamless, not bolted on.
Some of Fedora’s container builds run through Konflux. Right now, Konflux only supports GitHub and GitLab. To make it work with Forgejo, we built a workaround that mirrors repositories into GitHub. It works, but it is fragile and wasteful.
The better solution is native Forgejo integration. That means upstream changes in Konflux, secure authentication, and removing the mirroring step entirely. Until then, the GitHub workaround will stay in place, but long-term, the focus is on a direct, reliable path.
A migration like this cannot happen overnight. We need to keep workflows running while the move happens. To do this, we are building a compatibility bridge.
The bridge includes:
The goal is continuity. Contributors should be able to keep working while the infrastructure gradually changes behind the scenes.
Fedora’s ecosystem depends on many tools that integrate with dist-git. Each needs some level of adjustment.
The approach is simple. During the transition, a compatibility layer keeps these tools running. Once Forgejo support is mature, the tools can be updated to use Forgejo directly.
This migration is not just an infrastructure swap. It is a chance to fix long-standing pain points, simplify workflows, and make Fedora’s packaging system stronger for the future.
By the end of the Year, I expect us to be able to:
Nice to have:
Fedora thrives on collaboration. Forgejo is our next step toward a modern, maintainable, and community-driven development platform.
Join us in shaping it together, try the staging environment, file migration ticket, and share your feedback in our matrix channel for ideas and discussion, use the git-forge-future tag.
The post Forging Fedora’s Future with Forgejo appeared first on Fedora Community Blog.
This outage impacts the Fedora Forge instance Reason: database maintenance
admin )
on 2025-10-17 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: Oct 13 – Oct 17 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 42 appeared first on Fedora Community Blog.
admin )
on 2025-10-16 10:00:00 UTC
It’s been over a week since I attended OSCAFest 2025 and CHAOSScon Africa 2025, the experience from both gatherings have left lasting impressions and memorable moments on me. All located in Lagos, Nigeria, it was a week-long activity attending CHAOSScon Africa 2025 on the 13th and OSCAFest 2025 on the 15th – 16th of August.
CHAOSS, which is dedicated to creating metrics and analytics to measure the health and sustainability of open-source projects, this time served as an insightful and educational conference. Its sessions dove deep into topics of inclusion, building open-source communities and the discerning business value of open source.
Being involved in The Fedora Project helped me recognize the significant creative value that upstream open source projects contribute to commercial software. Brian Proffitt (Red Hat) talk on the “Metrics and the Business of Open Source” revealed “The Value and Freedom of Creativity” in the Red Hat’’s approach to open source.
On August 15th, I joined the OSCAFest train, experiencing the biggest open-source festival in Africa. The event attracted a diverse range of attendees, including developers, designers, and enthusiasts, with a little under a thousand people in attendance. There were so many talk sessions spread across five different rooms that I occasionally had to move from room to room to attend the ones I was interested in. At OSCAFest, the focus was on enabling growth through open source and inspiring attendees with mentorship-driven talks.
Overall, I had a great time at both events as a Fedora ambassador. I made new friends, connected with people about the Fedora community, and onboarded some potential new contributors to The Fedora Project. Being part of both events as an ambassador creates a pathway for greater visibility of The Fedora Project and our incredible community. It’s a strong start to establishing a larger regional community of contributors and enthusiasts from Africa.
I shared some additional event highlights on my Twitter/X handle (see tweet 1 and tweet 2). One key takeaway was a noticeable difficulty in the onboarding process, while I aimed to recruit new Fedora contributors, I found that Element Chat, our primary community platform, was unfamiliar to many attendees. I frequently received questions about whether we used platforms like Discord or Slack, which often halted conversations. This was a clear indication that for future event outreach, adopting a more popular, regionally familiar platform could serve as a better first line of onboarding, attracting and retaining an audience until they are ready to progressively move to our stable platforms.
I look forward to attending these events again, with the hope of speaking to the audience and further promoting our great community.
The post OSCAFEST’25 & CHAOSS’25 Lagos, Nigeria appeared first on Fedora Community Blog.
admin )
on 2025-10-14 10:00:00 UTC
Hello Fedora Community,
We are excited to share an update on the Packit as Fedora dist-git CI change proposal. This initiative aims to transition Fedora dist-git CI to a Packit-based solution, deprecating Fedora CI and Fedora Zuul Tenant. The change affects the triggering and reporting mechanism for tests but does not alter the tests themselves or the test execution service (Testing Farm). The transition is gradual, allowing maintainers to try the integration out, provide feedback and catch issues early. You can read more about the benefits and why we are doing this in the proposal itself.
As part of the second and third phases, we have implemented Packit-driven installability checks and custom tests for Fedora dist-git PRs.
These features are currently opt-in, and maintainers can enable them by adding their projects to our configuration here by creating a pull request.
Once projects are listed in our packit-service configuration, Packit will automatically run a Koji scratch build and an installability check for every push to a dist-git PR.
Currently, the installability check executed by Packit is identical to the one performed by Fedora CI. In the future, based on user requests and already collected feedback we may plan to enhance it.
Additionally, if a project has both a .fmf/version file and a tmt plan defined in the plans directory, Packit will also execute custom tests in Testing Farm and report the results.
You can see an example of how this feedback appears in this python-specfile example PR or in the screenshots below:
Retriggering of all the jobs via pull request comments is also possible now, for details, see the documentation.
Do you want to know more? Look at our Packit as Fedora dist-git CI documentation.
We welcome feedback and questions! For bugs or feature requests, please use this issue tracker. For ideas or suggestions to discuss, feel free to add a discussion topic here. And for any other questions, join us in the #packit:fedora.im channel on Matrix.
Transition to the new Packit-based CI as the default mechanism, replacing Fedora CI.
This transition will require addressing several technical challenges:
We welcome your feedback. If you’d like to contribute toward reaching our final goal, please add your projects to the list of enabled projects for our Fedora CI here. We’re open to suggestions for improvement and appreciate your support. Thank you!
Recap of the plan
You can also check our tasklist in this issue.
Final phase targets Fedora Linux 44
The original plan was to do the switch during the Fedora Linux 43 cycle, but most of the Packit team members are temporarily focusing on another project. We promised to provide an actively maintained CI solution for Fedora dist-git, so we would rather postpone the default change by one Fedora cycle to ensure we have the capacity to implement the change properly. However, the current Packit workflows are still supported, including the opt-in approach to Fedora dist-git CI. This means you have more time to try it and provide feedback, and we can deliver a more polished solution when it becomes the default for everyone.
We appreciate your support and look forward to your feedback!
Best, the Packit team
The post Packit as Fedora dist-git CI: Phase 2 and 3 completed appeared first on Fedora Community Blog.
admin )
on 2025-10-10 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: Oct 6 – Oct 10 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 41 appeared first on Fedora Community Blog.
admin )
on 2025-10-09 10:00:00 UTC
Hi everyone, I’m Mayank Singh, and I’ve been working on a GSoC 2025 project aimed at simplifying the packaging process in Fedora.
I have been working on making an implementation of the new package review process, where everything happens in one place around git. Instead of switching between Bugzilla tickets, for hosting the source rpm and logs. Instead new contributors can review their packages through pull requests.
Let’s dive into a brief comparison between the current Bugzilla process and the new one.
If you want a package that is not available in Fedora repositories yet, the process looks something like:
.spec file, which declares your package sources and instructions on building it.This process isn’t reliable, it forces developers to constantly juggle multiple tools and tabs. This creates a fragmented and disjointed experience.
We try to solve this problem by trying to focus the workflow around git. A tool developers already use daily. The process is made much simpler in these steps:
The service takes care of the rest for assisting in the review process.
Once the Pull Request is open, the following automated actions are triggered to assist the review:
Checking the latest entry here, we can find the Testing Farm run and inspect the logs to trace the cause of failure.
The checks failed due to a broken package and its dependencies.
fedora-review tool runs, and its formatted output is posted directly as a comment in the pull request discussion.rpmlint checks using Testing Farm.If a change is needed, one can just push a new commit and the service takes care of building and testing now.
Check out the service here: review
The service is based on the packit-service codebase to handle COPR builds, Testing Farm integration, and orchestration of the actions described above with forgejo support.
Repo link: packit/avant
Looking ahead, this workflow can be extended to transfer the packages into dist-git after approval of the package.
Big thanks to my mentor and Fedora community for guidance throughout the GSoC timeline.
Feedback’s appreciated ! Thank you.
The post GSoC 2025: Bringing package reviews to Forgejo appeared first on Fedora Community Blog.
This outage impacts the Fedora Forge instance
admin )
on 2025-10-07 10:00:00 UTC
This week in the Fedora project, we did some small changes to the details and reporting of information in the service.
Previously, we were fetching the text version of the fedora-review report, the problem was it had way too much text for a comment and I had to parse the text file, to format the comment before posting into sections in collapsible tags manually.
While testing, I found out that the tool also publishes a json version with proper segregation of categories, items, checks and the related documentation to each rule. It made it much easier to parse and comment.
Another small change was to report the status for install-ability and rpmlint checks separately from Testing Farm. My mentor suggested this approach to make it easier for users to interpret feedback.
One can check detailed logs of each run by going to dashboard through the details button.
I’m still working through some challenges with unit testing. The tricky part is mocking external dependencies to properly test the integration code in the service. The aim is to catch smaller bugs earlier with better coverage in ogr, the library that’s being used for interacting with forgejo.
We almost have a way to review packages directly within a Forgejo repository. This will allow us to set up a dedicated repo for performing package reviews with automated feedback from tools and experienced packagers.
In the future, this idea could be extended further as Fedora moves to Forgejo, even handling dist-git setup.
For now, my next tasks are:
I’m grateful to my mentor, František Lachman, for his constant support and guidance.
The post Simplifying Package Submission Progress (15 August – 22 August) – GSoC ’25 appeared first on Fedora Community Blog.
admin )
on 2025-10-03 06:27:15 UTC
You went above and beyond - Fedora Project would not be the same without you!
You visited the Fedora booth at TXLF 2025!
admin )
on 2025-10-02 10:00:00 UTC
This week in the project, we covered the changes on how we handle the pull request to make it a more intuitive process.
One of our key goals is to reduce friction for contributors as much as possible. With that in mind, my mentor suggested we align our required file structure with the standard dist-git layout, which defines a package simply with a specfile and patches for the upstream source.
Previously, our service required a packit.yaml configuration file in the repository just to trigger COPR builds and Testing Farm jobs. We have now eliminated this dependency. By parsing the specfile directly from within a pull request, our service can infer all the required context automatically. This removes the need for any boilerplate configuration.
As I have mentioned before that we are currently using the rawhide container images for development, since the current stable Fedora release does not have the required versions of the python bindings for forgejo.
The problem was I was running a dnf update before installing anything in the container and for some reason ca-certificates got upset in the container, which caused the service to not be able to communicate over the network.
With some hit and trial, I discovered that removing that line and simply just not updating can work. That fixed it for now, but the good news is Fedora 43 is going to enter a Beta or a package freeze phase so there should not be any such problems now.
With these core features now in place, my focus for the upcoming weeks will be on two main tasks:
The post Simplifying Package Submission Progress (7 August – 14 August) – GSoC ’25 appeared first on Fedora Community Blog.