We're updating Copr servers to F43
This outage impacts the copr-frontend and the copr-backend.
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.
We will be updating and rebooting various servers. Services will be up or down during the outage window.
This outage impacts the copr-frontend and the copr-backend.
admin )
on 2025-09-30 10:00:00 UTC
This week in the project, we added the support for status reporting of the package actions via commit statuses.
A key improvement this week is in status reporting. Now, whenever an action like a package build or a test succeeds or fails, the result is directly reported as a commit status on the pull request. This provides immediate clear feedback right where it’s most visible, the list of checks one can find on the bottom of the PR page.
To achieve this, I had to implement the necessary commit status logic for Forgejo within OGR, the library we use for Git forge interactions, as it was previously missing.
I noticed that Forgejo does not really support commenting under individual commits and every comment therefore is just a normal comment in the discussion. I focused on the latter instead.
Currently, what’s left is writing unit tests for the new code, will be done along with pushing the code into upstream sources.
With this feature in place, my next steps will be:
The post Simplifying Package Submission Progress (29 July – 7 August) – GSoC ’25 appeared first on Fedora Community Blog.
admin )
on 2025-09-26 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: 22nd – 26th September 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 39 2025 appeared first on Fedora Community Blog.
admin )
on 2025-09-25 13:10:55 UTC
Artificial Intelligence is a transformative technology, and as a leader in open source, the Fedora Project needs a thoughtful position to guide innovation and protect our community’s values.
For the past year, we have been on a journey with the community to define what that position should be. This process began in the summer of 2024, when we asked for the community’s thoughts in an AI survey. The results, which we discussed openly at Flock and in Council meetings, gave us a clear message: we see the potential for AI to help us build a better platform, but we also have valid concerns about privacy, ethics, and quality.
The draft we are proposing below is our best effort to synthesize the Fedora community’s input into a set of clear, actionable guidelines. It is designed to empower our contributors to explore the positive uses of AI we identified, while creating clear guardrails to protect the project and its values from the risks we highlighted.
In accordance with the official Policy Change policy, we are now opening a formal two-week period for community review and feedback. We encourage you to read the full draft and share your thoughts on the discussion.fedoraproject.org post.
After the two-week feedback period, the Fedora Council will hold a formal vote on ratifying the policy via ticket voting. Thank you for your thoughtful engagement throughout this process. We look forward to hearing your feedback as we take this important next step together.
The Fedora Project is a community built on four foundations: Freedom, Friends, Features, and First. We envision a world where everyone benefits from free and open source software built by inclusive, open-minded communities. In the spirit of our “First” and “Features” foundations, we see Artificial Intelligence as a tool to empower our contributors to make a more positive impact on the world.
We recognize the ongoing and important global discussions about how AI models are trained. Our policy focuses on the responsible use of these tools. The responsibility for respecting the work of others and adhering to open source licenses always rests with the contributor. AI assistants, like any other tool, must be used in a way that upholds these principles.
This policy provides a framework to help our contributors innovate confidently while upholding the project’s standards for quality, security, and open collaboration. It is a living document, reflecting our commitment to learning and adapting as this technology evolves.
We encourage the use of AI assistants as an evolution of the contributor toolkit. However, human oversight remains critical. The contributor is always the author and is fully accountable for their contributions.
2. AI In Fedora Project Management: To avoid introducing uncontrollable bias, AI/ML tools must not be used to score or evaluate submissions for things like code of conduct matters, funding requests, conference talks, or leadership positions. This does not prohibit the use of automated tooling for tasks like spam filtering and note-taking.
Our commitment is to our users’ privacy and security. AI-powered features can offer significant benefits, but they must be implemented in a way that respects user consent and control.
One of our key goals is to make Fedora the destination for Linux platform innovation, including for AI.
The data generated by the Fedora Project is a valuable community asset. Its use in training AI models must respect our infrastructure and our open principles.
The post Council Policy Proposal: Policy on AI-Assisted Contributions appeared first on Fedora Community Blog.
admin )
on 2025-09-25 10:00:00 UTC
We’re excited to share our Quarterly Reports from Q1 to Q3 2025. From January to September, we’ve welcomed new members to the DEI team, hosted the Fedora Mentor Summit (FMS), joined Outreachy, connected during Fedora Social Calls, and worked on our Event DEI Location Policy. Here’s a quick look back at what we’ve accomplished together so far this year!
The Fedora Mentor Summit was held in person at Flock to Fedora 2025 in Prague, Czech Republic, and it was a great opportunity to connect and share. Some of the highlights included:
See more in the Past Events section
This year, three Fedora Outreachy interns joined us:
These projects highlight Fedora’s commitment to mentorship and building new contributor pathways.
In July 2025, the DEI team kicked off Fedora Social Calls, casual hangouts to connect beyond project work.
These calls help build community bonds and keep Fedora fun and welcoming.
See the Discussion thread here. If you’d like to participate or propose another day, kindly reply in the thread. Updates about the calls will be shared there. At present, we meet on the second Friday of each month from 3 pm UTC. I hope to see you there.
The Event DEI Location Policy is now an official Council policy. Thanks to Michael Scherer (misc) for helping push this forward!
Its goal is simple: to ensure Fedora’s global events are hosted in places where all contributors, including those from marginalized communities, can participate without barriers.
This policy helps keep Fedora events inclusive and welcoming for everyone worldwide.
In June 2025, Cornelius Emase (lochipi) was nominated and welcomed as a new member of the Fedora DEI Team. Cornelius joined as part of the June–August 2025 Outreachy cohort with the DEI team.
In August 2025, Chris Idoko (chris) was nominated to join the Fedora DEI Team, following his contributions as an Outreachy intern in 2023, representing Fedora at OSCAFEST 2025, and helping organize Week of Diversity 2024.
September 2025 – Micheal (misc) was nominated and welcomed to the Fedora DEI Team. misc has been actively involved in Fedora through creating the Event DEI Location Policy, presenting “Injecting DEI into Community Event Policies” at Flock 2024, contributing to badges, community infrastructure, and more.
Stay tuned for updates on upcoming social calls, ongoing mentorship, and preparations for 2026 DEI activities.
The post Fedora DEI Team Q1–Q3 2025 Highlights appeared first on Fedora Community Blog.
admin )
on 2025-09-24 08:00:00 UTC
Image mode for Fedora Linux leverages bootable containers. This technology enables OCI containers to serve as a transport and delivery mechanism for operating system content. This article will guide you through how to use that technology to quickly create a Web Server using Caddy
Bootable containers leverage existing OCI container tools (like Podman and Docker) and transport protocols for operating system management. This streamlines the configuration and distribution of operating systems through Containerfiles and container registries. The Universal Blue (ublue) community has embraced this technology, offering diverse operating systems. They also provide a project template to simplify the creation of custom operating systems.
We will begin by using the image-template GitHub repository to create our own repository. For this guide I have named it fedora-web-server.
If you don’t have a GitHub account, you can simply clone the repository to your local machine and rename it to reflect your project’s name.
$ git clone git@github.com:<username>/fedora-web-server.git
$ cd fedora-web-server
Image-template simplifies custom OS creation by providing a pre-built structure and essential files. To begin building our web server, we need to choose a base image. While image-template defaults to the ublue Bazzite image, we’ll switch to quay.io/fedora/fedora-bootc:42. Make this change by editing the Containerfile (see immediately below) and replacing the default Base Image.
# Allow build scripts to be referenced without being copied into the final image
FROM scratch AS ctx
COPY build_files /
# Base Image
FROM quay.io/fedora/fedora-bootc:42
RUN --mount=type=bind,from=ctx,source=/,target=/ctx \
--mount=type=cache,dst=/var/cache \
--mount=type=cache,dst=/var/log \
--mount=type=tmpfs,dst=/tmp \
/ctx/build.sh
### LINTING
## Verify final image and contents are correct.
RUN bootc container lint
fedora-bootc is a minimal image designed for customized installations. For this project, I’ll install cloud-init to facilitate deployment and testing both in the cloud and locally. I’ll modify the build_files/build.sh script, which is executed from within the Containerfile, to incorporate cloud-init into our customized OS.
The build.sh file will appear as follow:
#!/bin/bash
set -ouex pipefail
### Install packages
dnf5 install -y --setopt=install_weak_deps=0 cloud-init
Since I want to keep my OS minimal I am not installing weak dependencies.
Caddy is an open-source, modern web server known for its simplicity, security, and automatic configuration—it “just works.” For our Fedora Bootc server, we’ll run Caddy using its container image, docker.io/caddy. We’ll leverage quadlet for seamless integration with systemd, allowing our Caddy container to operate like any other systemd service. Create the following file:
$ cd build_files $ touch caddy.container
and enter the following text into caddy.contatiner :
[Unit] Description=Caddy Web Server After=network-online.target [Container] Image=docker.io/caddy:2-alpine PublishPort=80:80 PublishPort=443:443 Memory=512m Volume=/var/caddy-data/:/data:Z Volume=/var/caddy-config/:/config:Z Volume=/var/log/caddy/:/var/log/caddy:Z Volume=/etc/caddy:/etc/caddy:Z Volume=/var/www/:/var/www:Z [Service] Restart=always [Install] # Start by default on boot WantedBy=multi-user.target
For those familiar with systemd services, the syntax and directives will be recognizable. The [Container] section declares the image to be used, the ports to be published, and the volumes to be shared between the host and the container.
We can now modify the build.sh to copy that file in our custom OS, as shown here:
#!/bin/bash set -ouex pipefail ### Install packages dnf5 install -y --setopt=install_weak_deps=0 cloud-init # Copy caddy.container to /etc/containers/systemd/caddy.container cp /ctx/caddy.container /etc/containers/systemd/caddy.container
The final step to create a working Caddy server is to add the configuration file. Let’s create a Caddyfile:
$ touch Caddyfile
and enter the text shown below:
# Caddy configuration with automatic Let's Encrypt certificates
# Replace 'your-domain.com' with your actual domain name
# For automatic HTTPS with Let's Encrypt, use your domain name instead of :80
# your-domain.com {
# root * /var/www
# file_server
# log {
# output file /var/log/caddy/access.log
# }
# }
# For local development (HTTP only)
:80 {
root * /var/www
file_server
log {
output file /var/log/caddy/access.log
}
}
We can now copy that file in our OS, by editing build.sh
#!/bin/bash set -ouex pipefail ### Install packages dnf5 install -y --setopt=install_weak_deps=0 cloud-init # Copy caddy.container to /etc/containers/systemd/caddy.container cp /ctx/caddy.container /etc/containers/systemd/caddy.container # Create /etc/caddy directory and copy Caddyfile mkdir -p /etc/caddy cp /ctx/Caddyfile /etc/caddy/Caddyfile
To complete the setup, we’ll use systemd.tmpfiles to create Caddy’s necessary internal directories. This approach is essential because /var in bootable containers is mutable through overlayfs, meaning it’s only created at runtime and isn’t part of the container build process. Systemd.tmpfiles provides a straightforward solution to this limitation. Modify your build.sh file as follow:
#!/bin/bash set -ouex pipefail ### Install packages dnf5 install -y --setopt=install_weak_deps=0 cloud-init # Copy caddy.container to /etc/containers/systemd/caddy.container cp /ctx/caddy.container /etc/containers/systemd/caddy.container # Create /etc/caddy directory and copy Caddyfile mkdir -p /etc/caddy cp /ctx/Caddyfile /etc/caddy/Caddyfile # Create tmpfiles.d configuration to set up /var directories at runtime cat > /usr/lib/tmpfiles.d/caddy.conf << 'EOF' # Create Caddy directories at runtime d /var/log/caddy 0755 root root - d /var/caddy-data 0755 root root - d /var/caddy-config 0755 root root - EOF
That’s it. We now have a Containerfile using fedora-bootc:42 as base image, a build script installing cloud-init and installing Caddy via quadlet and copying the Caddy configuration as well as setting up Caddy’s internal directories.
We can now build our custom operating system. The process involved a Containerfile based on fedora-bootc:42, a build script that installed cloud-init and Caddy (configured via quadlet), and the necessary Caddy configuration and directory setup.
If you want your Caddy web server to serve a custom html page, you can copy the following files https://github.com/cverna/fedora-web-server/tree/main/build_files/web and edit the build.sh script as follows:
#!/bin/bash set -ouex pipefail ### Install packages dnf5 install -y --setopt=install_weak_deps=0 cloud-init # Copy caddy.container to /etc/containers/systemd/caddy.container cp /ctx/caddy.container /etc/containers/systemd/caddy.container # Create /etc/caddy directory and copy Caddyfile mkdir -p /etc/caddy cp /ctx/Caddyfile /etc/caddy/Caddyfile # Copy web content to /usr/share for the base image mkdir -p /usr/share/caddy/web cp -r /ctx/web/* /usr/share/caddy/web/ # Create tmpfiles.d configuration to set up /var directories at runtime cat > /usr/lib/tmpfiles.d/caddy.conf << 'EOF' # Create Caddy directories at runtime d /var/log/caddy 0755 root root - d /var/caddy-data 0755 root root - d /var/caddy-config 0755 root root - # Copy web content from /usr/share to /var at runtime d /var/www 0755 root root - C /var/www/index.html 0644 root root - /usr/share/caddy/web/index.html C /var/www/fedora-logo.png 0644 root root - /usr/share/caddy/web/fedora-logo.png C /var/www/caddy-logo.svg 0644 root root - /usr/share/caddy/web/caddy-logo.svg EOF
The image-template repositories equip you with the necessary tools for local image construction. Let’s begin by verifying that all dependencies are in place.
$ sudo dnf install just git jq podman
Then we can run just to build the container. The following shows the just command and subsequent output:
$ just build fedora-web-server latest [1/2] STEP 1/2: FROM scratch AS ctx [1/2] STEP 2/2: COPY build_files / --> Using cache 94ec17d1689b09a362814ab08530966be4aced972050fedcd582b65f174af3a3 --> 94ec17d1689b [2/2] STEP 1/3: FROM quay.io/fedora/fedora-bootc:42 [2/2] STEP 2/3: RUN --mount=type=bind,from=ctx,source=/,target=/ctx --mount=type=cache,dst=/var/cache --mount=type=cache,dst=/var/log --mount=type=tmpfs,dst=/tmp /ctx/build.sh && ostree container commit --> Using cache 8cac20d690bda884b91ae2a555c4239a71f162fbd4ff36a1e2ed5f35f5dfb05a --> 8cac20d690bd [2/2] STEP 3/3: RUN bootc container lint --> Using cache 5cb978e3db5a2bcd437018a6e97e1029d694180002f5fa098aaf540952941dd4 [2/2] COMMIT fedora-web-server:latest --> 5cb978e3db5a Successfully tagged localhost/fedora-web-server:latest
Just is a useful tool for running project-specific commands, similar to Makefiles, and uses a ‘justfile’. As the image functions like any other container image, we can inspect it using Podman.
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/fedora-web-server latest 5cb978e3db5a 4 hours ago 1.95 GB quay.io/fedora/fedora-bootc 42 586b146c456e 2 days ago 1.88 GB
The disk image for our server is built using just as follows:
$ just build-vm localhost/fedora-web-server latest
This will use the bootc-image-builder project to build a disk image of our bootable container. Once the command has finished, we have a qcow2 image in the output directory
$ ls output/qcow2 disk.qcow2
We can now use that qcow2 image to start a Virtual Machine and run our webserver.
To run the server we can use any virtualization software. In this case I am using virt-install:
$ sudo dnf install virt-install libvirt $ virt-install --cloud-init root-ssh-key=/path/to/ssh/public.key --connect qemu:///system --import --name fedora-web-server --memory 2048 --disk output/qcow2/disk.qcow2 --os-variant fedora41 Starting install... Creating domain... ... Fedora Linux 42 (Adams) Kernel 6.16.5-200.fc42.x86_64 on x86_64 (ttyS0) enp1s0: 192.168.100.199 fedora login:
Once the virtual machine is up and running, you can use ssh to login as root, using the local IP address of the virtual machine.
$ ssh root@192.168.100.199
$ bootc status
● Booted image: localhost/fedora-web-server:latest
Digest: sha256:a813a8da85f48d8e6609289dde87e1d45ff70a713d1a9ec3e4e667d01cb470f2 (amd64)
Version: 42.20250911.0 (2025-09-12T07:36:05Z)
Currently, the server’s update capability is limited because the images point to the localhost/fedora-web-server:latest container image. This can be resolved by building and pushing these container images to a container registry such as quay.io or ghcr.io. Detailed instructions for these steps are available in the README file of the ublue-os/image-template repository.
To verify that the web server is running successfully, access that same ip address from your web browser and you should get the following web page.
This guide demonstrates the power of image mode for Fedora Linux using bootc and Caddy to build a lightweight, custom web server. By leveraging container technologies for OS delivery and Caddy for simplified web serving, users can efficiently deploy and manage web applications, setting a strong foundation for future customization. Make sure to check the library of examples to get ideas on how to use bootc.
admin )
on 2025-09-22 08:00:00 UTC
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. This article provides the steps to rebase to the newly released Fedora Linux 43 Beta, and how to revert if anything unforeseen happens.
NOTE: Before attempting an upgrade to the Fedora Linux 43 Beta, apply any pending upgrades.
Because Fedora LInux 43 Beta is not available in GNOME Software, the whole process must be done through a terminal.
First, check if the 43 branch is available, which should be true now:
$ ostree remote refs fedora
You should see the following line in the output:
fedora:fedora/43/x86_64/silverblue
If you want to pin the current deployment (this deployment will stay as an option in GRUB until you remove it), you can do it by running:
# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0
To remove the pinned deployment use following command ( “2” corresponds to the entry position in the output from rpm-ostree status ):
$ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora 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 Silverblue 43 Beta.
If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 43 Beta at all — it’s easy to go back. Pick the previous entry in the GRUB boot menu (you need to press ESC during boot sequence to see the GRUB menu in newer versions of Fedora Silverblue), and your system will start in its previous state. To make this change permanent, use the following command:
$ rpm-ostree rollback
That’s it. Now you know how to rebase to Fedora Silverblue 43 Beta and fall 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 Linux? For example from Fedora Silverblue 41 to Fedora Silverblue 43?
Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (41->42 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I got 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 article.
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 Updating using the terminal part of this guide for every ostree edition of Fedora. Just use the corresponding branch. For example for Kinoite use fedora:fedora/43/x86_64/kinoite
admin )
on 2025-09-19 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: 15 Sep – 19 Sep 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 38 appeared first on Fedora Community Blog.
admin )
on 2025-09-19 08:00:00 UTC
This guide provides a step-by-step walk-through for integrating a uTrust FIDO2 security key (Identiv uTrust) with Fedora 42 to secure:
The guide is intended for instructional cybersecurity labs and intermediate Fedora users. It prioritizes PIN + Touch verification for strong security.
NOTE: Since misconfiguration can result in system lockout, readers should work only on non-production systems, maintain a fallback password, and back up all critical data before making changes.
The following technology is used in this walk-through:
FIDO2 (Fast Identity Online 2) is a standard for passwordless or multi-factor authentication using hardware tokens. It relies on public key cryptography and supports PIN or biometric verification. In this setup, FIDO2 provides secure, hardware-backed authentication using a PIN and a required physical touch on the key.
LUKS2 (Linux Unified Key Setup 2) is the full-disk encryption format used in modern Linux systems.
PAM (Pluggable Authentication Modules) and Polkit (PolicyKit) control authentication for logins and privilege escalation across both GUI and CLI actions.
This guide combines these technologies to deliver end-to-end security — from full-disk decryption at boot, to graphical login, to administrative elevation with sudo.
The following hardware/software is used in this implementation:
Hardware and Software:
FIDO2 Key: Identiv uTrust FIDO2
Disk Setup
The following phases occur during implementation:
Install required development and security packages:
sudo dnf install -y
gcc make cmake git autoconf automake libtool
pam-devel systemd-devel glibc-devel openssl-devel
libfido2 libfido2-devel fido2-tools u2f-host pam-u2f
pcsc-lite pcsc-lite-ccid pcsc-tools ccid opensc
authselect cryptsetup pam_passwdqc fprintd-pam gnome-keyring-pam
Enable and start the PC/SC daemon for smartcard support:
sudo systemctl enable --now pcscd
Polkit GUI prompts were not enabled on my test system (no /etc/pam.d/polkit-1 and no running user agent). If you want FIDO2 for Polkit dialogs, ensure a compatible agent is running (for Cinnamon: polkit-gnome-authentication-agent-1). In testing, GUI prompts were not enabled by default and required additional configuration.”
Screensaver unlock: When the screen is locked, Fedora may default to the password prompt. Click the small two-person icon to switch to the FIDO2 method. Keep a fall-back password available. In various tests some desktop prompts did not always default to FIDO2.
The following sequence of images shows the following:
Backup:
mkdir -p ~/fido2-audit/pam_restore
for file in sudo lightdm cinnamon-screensaver system-auth password-auth polkit-1;
do
sudo cp ~/fido2-audit/pam/$file ~/fido2-audit/pam_restore/$file
done
Restore if needed using TTY or Live USB.
Emergency Login:
Multiple FIDO2 Keys:
lsusb sudo usbreset /dev/bus/usb/001/003
Strengths:
Risks:
Recommendations:
| Component | Delay Added |
|---|---|
| Boot (FDE) | ~5–10 seconds |
| GUI Login | ~2–3 seconds |
| Sudo/Polkit | ~1–2 seconds |
This guide demonstrates the successful integration of a uTrust FIDO2 security key with Fedora 42 for secure authentication across LUKS2 full-disk encryption, LightDM login, and sudo elevation. The setup is stable, reproducible, and well-suited for labs or intermediate Fedora users.
Polkit integration is optional and may vary by desktop environment. In testing, GUI prompts were not enabled by default and required additional configuration.