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.
Coordinated Scheduling with DevConf CZ
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.
Call for Proposals & Conference Themes
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.
Planning for Flock 2026
Here is what you need to know to plan your attendance:
Registration: Conference registration is scheduled to open in January 2026.
Sponsorship: Is your company or organization interested in sponsoring Flock 2026? Our sponsorship prospectus for Flock 2026 is now available on the Flock 2026 website. Organizations interested in supporting Flock and the Fedora community are encouraged to review the prospectus and contact the organizing team with any questions.
Hotel Block: A discounted block of rooms is arranged at the conference hotel. More information about the discounted hotel block can be found on the Flock website.
Travel Day & Connections: 17 June is designated as a free travel day between Flock to Fedora 2026 and DevConf.CZ. Frequent bus and train connections are available for travel between Prague and Brno.
Sponsored Travel: We intend to offer sponsored travel again for Flock to Fedora 2026. More details will follow in December 2025.
Get Involved & Ask Questions
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.
A Note on Our Flock to Fedora 2026 & 2027 Plans
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.
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
Infrastructure & Release Engineering
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
Fedora Infra
Continue to work on timeout issue. Networking has some ideas for after f43 release.
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.
Update your existing system
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.
Note
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.
Rebasing using GNOME Software
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?
Rebasing using terminal
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.
How to roll back
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:
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!
Upgrade
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.
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.
Notable User Visible Changes
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.
Plumbing Upgrades
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.
Save the Date: Fedora Linux 43 Release Party!
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 hit a snag
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.
Just drop by and say “hello”
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.
GNOME 49
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.
Wayland-only GNOME
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.
A new default video player — Showtime
The default video player has been changed from Totem to Showtime. Showtime is built on the newer GTK 4 and Libadwaita libraries.
Use COLR for Noto Color Emoji
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.
Peas 2.0
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.
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).
Changes for all variants
zstd compressed initrds
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.
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.
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.
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.
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.
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.).
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.
New home for the Fedora sysexts
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.
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 Plasma 6.4
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:
More flexible tiling. You are able to choose a different tile layout for each of your virtual desktops.
New Spectacle. Spectacle, Plasma’s screenshot tool, got a complete overhaul.
Color Management. The Display and Monitor page in System settings comes with a brand new HDR calibration wizard.
Accessibility. You can now move the pointer using your keyboard’s number pad keys, or use a three-finger touchpad pinch gesture to zoom in or out.
Notifications. When any applications are in full screen mode, Plasma will enter Do Not Disturb mode and only show urgent notifications. When you exit full screen mode, you’ll see a summary of any notifications you missed, and they’ll be right there in the System Tray for your perusal.
Apps. The Application Launcher will place a green New! tag next to newly installed apps, so you can easily find where something you just installed lives in the menu.
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
Infrastructure & Release Engineering
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
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.
Automation, Actions, and CI
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:
Automate ticket and pull request workflows
Run small repo-local tasks such as linting, simple checks, or doc generation.
Trigger jobs in external services like COPR or Jenkins
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.
Rethinking Dist-Git
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.
Modernizing Access Control and Contribution Workflows
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.
Key takeaways include:
A Shift to Merge Requests: There is strong momentum to make Merge Requests (MRs) the default contribution method for everyone. This “review-first” approach ensures that all changes to our packages benefit from peer review, improving code quality and stability.
Redefining the “Proven Packager” Role: We recognize the immense value and trust placed in our Proven Packagers. Instead of a direct-push model, we are exploring how this role can evolve within a merge-request workflow. A formal policy proposal for this is already being drafted.
Hardening Our Security: There was a unanimous agreement to enforce “hard rules” against rewriting git history. Force pushes to primary branches will be disabled across the board to protect the integrity of our repositories.
Granular Permissions: Forgejo will allow us to set fine-grained permissions for different actions. We plan to separate the ability to change package content from the ability to change repository configuration, adding another layer of security.
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.
Permissions are all or nothing. You either have commit rights or you do not.
It is not always clear who is responsible for a package at any given time.
Onboarding new maintainers or transferring ownership when someone steps back is often manual and slow.
Critical packages such as toolchains affect the whole distribution, but our ownership model does not reflect that impact.
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.
Artifact storage
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:
Using git lfs: An industry-standard solution for storing large files in Git. While it integrates cleanly with Forgejo, it’s not compatible with mirroring infrastructure.
Leveraging Forgejo’s Package Registry: We could repurpose Forgejo’s built-in registry to store source tarballs. While it sounds wonderful to solve all the problems with one tool. We would be misusing the feature and need to maintain compatibility.
A Radically Simpler Approach: Some suggested moving away from a separate cache entirely, embracing a “source git” model where we work directly with forks of upstream projects.
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 integration
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:
Deploy Forgejo in staging and provide Packit with a service account
Collect feedback from maintainers on real workflows.
Reach feature parity with GitHub and GitLab support.
The long-term goal is clear. Packit in Forgejo should feel natural and seamless, not bolted on.
Konflux Integration
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.
Building a Compatibility Bridge
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:
A metaservice that translates Pagure-style API calls into Forgejo’s API
New artifact storage, currently in the Lookaside Cache
A phased rollout: first internal scripts, then external tools, and finally contributor-facing workflows
Incremental testing in staging before production cutovers
The goal is continuity. Contributors should be able to keep working while the infrastructure gradually changes behind the scenes.
Tooling Compatibility
Fedora’s ecosystem depends on many tools that integrate with dist-git. Each needs some level of adjustment.
Bodhi will need to adapt to the new repository metadata.
COPR will need changes to fetch SRPMs directly from Forgejo
Packit integration is a priority and is being developed in parallel.
Fedpkg and release engineering scripts will be updated first since they are under Fedora control.
CI systems, Anitya, Toddlers, Notifications, Monitor Gating, and others will need targeted updates to remove assumptions about Pagure.
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.
What is Next
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:
Have runners and actions in production
Move about 80% of non-source projects to forge.fp.o
Nice to have:
Some outcomes from Package ownership and Artifact storage discussions
Staging deployment of Forgejo, let’s temporarily call it “packagers’ forge”
Staging environments for Packit and Actions of the packagers’ forge deployment
Roadmaps for Konflux and the compatibility bridge
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.
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
Infrastructure & Release Engineering
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
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.
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.
What we have and how to use it
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.
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.
What’s next?
Transition to the new Packit-based CI as the default mechanism, replacing Fedora CI.
This transition will require addressing several technical challenges:
Deploying the Packit Fedora CI code within the Fedora infrastructure
Switching Packit Fedora CI to be run on all other Fedora packages
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!
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!
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
Infrastructure & Release Engineering
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
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.
The current Bugzilla process
If you want a package that is not available in Fedora repositories yet, the process looks something like:
Package Recipe: start by writing a .spec file, which declares your package sources and instructions on building it.
Build: the same specfile is then used to build a Source RPM.
Upload: upload the Source RPM and specfile to a file host or a place like fedorapeople.
New Ticket: Now, start a new bugzilla ticket with the SRPM url and Spec url along with the description of the package.
Fedora-review-service: This service builds your package in COPR from the provided SRPM and specfile URL, runs fedora-review after a successful build to report compliance.
Review Cycle: A reviewer comes along, provides feedback, make changes, upload again. This creates a tedious, repetitive cycle for every minor change.
This process isn’t reliable, it forces developers to constantly juggle multiple tools and tabs. This creates a fragmented and disjointed experience.
The new process
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:
Fork the central package review repository on forgejo.
Commit your .spec files and patches.
Start a new Pull Request.
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:
One can navigate to the error logs by going through the details link.
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.
Automatic Build: The service clones your changes into a COPR build environment and builds the package.
Direct Feedback: After a successful build, the fedora-review tool runs, and its formatted output is posted directly as a comment in the pull request discussion.
Testing: The service runs installability and rpmlint checks using Testing Farm.
Commit Status Updates: The status of the COPR build and all tests is reported back directly to the pull request via commit statuses (the green checkmarks or red crosses).
If a change is needed, one can just push a new commit and the service takes care of building and testing now.
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.
This week in the Fedora project, we did some small changes to the details and reporting of information in the service.
Small Changes
Better Review Comments
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.
Clearer Status Reporting
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.
Testing
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.
What’s Next?
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:
Deploying the service
Writing setup instructions for local development
Setting up the bot account
Completing the work needed for merging the relevant code upstream
I’m grateful to my mentor, František Lachman, for his constant support and guidance.
This week in the project, we covered the changes on how we handle the pull request to make it a more intuitive process.
No config? No problem!
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.
Small troubles
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.
What’s Next?
With these core features now in place, my focus for the upcoming weeks will be on two main tasks:
Documentation: I’ll be writing documentation for the service, covering its usage for end-users and development guidelines for future contributors.
Upstreaming Code: The final step is to contribute the Forgejo integration code back to the upstream OGR and packit-service projects so the wider community can benefit from the forgejo integration, still in progress.
This week in the project, we added the support for status reporting of the package actions via commit statuses.
Feedback and Commit status
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.
What’s Next?
With this feature in place, my next steps will be:
Project Demonstration: Prepare a comprehensive demo to showcase the concept and the new workflow.
Code Refinement: Continue with bug fixes and code refactoring to improve the maintainability of the service. Primarily, downsizing from the original packit-worker code for the parts where we don’t need the integrations of services not involved in this project.
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
Infrastructure & Release Engineering
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
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.
Next Steps
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.
Fedora Project Policy on AI-Assisted Contributions
Our Philosophy: AI as a Tool to Advance Free Software
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.
1. AI-Assisted Project Contributions
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.
You are responsible for your contributions. AI-generated content must be treated as a suggestion, not as final code or text. It is your responsibility to review, test, and understand everything you submit. Submitting unverified or low-quality machine-generated content (sometimes called “AI slop”) creates an unfair review burden on the community and is not an acceptable contribution.
Be transparent about your use of AI. When a contribution has been significantly assisted by an AI tool, we encourage you to note this in your pull request description, commit message, or wherever authorship is normally indicated for the work. For instance, use a commit message trailer like Assisted-by: <name of code assistant>. This transparency helps the community develop best practices and understand the role of these new tools.
Fedora values Your Voice. Clear, concise, and authentic communication is our goal. Using AI tools to translate your thoughts or overcome language barriers is a welcome and encouraged practice, but keep in mind, we value your unique voice and perspective.
Limit AI Tools for Reviewing. As with creating code, documentation, and other contributions, reviewers may use AI tools to assist in providing feedback, but not to wholly automate the review process. Particularly, AI should not make the final determination on whether a contribution is accepted or not.
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.
3. AI Tools for Fedora Users
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.
AI features MUST be opt-in. Any user-facing AI assistant, especially one that sends data to a remote service, must not be enabled by default and requires explicit, informed consent from the user.
We SHOULD explore AI for accessibility. We actively encourage exploring the use of AI/ML tools for accessibility improvements, such as for translation, transcription, and text-to-speech.
3. Fedora as a Platform for AI Development
One of our key goals is to make Fedora the destination for Linux platform innovation, including for AI.
Package AI tools and frameworks. We encourage the packaging of tools and frameworks needed for AI research and development in Fedora, provided they comply with all existing Fedora Packaging and Licensing guidelines.
4. Use of Fedora Project Data
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.
Aggressive scraping is prohibited. Scraping data in a way that causes a significant load on Fedora Infrastructure is not allowed. Please contact the Fedora Infrastructure team to arrange for efficient data access.
Honor our licenses. When using Fedora project data to train a model, we expect that any use of this data honors the principles of attribution and sharing inherent in those licenses.
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!
Fedora Mentor Summit (FMS)
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:
Kayode Xoxo – Local testing of Fedora packages intern
These projects highlight Fedora’s commitment to mentorship and building new contributor pathways.
Fedora Social Calls
In July 2025, the DEI team kicked off Fedora Social Calls, casual hangouts to connect beyond project work.
Held thrice so far, with plans to run monthly
Led by Cornelius Emase
We’d love to see you at the next one! Our last calls had a smaller turnout, but these gatherings are all about having fun, don’t miss the next one this September
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.
Event DEI Location Policy
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.
Looking ahead to Q4 2025
Stay tuned for updates on upcoming social calls, ongoing mentorship, and preparations for 2026 DEI activities.
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.
Using the image-template repository
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
Using Fedora Bootc 42 as base image
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.
Since I want to keep my OS minimal I am not installing weak dependencies.
Installing Caddy
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
Configuring Caddy
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
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
Building the bootable container
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
Building a Disk Image
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.
Running the Web Server
To run the server we can use any virtualization software. In this case I am using virt-install:
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.
Summary
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.
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.
Updating using the terminal
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.
How to revert
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:
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
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
Infrastructure & Release Engineering
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
This guide provides a step-by-step walk-through for integrating a uTrust FIDO2 security key (Identiv uTrust) with Fedora 42 to secure:
LUKS2 full disk encryption (FDE)
Graphical login (LightDM + Cinnamon)
Sudo elevation
Audience for this article
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.
Background
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.
System Overview
The following hardware/software is used in this implementation:
Hardware and Software:
Architecture: x86_64
CPU: Intel Core i7
Kernel: 6.14.9-300.fc42.x86_64
Fedora Version: Fedora 42 (Adams)
Desktop Environment: Cinnamon with LightDM
FIDO2 Key: Identiv uTrust FIDO2
Vendor/Product:
0x04e6:0x5a11
Protocol: CTAP2 / FIDO_2_0
PIN: Required
User Presence: Touch required
User Verification: PIN only (no biometrics)
Device Path:
/dev/hidraw0
Disk Setup
Btrfs on LUKS2 FDE (
/dev/sda3
)
LUKS UUID:
8b2f0322-f508-4bed-8b1e-8f05cc784d60
(this will differ on each machine)
Keyslots:
0: Passphrase (argon2id)
1: FIDO2 credential (note: in testing, only one FIDO2 key could be used at a time)
Process Flow Overview
The following phases occur during implementation:
System preparation — Install Fedora 42 with LUKS2 full-disk encryption and update packages.
Package installation — Add the development, PAM, and FIDO2 tools required for integration.
FIDO2 key enrollment — Register the key with LUKS2 for disk unlock.
PAM configuration — Enable FIDO2 authentication for login and sudo.
Polkit configuration (optional) — Extend FIDO2 support to graphical privilege prompts.
Testing and verification — Confirm PIN + Touch authentication at boot, login, and sudo elevation.
Implementation Guide
Phase 1: System Preparation
Create a clean install of Fedora 42 with Cinnamon + LightDM
During installation/partitioning configure the following:
LUKS2 Full Disk Encryption (Btrfs or ext4)
No separate /home
No auto-login
Create an admin user
Update the system: sudo dnf upgrade --refresh -y
Phase 2: Required Package Installation
Install required development and security packages:
Enable and start the PC/SC daemon for smartcard support:
sudo systemctl enable --now pcscd
Phase 3: FIDO2 Key Setup
Insert the FIDO2 key and verify it is detected: lsusb fido2-token -L fido2-token -I /dev/hidraw0 Expected output is: Identiv uTrust FIDO2 (0x04e6:0x5a11) with options rk, clientPin.
Troubleshooting considerations if the key isn’t recognized:
Ensure /dev/hidraw0 exists
Run the following to load kernel modules: sudo modprobe hid sudo modprobe hid_generic
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.
Phase 6: Testing
Reboot the system
Boot screen asking for LUKS2 token PIN.
Confirm functionality
The following sequence of images shows the following:
FDE (LUKS Unlock): PIN + Touch prompt appears at boot
GUI Login (LightDM): PIN + Touch required
Sudo: sudo echo test should prompt for PIN + Touch
Polkit: GUI software install or pkexec prompts for PIN + Touch
FDE (LUKS Unlock): PIN + Touch prompt appears at boot FIDO2 key lit up, waiting for touch to complete full-disk unlock.GUI login PIN Fedora LightDM login screen prompting for FIDO2 key PIN.GUI login key touch Login process with FIDO2 key lit up, requiring touch to proceed.GUI login completion Login screen showing successful authentication, ready to “Log In.”Sudo escalation (terminal) Example of sudo test requiring PIN + touch in terminal.Locked screen where the user may need to click the person icon to switch back to FIDO2 login.
Confirm the fallback password login remains functional
Locked screen PIN entry Re-login screen asking for FIDO2 key PIN to unlock session.
Recovery and Backup
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:
Use a high-entropy admin password
Store the password securely off-line or in encrypted container
Troubleshooting
Multiple FIDO2 Keys:
lsusb
sudo usbreset /dev/bus/usb/001/003
Warnings
Never test on production systems
Back up /etc/crypttab and /etc/pam.d/*
Avoid running dracut --force unless ready
Security Notes
Strengths:
Hardware-backed auth
PIN + Touch = Strong 2FA
Risks:
Loss of key
System updates may break compatibility
Recommendations:
Always keep a fall-back passphrase
Register a backup FIDO2 key
Back up /etc/u2f_mappings and test after upgrades
Performance Considerations
Component
Delay Added
Boot (FDE)
~5–10 seconds
GUI Login
~2–3 seconds
Sudo/Polkit
~1–2 seconds
Conclusion
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.
We are thrilled to announce the soft launch of Fedora Forge, our new home for Fedora Project subprojects and Special Interest Groups (SIGs)! This marks a significant step forward in modernizing our development and collaboration tools, providing a powerful platform built on Forgejo. For more background on why we chose Forgejo, see the previous community blog post.
A New Home for Fedora Collaboration
We designed Fedora Forge as a dedicated space for official Fedora Project work. Unlike pagure.io, which hosted personal projects alongside Fedora Project work, we focus on supporting subprojects and SIGs. This structured approach streamlines our efforts and simplifies contribution to official Fedora teams.
We are migrating projects from select teams, including: Release Engineering (RelEng), Council, and Fedora Engineering Steering Committee (FESCo). This phase-based approach lets us test the platform thoroughly before opening it to more subprojects and SIGs.
However, If you are a leader of a team or SIG and would like to request a new organization or team on Fedora Forge, please see our Requesting a New Organization and/or Team guide for detailed instructions.
Seamless Migration with Pagure Migrator
The Pagure Migrator is a key part of this launch. We developed and upstreamed this new Forgejo feature to ensure smooth transitions. This utility moves projects from Pagure-based Git forges seamlessly. It brings over historical data like pull requests, issue tickets, topics, labels, and users. As subprojects and SIGs move over, their valuable history and ongoing work come with them. This ensures continuity and a painless transition for contributors.
Get Ready for What’s Next!
This soft launch is just the beginning. As we test the waters by settling these first subprojects and SIGs on Fedora Forge, we will be preparing to open it up in the coming weeks. We are confident that Fedora Forge will become an invaluable tool for the community, providing a robust and modern platform for collaboration.
complyctl is a powerful command-line utility implementing the principles of “ComplianceAsCode” (CaC) with high scalability and adaptability for security compliance.
In today’s rapidly evolving digital landscape, maintaining a robust security posture isn’t just a best practice – it is a necessity. For Fedora users, system administrators, and developers, ensuring that your systems meet various security and regulatory requirements can often feel like a daunting, manual task. But what if you could standardize and automate much of this process, making compliance checks faster, easier to audit, and seamlessly integrated into your workflows?
This is now a reality enabled with multiple ComplyTime projects. These focus on specific tasks designed to be easily integrated. They allow a robust, flexible, and scalable combination of microservices communicating with standardized formats that ultimately allow a powerful capability to much more easily adapt to the compliance demands. This also allow faster adoption of new technologies. There are multiple exciting projects actively and quickly evolving under the umbrella of ComplyTime organization. In this article I would like to highlight complyctl, the ComplyTime CLI for Fedora, and its main features that make it an excellent option to easily maintain a robust security posture in your Fedora systems.
complyctl is a powerful command-line utility available since Fedora 42. It’s design uses the principles of “ComplianceAsCode” (CaC) with high scalability and adaptability. It contains a technology agnostic core and is easily extended with plugins. This allows users to use the best of every available underlying technology with a simple and standardized user interface.
The Power of ComplianceAsCode with complyctl
At its heart, complyctl is a tool for performing compliance assessment activities, scaled by a flexible plugin system that allows users to perform compliance check activities with a flexible combination of the best available assessment technologies.
The complyclt plugin architecture allows quick adoption and combination of different scanner technologies. The core design is technology agnostic with standardizing inputs and outputs using machine readable formats that allow high reusability and shareability of compliance artifacts. Currently it leverages the Open Security Controls Assessment Language (OSCAL) and its anti-fragile architecture also allows a smooth adoption of future standards, making it a reliable and continuous modern solution for the long-term.
This might sound technical, but the benefits are simple:
Automation and Speed: Traditional compliance audits can be slow, manual, complex and prone to human error. complyctl relies on standardized machine readable formats, allowing automation without technology or vendor lock-in.
Accuracy and Consistency: Machines are inherently more consistent than human reviewers. complyctl’s reliance on OSCAL provides a standardized format for expressing security controls, assessment plans, and results. This standardization is crucial for interoperability. It allows consistent processing and understanding of compliance data across different tools and systems.
Scalability and Integration:complyctl simplifies compliance checks integration in your development and deployment pipelines. An OSCAL Assessment Plan can be created and customized once and reused across multiple systems. Ultimately compliance checks can be implemented faster and compliance gaps are caught earlier. This prevents non-compliant configurations from reaching production environments.
Extensibility with Plugins (including OpenSCAP): The plugin-based architecture of complyctl makes it incredibly versatile. An example is the complyctl-openscap-plugin, which extends complyctl’s capabilities to use OpenSCAP Scanner and the rich content provided by scap-security-guide package. This allows an immediate and smooth adoption of complyctl using a well-established assessment engine while providing a modern, OSCAL-driven workflow for managing and executing security compliance checks. It also allows a smooth and gradual transition to other scanner technologies.
By embracing complyctl, Fedora users can more easily maintain a strong security posture.
Getting Started with complyctl: A Practical Tutorial
Ready to put complyctl to work? It is likely simpler than you expect. The following is a step-by-step guide to start using complyctl on your Fedora system.
plan: Create an OSCAL Assessment Plan based on a chosen framework. This plan acts as your assessment configuration.
generate: Generate executable policy artifacts for each installed plugin based on the OSCAL Assessment Plan.
scan: Call the installed plugins to scan the system using their respective policies and finally aggregate the results in a single OSCAL Assessment Results file.
Let’s walk through these commands.
3. Step-by-Step Tutorial
Step 1: List Available Frameworks
To begin, you need to know which compliance frameworks complyctl can assess your system against. Currently the complyctl package includes the CUSP Profile out-of-the-box.
Use the list command to show the available frameworks:
complyctl list
This command will output a table, showing the available frameworks. Look for the Framework ID column, as you’ll need this for the next step.
Example:
Optionally, you can also include the --plain option for simplified output.
Step 2: Create an Assessment Plan
Once you’ve identified a Framework ID, you can create an OSCAL Assessment Plan. This plan defines what will be assessed. The plan command will generate an assessment-plan.json file in the complytime directory.
complyctl plan cusp_fedora
This command creates the user workspace in the “complytime” directory:
tree complytime
complytime/
└── assessment-plan.json
The JSON file is a machine-readable representation of your chosen compliance policy.
Step 3: Install a plugin
In this tutorial we will use OpenSCAP Scanner as the underlying technology for compliance checks. So, we also want to install the OpenSCAP plugin for complyctl as well the OpenSCAP content delivered by scap-security-guide package:
With your assessment-plan.json in place, and the desired plugins installed, the generate command translates this declarative plan into policy artifacts for the installed plugins. These are the actual plugin specific instructions complyctl plugins will use to perform the checks.
complyctl generate
This command prepares the assessment for execution.
Finally, the scan command runs the assessment using the installed plugins. The results will appear in the assessment-results.json, file by default.
complyctl scan
For human-readable output, which is useful for review and reporting, you can add the --with-md option. This will generate both assessment-results.json and assessment-results.md files.
complyctl scan --with-md
This Markdown file provides a clear, digestible summary of your system’s compliance status, making it easy to share with auditors or other stakeholders.
If you find an issue or have a feature request, please open an issue, propose a PR, or contact the maintainers. Your feedback will help shape the future of this tool.
On Tuesday, 16 September 2025, it is our pleasure to announce the availability of Fedora Linux 43 Beta! This release comes packed with the latest version upgrades of existing features, plus a few new ones too. As with every beta release, this is your opportunity to test out the upcoming Fedora Linux release and give some feedback to help us fine tune F43 final. We hope you enjoy this latest version of Fedora!
How to get the beta release
You can download F43 Beta, or our pre-release edition versions, from any of the following places:
The Fedora CoreOS “next” stream moves to the beta release one week later, but content for F43 is still available from their current branched stream to enjoy now.
You can also update an existing system to the beta using DNF system-upgrade.
The F43 Beta release content is also available for Fedora Spins and Labs, with the exception of the following:
Mate – not currently available on any architectures with F43 content
i3 – not currently available on aarch64 only with F43 content
F43 Beta highlights
Installer and desktop Improvements
Anaconda WebUI for Fedora Spins by default: This creates a consistent and modern installation experience across all Fedora desktop variants. It brings us closer to eventually replacing the older GTK installer. This ensures all Fedora users can benefit from the same polished and user-friendly interface.
Switch Anaconda installer to DNF5: This change provides better support and debugging for package-based applications within Anaconda. It is a bigger step towards the eventual deprecation or removal of DNF4, which is now in maintenance mode.
Enable auto-updates by default in Fedora Kinoite: This change ensures that users are consistently running a system with the latest bug fixes and features after a simple reboot. Updates are applied automatically in the background.
Set Default Monospace Fallback Font: This change ensures that when a specified monospace font is missing, a consistent fallback font is used. Font selection also remains stable and predictable, even when the user installs new font packages. No jarring font changes should occur as appeared in previous versions.
System enhancements
GNU Toolchain Update: The updates to the GNU Toolchain ensures Fedora stays current with the latest features, improvements, and bug and security fixes from the upstream gcc, glibc, binutils, and gdb projects. They guarantees a working system compiler, assembler, static and dynamic linker, core language runtimes, and debugger.
Package-specific RPM Macros For Build Flags: This change provides a consistent and standard way for packages to add to the default list of compiler flags. It also offers a cleaner and simpler method for package maintainers to make per-package adjustments to build flags. This avoids the need to manually edit and re-export environmental variables, and prevents potential issues that could arise from the old manual method. It ensures the consistent applications of flag adjustments.
Build Fedora CoreOS using Containerfile: This change brings the FCOS build process under a standard container image build, moving away from the custom tool, CoreOS Assembler. It also means that anyone with Podman installed can build FCOS. This simplifies the process for both individual users and automated pipelines.
Upgrades and removals
Deprecate The Gold Linker: Deprecate the binutils-gold subpackage. This change simplifies the developer experience by reducing the number of available linkers from four to three. It streamlines choices for projects, and moves towards safeguarding the project against potential issues from “bitrot” where a package’s quality can decline and become unbuildable or insecure over time.
Retire python-nose: The python-nose package will be removed in F43. This prevents the creation of new packages with a dependency on an unmaintained test runner. Developers are encouraged to migrate to actively maintained testing frameworks such as python3-pytest or python3-nose2.
Retire gtk3-rs, gtk-rs-core v0.18, and gtk4-rs v0.7: This change prevents Fedora from continuing to depend on old, unmaintained versions of these bindings. It also prevents shipping obsolete software and fewer unmaintained versions of packages.
Python 3.14: Updating the Python stack in F43. This means that by building Fedora packages against an in-development version, critical bugs can be identified and reported before the final 3.14.0 release. This helps the entire Python ecosystem. Developers also gain access to the latest features in this release. More information is available at https://docs.python.org/3.14/whatsnew/3.14.html.
Golang 1.25: This change provides Fedora Linux 43 Beta with the latest new features in Go. These include that go build -asan now defaults to leak detection at program exit, the go doc -http option starts a documentation server, and subdirectories of a repository can now be used as a module root. Since Fedora will keep as close to upstream as possible, this means we will continue to provide a reliable development platform for the Go language and projects written in it.
Idris 2: Users gain access to new features in Idris 2. These include Quantitative Type Theory (QTT), which enables type-safe concurrent programming and fine-grained control over resource usage. It also has a new core language, a more minimal prelude library, and a new target to compile to, Chez Scheme.
More information
Details and more information on the many great changes landing in Fedora Linux 43 are available on the Change Set page.
And just like that, the Fedora 43 Wallpaper has been finalized!
I recently attended Flock (for the first time ) at the beginning of the summer. I had the privilege of facilitating a workshop with Emma Kidney about getting started in the Fedora Design Team. You can read Emma’s workshop recap here if you didn’t get the opportunity to attend! Participants helped create inspiration for the F44 wallpaper.
Now that it’s the end of the summer, I thought it might be a good time to discuss the F43 wallpaper process.
The final F43 Day WallpaperThe final F43 Night Wallpaper
Let’s rewind to the start
If you’re not a blog post person, then you can always see the process documented on the F43 ticket here.
The first step involves a list of people or topics in STEM that the community can vote on. We were choosing between people whose last name starts with R, since we’ve followed the alphabet for the past 18 wallpapers.
Jess Chitas wrote on the ticket, “Thinking of ones that would make really nice wallpapers- Vera Rubin was an Astronomer who worked on galaxy rotation rates. Rooting for this one myself, a galaxy wallpaper would be epic! Wilhelm Röntgen essentially discovered the X-ray. Something with the skeleton could be cool? Henry Augustus Rowland worked with diffraction gratings (lots of colour!!)
Vera Rubin and Wilhelm Röntgen made it into the poll (which can be found here on Fedora discussions), but Sally Ride ultimately won!
Sally Ride
“Everywhere I go I meet girls and boys who want to be astronauts and explore space, or they love the ocean and want to be oceanographers, or they love animals and want to be zoologists, or they love designing things and want to be engineers. I want to see those same stars in their eyes in 10 years and know they are on their way.“- Sally Ride
Sally Ride (May 26, 1951 – July 23, 2012) was a physicist and astronaut who became the first American woman in space on June 18, 1983. The third woman ever!
After finishing her training at NASA, she served as the ground-based CapCom for the second and third Space Shuttle flights. She helped develop the Space Shuttle’s robotic arm, which helped her get a spot on the STS-7 mission in June 1983.
Two communication satellites were deployed, including the first Shuttle pallet satellite. Ride operated the robotic arm to deploy and retrieve SPAS-1, which carried ten experiments to study the formation of metal alloys in microgravity.
Mind Map
The mind map we created together in a design team meeting.
Based on Ride’s career, we started gathering images. We looked up the books she had worked on that had exclusive photographs of her missions. Her work in education and STEM made us think of the infographic posters that usually hang in classrooms. Ride’s mission happened in the 80s, which is technically too late to classify as mid-century. However, the bright, colorful mid-century space art and retro futurism felt perfectly suited to represent her optimism and approach to learning in STEM.
Sketches
I usually do quick sketches on paper or my iPad and came up with these three options. The first one isn’t a wallpaper, so much as a blueprint for an exploring spacecraft. More realistic vs ones with exaggerated shapes for children’s books. I was much happier with the second and third compositions. That’s why we always push to come up with multiple ideas, because it’s like working a muscle. The design muscle!
People commented on the ticket that we could go forward with sketch 2 or sketch 3. I brought sketch 2 into Krita and started drawing over it on a new layer. I wanted to map out how the clouds would billow out and where stars could be.
Rough and Final Drafts
At this point, I received feedback from people on the Fedora Design team. It was suggested to bring the clouds on the right down a little and perhaps add a moon in the sky. The color and arch of the sunrise and sunset were also things we discussed in our weekly team meeting (open to community members ), and I believe they turned out pretty great.
Post F43 Thoughts
Without the community, these wallpapers wouldn’t happen! If you’re a passionate artist or designer, you’re more than welcome to participate in this recurring project.
Over the past few Fedora releases, the Anaconda team has been gradually replacing the GTK-based installer with a new web-based interface. As this work expands, we want to share a quick update on the current status, where things are headed, and how to stay involved.
Current Status
The WebUI was introduced in Fedora 42 Workstation Live ISO as the default installer, supporting Live image installations only. DNF-based installs are not yet supported, this is planned for a future phase.
A change proposal for Fedora 43 has been approved, enabling the WebUI by default for all Fedora Spins and KDE.
Community testing has already taken place, and we’ve received an incredible amount of useful feedback. Thank you to everyone who participated and helped us shape the experience! We are now actively reviewing and processing that feedback to guide the next phases of development.
Below is an example of the WebUI installer in action, as currently used in one of the Fedora Spins.
Documentation Update
The existing Fedora Installation Guide is outdated and no longer reflects the current installer. Our team is open to co-owning updated installer documentation and hosting it upstream to keep it accurate and maintainable.
To reduce the documentation overhead, we’re working on autogenerated docs directly from the source code. While this is still early work, we have a small but up-to-date example live now: Web UI Installer documentation
Here’s a rough view of how we plan to roll out the WebUI across Fedora editions:
Fedora Version
Status/Target
Fedora 42
Workstation Live ISO (WebUI available)
Fedora 43
Spins + KDE (approved)
Fedora 44
uBlue, Atomic Desktops, Remote Browser
Fedora 45
Server Edition
After 45
Deprecation of GTK UI
Get Involved
We’re open to contributions across all areas of the project – from design suggestions, to feature development, testing, and documentation. If you’re interested in helping out or learning more, join us in the #anaconda:fedora.im Matrix channel. We’d be happy to talk!
The i18n team is testing changes for Fedora Linux 43 (Use COLR for Noto Color Emoji, Set Default Monospace Fallback Font , and many more). As a result, the i18n and QA teams organized a test week to run from Tuesday, September 09, 2025, to Monday, September 15, 2025. The wiki page in this article contains links to the test images you’ll need to participate. Please continue reading for details.
How does a test week work?
A test week is an event where anyone can help ensure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.
To contribute, you only need to be able to do the following things:
Download test materials, which include some large files
Read and follow directions step by step
The wiki page for the i18n test week is your source of information on what and how to test. After you’ve done some testing, you can log your results in the test week web application. If you’re available on or around the days of the event, please do some testing and report your results.
Happy testing, and we hope to see you on one of the test days.
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: 1st – 5th September 2025
Infrastructure & Release Engineering
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
Fedora documentation has been perceived as a weak point for years. But in reality, the situation is very mixed. I would like to briefly describe the current situation and how we got there. Based on this experience, I will present 5 theses about how Fedora Docs can be improved in the long term.
The current situation
The project is ‘dormant’ to say the best, showing all the signs of a deteriorated community and a ‘dead’ project.
The team is dissolved with no consistent organization.
Documentation has broken down into an active and maintained part, which is managed by the editions (mostly installation instructions), and a non-edition-specific part, which is largely obsolete with a few highlights maintained by groups with a special interest.
There is a long list of unprocessed MRs, but no plan for improvement.
At the same time, the situation is better than it was about 4 years ago, when our documentation consisted of a completely outdated “Installation Guide” and an equally outdated “Administration Guide,” whose instructions were insufficient for installing any of our distribution media or performing any administrative tasks. We now have a strong documentation at least for some Editions, but huge shortcomings in Edition agnostic areas, specifically Administration topics.
This situation is quite unsatisfactory. And it has negative consequences for Fedora as a whole. Our distribution is considered “difficult” to use, at least in part due to missing or even misleading long outdated documentation. Other distributions are more attractive and are considered „easy“ and „quick“ to use. They are gaining users and thus also potential contributors, which Fedora is losing.
An example of this effect is ArchLinux, whose documentation is considered excellent and exemplary and – among others – a recommendation to choose it.
In the end, the documentation malaise contributes to the fact, that the outstanding engineering results achieved through the great personal commitment of many Fedora contributors do not receive the attention and impact they deserve.
A brief look back – a roller coaster ride
To investigate possible causes, it is helpful to briefly recall how this situation developed.
At the beginning, i.e., during the first about 10 releases, we saw strong development in the area of Fedora documentation. At its peak, it consisted of a wide range of documentation on topics of varying scope. From a broad Administration Guide to specialized documentation on specific topics such as Grub or setting up a home server, everything was included.
After the initial enthusiasm and appeal of something new, a period of decline began: A gradual decrease in the number of participants, meetings becoming increasingly rare over time due to a lack of participants, and eventually no longer taking place at all; loss of focus; loss of organization, goals, and planning. And with each new release, the amount of documentation decreased. At the time, the technology, DocBook and Publican, was identified as the root cause of the problem. It was then replaced by another technology – Antorra and the Git workflow.
Once again, there was a brief resurgence of interest due to the appeal of something new. A large amount of the existing documentation was migrated, partly manually and partly automatically. Once the technical part was done, things started to slow down again, and in the end, only Petr remained as a “lone warrior” with a completely outdated installation guide and an equally outdated administration guide.
The revitalization in 2022 initiated by Ben, initially brought a strong upswing, not so much in the number of active contributors but above all in the continuous work of an active core group on a defined and “focusable” task. There were different sub-areas that could be worked on by different contributors and produced a common result. And a new problem was raised: a high hurdle for authors due to the Git workflow. This is familiar to “technicians”, but who write rarely documentation, and is a hurdle for authors and users who like to write but are hindered by unfamiliar tooling. And just another change in technology was brought into play: the wiki.
Then, in 2023, it all came crashing down again, this time because two key members had to leave and we had no one to replace them. Another downturn began. Various initiatives involving online workshops were unable to stop this.
Since mid-2024, the Docs Team has once again become a dormant entity. There is no focused planning or goals setting at all. Instead, once again, a switch to a different technology came up: the documentation plugin of the discussion forum .
Afterall, we’re stuck in a slump again. Not quite as bad as around 2020, but you can feel it everywhere. At the moment, the current curation does not make the dire situation quite so blatantly obvious. However, with each new release, the shortcomings of generic, edition-independent documentation become increasingly apparent and urgent, particularly the Quick Docs and, above all, the Administrator’s Guide.
How to improve – the essential requirements
1. A change in technology is not a solution
Fedora has repeatedly discussed and implemented technical solutions or changes to resolve the Docs issues. However, the actual cause were not technical problems, but rather a gradual decline in the communities, recognizable by the typical symptoms mentioned above.
A technological change is more likely to destroy a community or accelerate a decline that is already taking place. It ends up uncovering new usage problems that don’t reduce the original problem but further hinder a solution.
Instead, it is beneficial to adapt the technology to the needs and existing skills in the community.
2. Extraordinary strong community building essentially required
The solution to Doc’s predicament is to build a strong community (or several communities) and put serious, extraordinary effort into it to make them viable and sustainable right from the start. In retrospect, this was the fatal flaw of Ben’s otherwise very successful 2022 initiative. We started with too few resources and focused too early on documentation work.
Any Docs community requires special efforts to be sustained. A community focused on a technical product has a quasi-natural long-term focus. In a Docs community, this focus is highly volatile. It requires members who continuously maintain communication, actively involve new members, recognize and seize opportunities to initiate communication within the team and with other teams, as well as continuously propose projects and goals that provide a focus for several different skills and members.
Such extensive and continuous community work is a prerequisite for effective documentation, alongside the actual documentation tasks. In the best case scenario, this happens automatically, with someone naturally stepping forward to take on this tasks. Otherwise, it is something that needs to be specifically considered and promoted when building a Docs team.
3. Self-contained short “Instructions” instead of monolithic “Guides”
Monolithic guides require considerable time and commitment. An author has to familiarise themselves not only with the chapter in question, but also with the documentary context. Follow-up work in subsequent or preceding sections may also be necessary to maintain over all consistency of content. This is an unavoidable consequence of the inherent structure and nature of extensive monolithic text bodies.
This peculiarity is problematic for a group of volunteer authors consisting mainly of regular users. Changes in membership are a regular occurrence in open source projects. Replacing or adding an author in a team writing and maintaining a monolithic text body is difficult and time-consuming, resulting in additional barriers. At the end it makes successful and productive work highly volatile.
However, it’s not just a matter of community, but also of usability and quality assurance. Shorter and thematically focused texts enable users to achieve success more quickly. The text may optionally provide links to broader information for those who want to acquire deeper knowledge. And updates due to changes in the software are easier and require less effort and quicker to accomplish and thus enable their timeliness.
4. Upstream first
The objective of Fedora documentation are the Fedora specific implementations and regulations, and how to accomplish a specific task, or use a specific software, in the Fedora runtime environment. This is an area where users and maintainers can excel. And this is where they are the experts.
Upstream projects usually provide general, distribution-agnostic documentation themselves. And there are numerous books and general information sites on specific software or Linux technologies. It makes no sense and is unnecessary effort to duplicate this documentation. The frequently referred to ArchLinux documentation is not a model to follow. Infact, it is in large parts a curation of various upstream documentations, compiled in one place and therefore the advantage of being easy to find..
The gap is applying this general info to your specific situation and Fedora distribution. And sometimes, finding this general info in an accurate, up-to-date, and readable version. A consistent quality feature of every Fedora documentation article is therefore its focus on the use case in Fedora and valuable links to upstream and more general documentation.
5. Bridging the gap between „engineering“ and „writing“
In Fedora, packaging and documentation are two completely different areas that do not interact or communicate in a systematic way. Although every “engineer” is quick to assure you that documentation is incredibly important, they are incredibly quick to disappear when it comes to contributing to it.
Vice versa, Fedora users are quick to post on our communication channels looking for solutions to problems or configuration suggestions for software. But they quickly disappear when it comes to making the solutions available to others.
At the end, writers get stuck because technical and/or valid usage informations are missing.
The documentation of the editions demonstrates an efficient alternative. Documentation is part of the scope of their Working Groups, thereby uniting technical and application/usage knowledge.
Of course, we cannot just apply this approach to all documentation. But it offers a promising strategy: Encourage and initiate communication between various experts – technicians, writers, users – but without introducing additional workload. The challenge is to create opportunities for such exchanges within the context of our existing Fedora Project activities. As an example, we could include an evaluation of the relevant documentation in the kernel test days. Or, we could dedicate one time slot on Flock to an exemplary technical area and its documentation. Implementing this strategy is without any doubt difficult and requires a high degree of innovative ideas, imagination and experimentation. And it will take some times.
Coda
The outlined strategy goes far beyond what can be achieved with a familiar SIG. A central coordinated initiative is needed to bring together several SIGs on a project-related basis. It also changes the tasks of the Docs team. Writing documentation is still part of the job, but a key focus is now on curating Fedora documentation and specifically initiating and instigating opportunities for exchange between different experts — in other words, community building.
We are excited to announce the general availability of the MetaSource (or MDAPI 4) in both the staging and productionFedora Infrastructure environments. The release includes an architectural rewrite of the MDAPI from Python to Go, making it a performant source of RPM repositories metadata as a REST service with 1:1 API compatibility. More details about the developments and acknowledgements are below.
MetaSource (or MDAPI v4.0.0) performs roughly 33% faster than MDAPI v3.1.7 while using about 30% lesser memory than that on sustained querying operations. This means that MetaSource would be able to address approx 50% additional requests without furthering resource consumption. Please note that the results may vary depending on unknown variables like network bandwidth and querying nature.
Concurrent querying
Services
Sample Duration
Total Count
Per request Duration
MDAPI MDAPI v3.1.7
500 seconds
148 requests
7.3615 seconds
MetaSource MDAPI v4.0.0
500 seconds
310 requests
3.5530 seconds
Services
Average Memory
Minimum Memory
Maximum Memory
MDAPI MDAPI v3.1.7
217.41 MiB 222,625 KiB
136.73 MiB 140,008 KiB
289.93 MiB 296,888 KiB
MetaSource MDAPI v4.0.0
187.02 MiB 191,510 KiB
130.68 MiB 133,816 KiB
257.44 MiB 263,624 KiB
MetaSource (or MDAPI v4.0.0) performs roughly 52% faster than MDAPI v3.1.7 while using about 14% lesser memory than that on concurrent querying operations. This means that MetaSource would be able to address approx 110% additional requests without furthering resource consumption. Please note that the results may vary depending on unknown variables like network bandwidth and querying nature.
You helped solidify the core for the Fedora 43 rebase!
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).
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!
You went above and beyond - Fedora Project would not be the same without you!
You visited the Fedora booth at TXLF 2025!
) at the beginning of the summer. I had the privilege of facilitating a workshop with Emma Kidney about getting started in the Fedora Design Team. You can read Emma’s workshop recap 
), and I believe they turned out pretty great.
You helped testing Fedora 45 i18n features
You helped testing Fedora 44 i18n features
You helped testing Fedora 43 i18n features
