We will be updating and rebooting various servers. Services will be up or down during the outage window.
We will be updating and rebooting various servers. Services will be up or down during the outage window.
admin )
on 2025-11-14 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 10th – 14th November 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 46 2025 appeared first on Fedora Community Blog.
admin )
on 2025-11-14 08:00:00 UTC
We did it again, Fedora at Kirinyaga university in Kenya. This time, we didn’t just introduce what open source is – we showed students how to participate and actually contribute in real time.
Many students had heard of open source before, but were not sure how to get started or where they could fit. We did it hands-on and began with a simple explanation of what open source is: people around the world working together to create tools, share knowledge, and support each other. Fedora is one of these communities. It is open, friendly, and built by different people with different skills.
We talked about the many ways someone can contribute, even without deep technical experience. Documentation, writing guides, design work, translation, testing software, and helping new contributors are all important roles in Fedora. Students learned that open source is not only for “experts.” It is also for learners. It is a place to grow.
After the introduction, we moved into a hands-on workshop. We opened Fedora Docs and explored how documentation is structured. Students learned how to find issues, read contribution instructions, and make changes step-by-step. We walked together through:
By the end of the workshop, students had created actual contributions that went to the Fedora project. This moment was important. It showed them that contributing is not something you wait to do “someday.” You can do it today.
“This weekend’s Open Source Event with Fedora, hosted by the Computer Society Of Kirinyaga, was truly inspiring! 
Through the guidance of Cornelius Emase, I was able to make my first pull request to the Fedora Project Docs – my first ever contribution to the open-source world. 
”
– Student at Kirinyaga University
Huge appreciation to:
And to everyone who played a part – even if your name isn’t listed here, I see you. You made this possible.
The students showed interest, curiosity, and energy. Many asked how they can continue contributing and how to connect with the wider Fedora community. I guided them to Fedora Docs, Matrix community chat rooms, and how they can be part of the Fedora local meetups here in Kenya.
We are introducing open source step-by-step in Kenya. There is a new generation of students who want to be part of global technology work. They want to learn, collaborate, and build. Our role is to open the door and walk together(I have a discourse post on this, you’re welcome to add your views).
This event is part of a growing movement to strengthen Fedora’s presence in Kenya. More events will follow so that learning and contributing can continue.
We believe that open source becomes strong when more people are included. Fedora is a place where students in Kenya can learn, grow, share, and contribute to something global.
We already had a Discourse thread running for this event – from the first announcement, planning, and budget proposal, all the way to the final workshop. Everything happened in the open. Students who attended have already shared reflections there, and anyone who wants to keep contributing or stay connected can join the conversation.
You can check the events photos submitted here on Google photos(sorry that’s not FOSS:))
Cornelius Emase,
Your Friend in Open Source(Open Source Freedom Fighter)
admin )
on 2025-11-12 13:18:27 UTC
Today, the Fedora Project begins the nomination period during which we accept nominations to the “steering bodies” of the following teams:
This period is open until Wednesday, 2025-11-26 at 23:59:59 UTC.
Candidates may self-nominate. If you nominate someone else, check with them first to ensure that they are willing to be nominated before submitting their name.
Nominees do not yet need to complete an interview. However, interviews are mandatory for all nominees. Nominees not having their interview ready by end of the Interview period (2025-12-03) will be disqualified and removed from the election. Nominees will submit questionnaire answers via a private Pagure issue after the nomination period closes on Wednesday, 2025-11-26. The F43 Election Wrangler (Justin Wheeler) will publish the interviews to the Community Blog before the start of the voting period on Friday, 2025-12-05.
The elected seats on FESCo are for a two-release term (approximately twelve months). For more information about FESCo, please visit the FESCo docs.
The full schedule of the elections is available on the Elections schedule. For more information about the elections, process see the Elections docs.
The post F43 election nominations now open appeared first on Fedora Community Blog.
admin )
on 2025-11-10 12:00:00 UTC
We have ongoing intermittent issues with the communication between the Fedora proxies and the backend services. This manifests as intermittent 502 / 503 errors when talking to services such as Koji, Src, and so on.
We are working with the networking team to track it down, see the Pagure ticket for …
admin )
on 2025-11-07 17:00:00 UTC
Many services at our main datacenter are down/unresponsive. There seems to be a networking event going on. We are working with networking to track down and mitigate things. Updates as they become available.
All services have been restored.
admin )
on 2025-11-07 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you with both an infographic and a text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in-depth details, look below the infographic.
Week: 03rd – 07th November 2025
The purpose of this team is to take care of day-to-day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces, etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 45, 2025 appeared first on Fedora Community Blog.
admin )
on 2025-11-07 08:00:00 UTC
The Fedora community is coming together once again to celebrate the release of Fedora Linux 43, and you’re invited! Join us on Friday, November 21, 2025, from 13:00 to 16:00 UTC on Matrix for our virtual Fedora 43 Release Party.
This is our chance to celebrate the latest release, hear from contributors across the project, and see what’s new in Fedora Workstation, KDE, Atomic Desktops, and more. Whether you’re a long-time Fedora user or new to the community, it’s the perfect way to connect with the broader community, learn more about Fedora, and hang out in Matrix chat with your Fedora friends.
We have a lineup of talks and updates from across the Fedora ecosystem, including updates directly from teams who have been working on changes in this release. We’ll kick things off with Fedora Project Leader Jef Spaleta and Fedora Community Architect Justin Wheeler, followed by sessions with community members like Timothée Ravier on Atomic Desktops, Peter Boy and Petr Bokoč on the new Fedora Docs initiative, and Neal Gompa and Michel Lind discussing the Wayland-only GNOME experience. You’ll also hear from teams across Fedora sharing insights, demos, and what’s next for the project.
Registration is free but required to join the Matrix event room. Once registered, you’ll receive an invitation in your Matrix account before the event begins.
Sign up on the Fedora Linux 43 Release Party event page. We can’t wait to see you there to come celebrate Fedora 43 with us!
admin )
on 2025-11-04 08:00:00 UTC
The official dates and location are set for Flock to Fedora 2026, the premier annual conference for Fedora Project contributors. The event will take place from 14-16 June 2026, in Prague, Czechia.
For Flock 2026, we are returning to the Vienna House by Wyndham Andel’s Prague, located at:
Stroupeznickeho 21
Prague, 150 00
Czech Republic
While all three days will be full conference days, the arrangement of the schedule will change slightly in 2026. Sunday, 14 June, will be designated as Day 0, featuring workshops, team meetups, and hands-on contributor sessions. The main conference activities, including streamed content, the opening keynote, and other sessions, are scheduled for Monday, 15 June, and Tuesday, 16 June.
Following community feedback from last year, Flock 2026 has been scheduled to align more closely with DevConf.CZ. The conference will conclude just before DevConf.CZ begins in Brno (18-20 June 2026). This compressed travel schedule is intended to make it easier for community members who wish to attend both events.
The Call for Proposals (CFP) for Flock 2026 will open in early December 2025 and close shortly after FOSDEM 2026 (31 January – 1 February). Speaker confirmations are scheduled to be sent in March 2026.
For Flock 2026, we are taking a more focused approach to session content. The Fedora Council, FESCo, and the Mindshare Committee are shaping key themes for the CFP. All presentation and workshop submissions should align with one of these themes. More details will be shared when the CFP opens.
Here is what you need to know to plan your attendance:
The official Flock to Fedora 2026 Matrix room, #flock:fedoraproject.org, is the best place to connect with organizers and other community members. We encourage you to join the channel for the latest updates and to ask any questions you may have.
We recognize that returning to the same city and venue for a second consecutive year is a departure from Flock’s tradition. This decision was made intentionally with two key goals in mind.
First, by working with a familiar venue, our organizing team can optimize its processes and plan further in advance. This stability for Flock to Fedora 2026 will give us more opportunity to improve our internal processes and explore new ways to incorporate community input into the design of Fedora’s flagship contributor conference.
Second, this allows us to plan for a significant change in 2027. The Flock organizing team is committed to exploring new locations for Flock 2027, with a particular focus on regions outside of North America and Europe. We acknowledge the travel difficulties many of our contributors in regions like LATAM and APAC face. We learned valuable lessons from past planning cycles and are eager to achieve this goal, while also recognizing that unforeseen circumstances can impact our plans. We will work with community members in these regions to explore possible options and conduct thorough research on pricing and availability for 2027.
We look forward to seeing you in Prague for Flock 2026, 14-16 June.
— The Flock to Fedora Planning Team
admin )
on 2025-10-31 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 27 October – 31 October 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 44 appeared first on Fedora Community Blog.
You helped solidify the core for the Fedora 43 rebase!
admin )
on 2025-10-28 13:56:28 UTC
Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to rebase to Fedora Linux 43 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.
Prior to actually doing the rebase to Fedora Linux 43, you should apply any pending updates. Enter the following in the terminal:
$ rpm-ostree update
or install updates through GNOME Software and reboot.
rpm-ostree is the underlying atomic technology that all the Fedora Atomic Desktops use. The techniques described here for Silverblue will apply to all of them with proper modifications for the appropriate desktop.
GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.
First thing to do is download the new image, so select the Download button. This will take some time. When it is done you will see that the update is ready to install.
Select the Restart & Upgrade button. This step will take only a few moments and the computer will restart when the update has completed. After the restart you will end up in a new and shiny release of Fedora Linux 43. Easy, isn’t it?
If you prefer to do everything in a terminal, then this part of the guide is for you.
Rebasing to Fedora Linux 43 using the terminal is easy. First, check if the 43 branch is available:
$ ostree remote refs fedora
You should see the following in the output:
fedora:fedora/43/x86_64/silverblue
If you want to pin the current deployment (meaning that this deployment will stay as an option in GRUB until you remove it), you can do this by running this command:
# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0
To remove the pinned deployment use the following command:
# 2 is entry position in rpm-ostree status
$ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora Linux 43 branch.
$ rpm-ostree rebase fedora:fedora/43/x86_64/silverblue
Finally, the last thing to do is restart your computer and boot to Fedora Linux 43.
If anything bad happens (for instance, if you can’t boot to Fedora Linux 43 at all) it’s easy to go back. At boot time, pick the entry in the GRUB menu for the version prior to Fedora Linux 43 and your system will start in that previous version rather than Fedora Linux 43. If you don’t see the GRUB menu, try to press ESC during boot. To make the change to the previous version permanent, use the following command:
$ rpm-ostree rollback
That’s it. Now you know how to rebase Fedora Silverblue to Fedora Linux 43 and roll back. So why not do it today?
Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.
Question: Can I skip versions during rebase of Fedora? For example from Fedora 40 Silverblue to Fedora 43 Silverblue?
Answer: Although it could sometimes be possible to skip versions during rebase, it is not recommended. You should always update to one version above (40->41->42->43 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I get errors during rebase. How should I do the rebase?
Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:
$ rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release
After doing this you can follow the guide in this blog post.
Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?
Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/43/x86_64/kinoite
I’m excited to announce my very first Fedora Linux release as the new Fedora Project Leader. Fedora Linux 43 is here! 43 releases! Wow that’s a lot. I was thinking about proposing special tetracontakaitrigon stickers to celebrate this release, but I’m not sure anyone would notice they weren’t circles.
Thank you and congrats to everyone who has contributed to Fedora to this release, and in all the releases leading up to this one. I’m grateful to be back with a chance to take stewardship of the collaboration as the Fedora Project leader. I’ve been getting my feet under me as much as I can in these first few months. I’m looking forward to writing up some longer missives about where I want to steer this ship, but for right now I just want to highlight some of the changes you should expect to encounter in the latest release of Fedora Linux. Read the highlights below to find out more. Or if you are ready just jump right in!
If you have an existing system, Upgrading Fedora Linux to a New Release is easy. In most cases, it’s not very different from just rebooting for regular updates, except you’ll have a little more time to grab a coffee.
If this is your first time running Fedora Linux, or if you just want to start fresh with Fedora, download the install media for our flagship Editions (Workstation, KDE Plasma Desktop, Cloud, Server, CoreOS, IoT), for one of our Atomic Desktops (Silverblue, Kinoite, Cosmic, Budgie, Sway), or for alternate desktop options (like Cinnamon, Xfce, Sway, or others).
As usual, with Fedora, there are just too many individual changes and improvements to go over in detail. You’ll want to take a look at the release notes for that.
There are, however, a few notable user visible changes in this release. For those of you installing fresh Fedora Linux 43 Spins, you may be greeted with the new Anaconda WebUI. This was the default installer interface for Fedora Workstation 42, and now it’s the default installer UI for the Spins as well.
If you are a GNOME desktop user, you’ll also notice that the GNOME is now Wayland-only in Fedora Linux 43. GNOME upstream has deprecated X11 support, and has disabled it as a compile time default in GNOME 49. Upstream GNOME plans to fully remove X11 support in GNOME 50.
Beyond the user-visible changes, there are a couple of significant bits of plumbing that should go unnoticed for most users but are a big deal, nonetheless.
Fedora Linux 43 will be the first release with RPM 6.0. Like I said, this should go unnoticed to end-users, but it is a significant change. RPM 6.0 provides some interesting security enhancements, like multiple key signing of packages. This should help future-proof package signing as we transition to post-quantum-crypto OpenPGP keys in future releases.
We’re also moving forward with our bootc enablement story. Fedora CoreOS is now buildable from a Fedora base bootc image using a Containerfile, instead of needing to be composed with a custom tool. That means anyone with podman can build the Fedora CoreOS image, whether manually or via CI/CD automation.
Fedora CoreOS (FCOS) is also changing how it’s issuing updates to users in Fedora 43. Instead of using an OSTree repository, FCOS updates will be delivered exclusively as OCI images. FCOS 42 provided both OSTree repository and OCI registry as a transition for users. In FCOS 43, the OSTree updates are disabled entirely.
To celebrate all this incredible community work, we’ll be hosting a virtual Fedora Linux 43 Release Party! Please save the date for Friday, 21 November. We’re still finalizing the schedule and speakers, so registration isn’t open just yet, but more details will be shared soon. You can keep an eye on the Fedora Linux 43 Release Party Schedule wiki page for the latest updates!
If you run into a problem, visit our Ask Fedora user support forum. This forum includes a category where we collect common issues and solutions or work-arounds.
Drop by our “virtual watercooler” on Fedora Discussion and join a conversation, share something interesting, and introduce yourself. We’re always glad to see new people!
Below are a few noteworthy changes in the latest release of Fedora Workstation that we think you will love. Upgrade today from the official website, or upgrade your existing install using GNOME Software or through the terminal with dnf system-upgrade.
Fedora Linux 43 Workstation also ships with the brand-new GNOME 49 release, bringing a host of refinements to your desktop. This update introduces significant enhancements for multiple display setups, an improved and streamlined workflow for taking screenshots and screen recordings, and a new “Focus Mode” to help you minimize distractions. Under the hood, resource-smart background throttling improves performance and battery life, while the Settings app has been polished with a refined UI. These are just the highlights. Check out the official GNOME 49 release notes to find more information about all the new features.
One significant change we want to forewarn you about is that Fedora Linux 43 is removing the GNOME X11 packages from the Fedora repositories. All users of the GNOME X11 session will be migrated to the GNOME Wayland session with the upgrade to Fedora Workstation 43.
The transition to the GNOME Wayland session in Fedora Workstation 43 has been in the works for nearly a decade. There have been several prior steps toward this goal, such as the work in Fedora Linux 41 to remove legacy X11 dependencies from core media components.
Wayland has been the default GNOME session on Fedora Workstation for many years, but this release completes the change. The legacy gnome-session-xsession packages have been removed from the Fedora Linux 43 repositories.
This change will unlock a new level of performance and hardware compatibility. You’ll immediately notice smoother, cleaner visuals thanks to triple buffering, which dramatically reduces screen tearing. This change also improves support for a range of hardware, including enhanced drivers for Intel Xe graphics and improvements for systems using NVIDIA Optimus and Hybrid Mode.
The default video player has been changed from Totem to Showtime. Showtime is built on the newer GTK 4 and Libadwaita libraries.
The Noto Color Emoji fonts have released some new files with the COLRv1 format. The COLRv1 format is a color scalable font compared with the previous color bitmap fonts. This new scalable font format should have better or similar rendering results compared to the old bitmap font format. See the change notes for more details.
If you are an app developer, you might be interested in the upgrade to Peas 2. Peas is a gobject-based plugins engine that is used by several GNOME applications.
Be sure to check out the Fedora Linux 43 Change Set wiki for even more details about all the features and changes that went into Fedora Linux 43. Use the Fedora Discussion forum or Fedora’s Matrix chat server if you want to converse with the Fedora community about this new release!
admin )
on 2025-10-28 13:55:32 UTC
Fedora Linux 43 has been released! 
So, let’s see what is included in this new release for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
Alongside the rest of Fedora, we are now compressing our initrds with the Zstandard (zstd) algorithm. This should make the initrd a bit smaller and the boot a bit faster.
See the Fedora Change request and the tracking issue atomic-desktops-sig#34.
Along with the rest of Fedora, systems will install with a 2GB /boot partition. This should make things easier with the growing initrd sizes (mostly due to firmwares). Existing systems will require a backup and re-install to benefit from this change.
See the Fedora Change request.
We are adding the wireguard-tools to all variants. Users will still need to use the graphic interface in their desktop environment to configure WireGuard connections. However, it should now be easier to debug issues using the wg tool. This change was decided too late to be included in the installation ISO but it will come via an update.
See silverblue#390 and kde-sig#381.
We removed plocate from all variants.
Fedora Silverblue comes with the latest GNOME 49 release.
For more details about the changes that alongside GNOME 49, see What’s new in Fedora Workstation 43 on the Fedora Magazine.
We temporarily removed the Third Party page shown during the first boot as it was causing issues. Users will be asked if they want to enable Third Party repositories when they open GNOME Software.
This will be re-enabled once we figure out where the bug is.
See silverblue#650 and atomic-desktops-sig#74.
We added the openssl command line tool to Silverblue, to make the GSConnect extension work without having to resort to package layering or sysexts.
See silverblue#201.
Fedora Kinoite ships with Plasma 6.4, Frameworks 6.18 and Gear 25.08.
See also What’s New in Fedora KDE Plasma Desktop 43? on the Fedora Magazine.
Updates will now be automatically applied on a weekly basis, for Flatpaks and the system. You can configure the frequency or disable auto-updates in the system settings.
See the Fedora Change request and the tracking issue kde-sig#342.
Fedora Sway Atomic comes with the latest 1.11 Sway release.
Fedora Budgie Atomic comes with the latest 10.9.3 Budgie release. Budgie 10.9.3 is a bug-fix and GNOME 49 compatibility release.
Fedora COSMIC Atomic comes with the latest beta release of the COSMIC desktop.
Starting with Fedora 43, we will no longer build XFCE Atomic & LXQt Atomic unofficial images.
Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora 43. Look for upcoming announcements in their Discourse.
As always, I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra media codec, out of tree kernel drivers, etc.).
The next major evolution for the Atomic Desktops will be to transition to Bootable Containers. See also the Fedora bootc documentation.
We have established a roadmap (atomic-desktops-sig#26) and we need your help to make this a smooth transition for all of our existing users.
We have moved the systemd system extensions (sysexts) to a new GitHub organization. The sysexts are now split between those built exclusively from Fedora packages and those built from various community sources. Make sure to update your systemd-sysupdate configs to point to the new URLs.
Now that Fedora’s new forge is available, we will start moving our repos there. You can find the new organization at forge.fedoraproject.org/atomic-desktops. We will likely start by moving the documentation and then issue tracker and the sources.
We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.
admin )
on 2025-10-27 19:39:05 UTC
Fedora has released Fedora KDE Plasma Desktop Edition 43 to the public.
The Fedora KDE Plasma Desktop Edition is well suited for many needs. It combines the reliable and trusted Fedora Linux base with the KDE Plasma Desktop environment. It provides a selection of KDE applications that are simple by default, but powerful when needed.
KDE developers continue to release new features, fix bugs and fine-tune the desktop experience to improve on the now well-established foundation of Plasma 6.
Fedora KDE 43 ships with Plasma 6.4.5 featuring:
Beyond the updates to KDE Plasma 6.4, there are some Fedora KDE updates that have happened with Fedora Linux 43.
Some of the key updates occurred in the core components of Fedora Linux 43, which directly impact the KDE Plasma Desktop Edition, include:
The Fedora KDE SIG hopes that you’ll find the Fedora KDE Plasma Desktop 43 to be a wonderful experience. When you’re ready to try it, click here for download links and verification instructions. If you’d like to learn more, check out the Fedora KDE Plasma Desktop website.
admin )
on 2025-10-24 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 20th – 24th October 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 43 2025 appeared first on Fedora Community Blog.
Participated in the Fedora 43 Elections!
Participated in the Fedora 47 Elections!
Participated in the Fedora 46 Elections!
Participated in the Fedora 45 Elections!
Participated in the Fedora 44 Elections!
admin )
on 2025-10-21 10:00:00 UTC
We in the CLE team and wider Fedora infra space have been talking about the future of Fedora’s development infrastructure for a while. Now it is starting to take shape, as Ryan outlined in the soft launch blog post: Both staging and production Forgejo instances are up and running in the RDU3 datacenter. That means the work of moving away from pagure.io is no longer theoretical. It is happening.
If you have a project on Pagure, you can already open a migration ticket, as described in the Forge documentation, and we will help you move it over. But this is not just about swapping one forge for another. Forgejo gives us a chance to modernize some of the core parts of Fedora’s packaging workflows, such as how we handle ownership, where we store artifacts, and how we integrate automation.
Let us take a closer look.
One of the first questions we hear is: What about CI/CD?
Forgejo upstream recommends Woodpecker/Raven, which are full CI/CD systems. These are powerful, but they are also heavy and expensive to maintain. Fedora is going to take a different approach.
We are focusing on Forgejo Actions, which are somehow API compatible with GitHub Actions(It is not a 1:1 replacement).
This allows contributors to:
For those who want to run heavy workloads, such as large test suites or extensive CI pipelines. You can connect your own self-hosted runners, while the shared Fedora infrastructure will stay lightweight, stable, and dependable. The CLE team won’t provide resources within Fedora’s Forgejo infrastructure.
There was an engaging discussion about dist-git at this year’s Flock, and one message came through clearly: as we move forward, we should take the opportunity to improve the model rather than simply replicate it. The conversation focused on three key areas: package ownership, artifact storage, and Packit integration.
A central theme of our discussion was how we manage permissions and contributions in a way that is both secure and efficient. The goal is to leverage Forgejo’s powerful features to refine our processes.
Right now, all Fedora packages officially belong to the Fedora Project, but the daily reality is a patchwork of individual maintainers and teams. This works, but it leaves gaps.
Forgejo lets us improve this. With its more flexible permissions, we can introduce roles such as maintainer, co-maintainer, or limited contributor. Groups can own packages as first-class entities.
Today, the package build process relies on the Lookaside Cache. It is simple, but it is also dated. It struggles with very large artifacts, it separates code and artifacts, and it does not integrate well with modern workflows.
Several options are on the table:
This is a complex decision with long-term implications. No decision has been made yet. We are committed to a transparent process and will submit a formal Change Proposal to the Fedora Engineering Steering Committee (FESCo) before any major architectural change is implemented, ensuring the entire community can weigh in.
Packit is essential for connecting upstream projects to Fedora packaging. It automates updates, tests, and workflows that save maintainers huge amounts of time.
On Pagure, Packit integration was always custom. On GitHub and GitLab, it is native. This gap created extra work and sometimes rougher edges for Fedora contributors.
The Packit team already prototyped Forgejo support during Google Summer of Code. The service is called Avant, and it’s in our sights as one of the first integration testing areas in staging deployment.
The next steps are:
The long-term goal is clear. Packit in Forgejo should feel natural and seamless, not bolted on.
Some of Fedora’s container builds run through Konflux. Right now, Konflux only supports GitHub and GitLab. To make it work with Forgejo, we built a workaround that mirrors repositories into GitHub. It works, but it is fragile and wasteful.
The better solution is native Forgejo integration. That means upstream changes in Konflux, secure authentication, and removing the mirroring step entirely. Until then, the GitHub workaround will stay in place, but long-term, the focus is on a direct, reliable path.
A migration like this cannot happen overnight. We need to keep workflows running while the move happens. To do this, we are building a compatibility bridge.
The bridge includes:
The goal is continuity. Contributors should be able to keep working while the infrastructure gradually changes behind the scenes.
Fedora’s ecosystem depends on many tools that integrate with dist-git. Each needs some level of adjustment.
The approach is simple. During the transition, a compatibility layer keeps these tools running. Once Forgejo support is mature, the tools can be updated to use Forgejo directly.
This migration is not just an infrastructure swap. It is a chance to fix long-standing pain points, simplify workflows, and make Fedora’s packaging system stronger for the future.
By the end of the Year, I expect us to be able to:
Nice to have:
Fedora thrives on collaboration. Forgejo is our next step toward a modern, maintainable, and community-driven development platform.
Join us in shaping it together, try the staging environment, file migration ticket, and share your feedback in our matrix channel for ideas and discussion, use the git-forge-future tag.
The post Forging Fedora’s Future with Forgejo appeared first on Fedora Community Blog.
This outage impacts the Fedora Forge instance Reason: database maintenance
admin )
on 2025-10-17 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: Oct 13 – Oct 17 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 42 appeared first on Fedora Community Blog.
admin )
on 2025-10-16 10:00:00 UTC
It’s been over a week since I attended OSCAFest 2025 and CHAOSScon Africa 2025, the experience from both gatherings have left lasting impressions and memorable moments on me. All located in Lagos, Nigeria, it was a week-long activity attending CHAOSScon Africa 2025 on the 13th and OSCAFest 2025 on the 15th – 16th of August.
CHAOSS, which is dedicated to creating metrics and analytics to measure the health and sustainability of open-source projects, this time served as an insightful and educational conference. Its sessions dove deep into topics of inclusion, building open-source communities and the discerning business value of open source.
Being involved in The Fedora Project helped me recognize the significant creative value that upstream open source projects contribute to commercial software. Brian Proffitt (Red Hat) talk on the “Metrics and the Business of Open Source” revealed “The Value and Freedom of Creativity” in the Red Hat’’s approach to open source.
On August 15th, I joined the OSCAFest train, experiencing the biggest open-source festival in Africa. The event attracted a diverse range of attendees, including developers, designers, and enthusiasts, with a little under a thousand people in attendance. There were so many talk sessions spread across five different rooms that I occasionally had to move from room to room to attend the ones I was interested in. At OSCAFest, the focus was on enabling growth through open source and inspiring attendees with mentorship-driven talks.
Overall, I had a great time at both events as a Fedora ambassador. I made new friends, connected with people about the Fedora community, and onboarded some potential new contributors to The Fedora Project. Being part of both events as an ambassador creates a pathway for greater visibility of The Fedora Project and our incredible community. It’s a strong start to establishing a larger regional community of contributors and enthusiasts from Africa.
I shared some additional event highlights on my Twitter/X handle (see tweet 1 and tweet 2). One key takeaway was a noticeable difficulty in the onboarding process, while I aimed to recruit new Fedora contributors, I found that Element Chat, our primary community platform, was unfamiliar to many attendees. I frequently received questions about whether we used platforms like Discord or Slack, which often halted conversations. This was a clear indication that for future event outreach, adopting a more popular, regionally familiar platform could serve as a better first line of onboarding, attracting and retaining an audience until they are ready to progressively move to our stable platforms.
I look forward to attending these events again, with the hope of speaking to the audience and further promoting our great community.
The post OSCAFEST’25 & CHAOSS’25 Lagos, Nigeria appeared first on Fedora Community Blog.
admin )
on 2025-10-14 10:00:00 UTC
Hello Fedora Community,
We are excited to share an update on the Packit as Fedora dist-git CI change proposal. This initiative aims to transition Fedora dist-git CI to a Packit-based solution, deprecating Fedora CI and Fedora Zuul Tenant. The change affects the triggering and reporting mechanism for tests but does not alter the tests themselves or the test execution service (Testing Farm). The transition is gradual, allowing maintainers to try the integration out, provide feedback and catch issues early. You can read more about the benefits and why we are doing this in the proposal itself.
As part of the second and third phases, we have implemented Packit-driven installability checks and custom tests for Fedora dist-git PRs.
These features are currently opt-in, and maintainers can enable them by adding their projects to our configuration here by creating a pull request.
Once projects are listed in our packit-service configuration, Packit will automatically run a Koji scratch build and an installability check for every push to a dist-git PR.
Currently, the installability check executed by Packit is identical to the one performed by Fedora CI. In the future, based on user requests and already collected feedback we may plan to enhance it.
Additionally, if a project has both a .fmf/version file and a tmt plan defined in the plans directory, Packit will also execute custom tests in Testing Farm and report the results.
You can see an example of how this feedback appears in this python-specfile example PR or in the screenshots below:
Retriggering of all the jobs via pull request comments is also possible now, for details, see the documentation.
Do you want to know more? Look at our Packit as Fedora dist-git CI documentation.
We welcome feedback and questions! For bugs or feature requests, please use this issue tracker. For ideas or suggestions to discuss, feel free to add a discussion topic here. And for any other questions, join us in the #packit:fedora.im channel on Matrix.
Transition to the new Packit-based CI as the default mechanism, replacing Fedora CI.
This transition will require addressing several technical challenges:
We welcome your feedback. If you’d like to contribute toward reaching our final goal, please add your projects to the list of enabled projects for our Fedora CI here. We’re open to suggestions for improvement and appreciate your support. Thank you!
Recap of the plan
You can also check our tasklist in this issue.
Final phase targets Fedora Linux 44
The original plan was to do the switch during the Fedora Linux 43 cycle, but most of the Packit team members are temporarily focusing on another project. We promised to provide an actively maintained CI solution for Fedora dist-git, so we would rather postpone the default change by one Fedora cycle to ensure we have the capacity to implement the change properly. However, the current Packit workflows are still supported, including the opt-in approach to Fedora dist-git CI. This means you have more time to try it and provide feedback, and we can deliver a more polished solution when it becomes the default for everyone.
We appreciate your support and look forward to your feedback!
Best, the Packit team
The post Packit as Fedora dist-git CI: Phase 2 and 3 completed appeared first on Fedora Community Blog.
admin )
on 2025-10-10 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: Oct 6 – Oct 10 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 41 appeared first on Fedora Community Blog.
admin )
on 2025-10-09 10:00:00 UTC
Hi everyone, I’m Mayank Singh, and I’ve been working on a GSoC 2025 project aimed at simplifying the packaging process in Fedora.
I have been working on making an implementation of the new package review process, where everything happens in one place around git. Instead of switching between Bugzilla tickets, for hosting the source rpm and logs. Instead new contributors can review their packages through pull requests.
Let’s dive into a brief comparison between the current Bugzilla process and the new one.
If you want a package that is not available in Fedora repositories yet, the process looks something like:
.spec file, which declares your package sources and instructions on building it.This process isn’t reliable, it forces developers to constantly juggle multiple tools and tabs. This creates a fragmented and disjointed experience.
We try to solve this problem by trying to focus the workflow around git. A tool developers already use daily. The process is made much simpler in these steps:
The service takes care of the rest for assisting in the review process.
Once the Pull Request is open, the following automated actions are triggered to assist the review:
Checking the latest entry here, we can find the Testing Farm run and inspect the logs to trace the cause of failure.
The checks failed due to a broken package and its dependencies.
fedora-review tool runs, and its formatted output is posted directly as a comment in the pull request discussion.rpmlint checks using Testing Farm.If a change is needed, one can just push a new commit and the service takes care of building and testing now.
Check out the service here: review
The service is based on the packit-service codebase to handle COPR builds, Testing Farm integration, and orchestration of the actions described above with forgejo support.
Repo link: packit/avant
Looking ahead, this workflow can be extended to transfer the packages into dist-git after approval of the package.
Big thanks to my mentor and Fedora community for guidance throughout the GSoC timeline.
Feedback’s appreciated ! Thank you.
The post GSoC 2025: Bringing package reviews to Forgejo appeared first on Fedora Community Blog.
This outage impacts the Fedora Forge instance
admin )
on 2025-10-07 10:00:00 UTC
This week in the Fedora project, we did some small changes to the details and reporting of information in the service.
Previously, we were fetching the text version of the fedora-review report, the problem was it had way too much text for a comment and I had to parse the text file, to format the comment before posting into sections in collapsible tags manually.
While testing, I found out that the tool also publishes a json version with proper segregation of categories, items, checks and the related documentation to each rule. It made it much easier to parse and comment.
Another small change was to report the status for install-ability and rpmlint checks separately from Testing Farm. My mentor suggested this approach to make it easier for users to interpret feedback.
One can check detailed logs of each run by going to dashboard through the details button.
I’m still working through some challenges with unit testing. The tricky part is mocking external dependencies to properly test the integration code in the service. The aim is to catch smaller bugs earlier with better coverage in ogr, the library that’s being used for interacting with forgejo.
We almost have a way to review packages directly within a Forgejo repository. This will allow us to set up a dedicated repo for performing package reviews with automated feedback from tools and experienced packagers.
In the future, this idea could be extended further as Fedora moves to Forgejo, even handling dist-git setup.
For now, my next tasks are:
I’m grateful to my mentor, František Lachman, for his constant support and guidance.
The post Simplifying Package Submission Progress (15 August – 22 August) – GSoC ’25 appeared first on Fedora Community Blog.
admin )
on 2025-10-03 06:27:15 UTC
You went above and beyond - Fedora Project would not be the same without you!
You visited the Fedora booth at TXLF 2025!
admin )
on 2025-10-02 10:00:00 UTC
This week in the project, we covered the changes on how we handle the pull request to make it a more intuitive process.
One of our key goals is to reduce friction for contributors as much as possible. With that in mind, my mentor suggested we align our required file structure with the standard dist-git layout, which defines a package simply with a specfile and patches for the upstream source.
Previously, our service required a packit.yaml configuration file in the repository just to trigger COPR builds and Testing Farm jobs. We have now eliminated this dependency. By parsing the specfile directly from within a pull request, our service can infer all the required context automatically. This removes the need for any boilerplate configuration.
As I have mentioned before that we are currently using the rawhide container images for development, since the current stable Fedora release does not have the required versions of the python bindings for forgejo.
The problem was I was running a dnf update before installing anything in the container and for some reason ca-certificates got upset in the container, which caused the service to not be able to communicate over the network.
With some hit and trial, I discovered that removing that line and simply just not updating can work. That fixed it for now, but the good news is Fedora 43 is going to enter a Beta or a package freeze phase so there should not be any such problems now.
With these core features now in place, my focus for the upcoming weeks will be on two main tasks:
The post Simplifying Package Submission Progress (7 August – 14 August) – GSoC ’25 appeared first on Fedora Community Blog.
We will be updating and rebooting various servers. Services will be up or down during the outage window.
This outage impacts the copr-frontend and the copr-backend.
admin )
on 2025-09-30 10:00:00 UTC
This week in the project, we added the support for status reporting of the package actions via commit statuses.
A key improvement this week is in status reporting. Now, whenever an action like a package build or a test succeeds or fails, the result is directly reported as a commit status on the pull request. This provides immediate clear feedback right where it’s most visible, the list of checks one can find on the bottom of the PR page.
To achieve this, I had to implement the necessary commit status logic for Forgejo within OGR, the library we use for Git forge interactions, as it was previously missing.
I noticed that Forgejo does not really support commenting under individual commits and every comment therefore is just a normal comment in the discussion. I focused on the latter instead.
Currently, what’s left is writing unit tests for the new code, will be done along with pushing the code into upstream sources.
With this feature in place, my next steps will be:
The post Simplifying Package Submission Progress (29 July – 7 August) – GSoC ’25 appeared first on Fedora Community Blog.
admin )
on 2025-09-26 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 22nd – 26th September 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 39 2025 appeared first on Fedora Community Blog.
admin )
on 2025-09-25 13:10:55 UTC
Artificial Intelligence is a transformative technology, and as a leader in open source, the Fedora Project needs a thoughtful position to guide innovation and protect our community’s values.
For the past year, we have been on a journey with the community to define what that position should be. This process began in the summer of 2024, when we asked for the community’s thoughts in an AI survey. The results, which we discussed openly at Flock and in Council meetings, gave us a clear message: we see the potential for AI to help us build a better platform, but we also have valid concerns about privacy, ethics, and quality.
The draft we are proposing below is our best effort to synthesize the Fedora community’s input into a set of clear, actionable guidelines. It is designed to empower our contributors to explore the positive uses of AI we identified, while creating clear guardrails to protect the project and its values from the risks we highlighted.
In accordance with the official Policy Change policy, we are now opening a formal two-week period for community review and feedback. We encourage you to read the full draft and share your thoughts on the discussion.fedoraproject.org post.
After the two-week feedback period, the Fedora Council will hold a formal vote on ratifying the policy via ticket voting. Thank you for your thoughtful engagement throughout this process. We look forward to hearing your feedback as we take this important next step together.
The Fedora Project is a community built on four foundations: Freedom, Friends, Features, and First. We envision a world where everyone benefits from free and open source software built by inclusive, open-minded communities. In the spirit of our “First” and “Features” foundations, we see Artificial Intelligence as a tool to empower our contributors to make a more positive impact on the world.
We recognize the ongoing and important global discussions about how AI models are trained. Our policy focuses on the responsible use of these tools. The responsibility for respecting the work of others and adhering to open source licenses always rests with the contributor. AI assistants, like any other tool, must be used in a way that upholds these principles.
This policy provides a framework to help our contributors innovate confidently while upholding the project’s standards for quality, security, and open collaboration. It is a living document, reflecting our commitment to learning and adapting as this technology evolves.
We encourage the use of AI assistants as an evolution of the contributor toolkit. However, human oversight remains critical. The contributor is always the author and is fully accountable for their contributions.
2. AI In Fedora Project Management: To avoid introducing uncontrollable bias, AI/ML tools must not be used to score or evaluate submissions for things like code of conduct matters, funding requests, conference talks, or leadership positions. This does not prohibit the use of automated tooling for tasks like spam filtering and note-taking.
Our commitment is to our users’ privacy and security. AI-powered features can offer significant benefits, but they must be implemented in a way that respects user consent and control.
One of our key goals is to make Fedora the destination for Linux platform innovation, including for AI.
The data generated by the Fedora Project is a valuable community asset. Its use in training AI models must respect our infrastructure and our open principles.
The post Council Policy Proposal: Policy on AI-Assisted Contributions appeared first on Fedora Community Blog.
admin )
on 2025-09-25 10:00:00 UTC
We’re excited to share our Quarterly Reports from Q1 to Q3 2025. From January to September, we’ve welcomed new members to the DEI team, hosted the Fedora Mentor Summit (FMS), joined Outreachy, connected during Fedora Social Calls, and worked on our Event DEI Location Policy. Here’s a quick look back at what we’ve accomplished together so far this year!
The Fedora Mentor Summit was held in person at Flock to Fedora 2025 in Prague, Czech Republic, and it was a great opportunity to connect and share. Some of the highlights included:
See more in the Past Events section
This year, three Fedora Outreachy interns joined us:
These projects highlight Fedora’s commitment to mentorship and building new contributor pathways.
In July 2025, the DEI team kicked off Fedora Social Calls, casual hangouts to connect beyond project work.
These calls help build community bonds and keep Fedora fun and welcoming.
See the Discussion thread here. If you’d like to participate or propose another day, kindly reply in the thread. Updates about the calls will be shared there. At present, we meet on the second Friday of each month from 3 pm UTC. I hope to see you there.
The Event DEI Location Policy is now an official Council policy. Thanks to Michael Scherer (misc) for helping push this forward!
Its goal is simple: to ensure Fedora’s global events are hosted in places where all contributors, including those from marginalized communities, can participate without barriers.
This policy helps keep Fedora events inclusive and welcoming for everyone worldwide.
In June 2025, Cornelius Emase (lochipi) was nominated and welcomed as a new member of the Fedora DEI Team. Cornelius joined as part of the June–August 2025 Outreachy cohort with the DEI team.
In August 2025, Chris Idoko (chris) was nominated to join the Fedora DEI Team, following his contributions as an Outreachy intern in 2023, representing Fedora at OSCAFEST 2025, and helping organize Week of Diversity 2024.
September 2025 – Micheal (misc) was nominated and welcomed to the Fedora DEI Team. misc has been actively involved in Fedora through creating the Event DEI Location Policy, presenting “Injecting DEI into Community Event Policies” at Flock 2024, contributing to badges, community infrastructure, and more.
Stay tuned for updates on upcoming social calls, ongoing mentorship, and preparations for 2026 DEI activities.
The post Fedora DEI Team Q1–Q3 2025 Highlights appeared first on Fedora Community Blog.
admin )
on 2025-09-24 08:00:00 UTC
Image mode for Fedora Linux leverages bootable containers. This technology enables OCI containers to serve as a transport and delivery mechanism for operating system content. This article will guide you through how to use that technology to quickly create a Web Server using Caddy
Bootable containers leverage existing OCI container tools (like Podman and Docker) and transport protocols for operating system management. This streamlines the configuration and distribution of operating systems through Containerfiles and container registries. The Universal Blue (ublue) community has embraced this technology, offering diverse operating systems. They also provide a project template to simplify the creation of custom operating systems.
We will begin by using the image-template GitHub repository to create our own repository. For this guide I have named it fedora-web-server.
If you don’t have a GitHub account, you can simply clone the repository to your local machine and rename it to reflect your project’s name.
$ git clone git@github.com:<username>/fedora-web-server.git
$ cd fedora-web-server
Image-template simplifies custom OS creation by providing a pre-built structure and essential files. To begin building our web server, we need to choose a base image. While image-template defaults to the ublue Bazzite image, we’ll switch to quay.io/fedora/fedora-bootc:42. Make this change by editing the Containerfile (see immediately below) and replacing the default Base Image.
# Allow build scripts to be referenced without being copied into the final image
FROM scratch AS ctx
COPY build_files /
# Base Image
FROM quay.io/fedora/fedora-bootc:42
RUN --mount=type=bind,from=ctx,source=/,target=/ctx \
--mount=type=cache,dst=/var/cache \
--mount=type=cache,dst=/var/log \
--mount=type=tmpfs,dst=/tmp \
/ctx/build.sh
### LINTING
## Verify final image and contents are correct.
RUN bootc container lint
fedora-bootc is a minimal image designed for customized installations. For this project, I’ll install cloud-init to facilitate deployment and testing both in the cloud and locally. I’ll modify the build_files/build.sh script, which is executed from within the Containerfile, to incorporate cloud-init into our customized OS.
The build.sh file will appear as follow:
#!/bin/bash
set -ouex pipefail
### Install packages
dnf5 install -y --setopt=install_weak_deps=0 cloud-init
Since I want to keep my OS minimal I am not installing weak dependencies.
Caddy is an open-source, modern web server known for its simplicity, security, and automatic configuration—it “just works.” For our Fedora Bootc server, we’ll run Caddy using its container image, docker.io/caddy. We’ll leverage quadlet for seamless integration with systemd, allowing our Caddy container to operate like any other systemd service. Create the following file:
$ cd build_files $ touch caddy.container
and enter the following text into caddy.contatiner :
[Unit] Description=Caddy Web Server After=network-online.target [Container] Image=docker.io/caddy:2-alpine PublishPort=80:80 PublishPort=443:443 Memory=512m Volume=/var/caddy-data/:/data:Z Volume=/var/caddy-config/:/config:Z Volume=/var/log/caddy/:/var/log/caddy:Z Volume=/etc/caddy:/etc/caddy:Z Volume=/var/www/:/var/www:Z [Service] Restart=always [Install] # Start by default on boot WantedBy=multi-user.target
For those familiar with systemd services, the syntax and directives will be recognizable. The [Container] section declares the image to be used, the ports to be published, and the volumes to be shared between the host and the container.
We can now modify the build.sh to copy that file in our custom OS, as shown here:
#!/bin/bash set -ouex pipefail ### Install packages dnf5 install -y --setopt=install_weak_deps=0 cloud-init # Copy caddy.container to /etc/containers/systemd/caddy.container cp /ctx/caddy.container /etc/containers/systemd/caddy.container
The final step to create a working Caddy server is to add the configuration file. Let’s create a Caddyfile:
$ touch Caddyfile
and enter the text shown below:
# Caddy configuration with automatic Let's Encrypt certificates
# Replace 'your-domain.com' with your actual domain name
# For automatic HTTPS with Let's Encrypt, use your domain name instead of :80
# your-domain.com {
# root * /var/www
# file_server
# log {
# output file /var/log/caddy/access.log
# }
# }
# For local development (HTTP only)
:80 {
root * /var/www
file_server
log {
output file /var/log/caddy/access.log
}
}
We can now copy that file in our OS, by editing build.sh
#!/bin/bash set -ouex pipefail ### Install packages dnf5 install -y --setopt=install_weak_deps=0 cloud-init # Copy caddy.container to /etc/containers/systemd/caddy.container cp /ctx/caddy.container /etc/containers/systemd/caddy.container # Create /etc/caddy directory and copy Caddyfile mkdir -p /etc/caddy cp /ctx/Caddyfile /etc/caddy/Caddyfile
To complete the setup, we’ll use systemd.tmpfiles to create Caddy’s necessary internal directories. This approach is essential because /var in bootable containers is mutable through overlayfs, meaning it’s only created at runtime and isn’t part of the container build process. Systemd.tmpfiles provides a straightforward solution to this limitation. Modify your build.sh file as follow:
#!/bin/bash set -ouex pipefail ### Install packages dnf5 install -y --setopt=install_weak_deps=0 cloud-init # Copy caddy.container to /etc/containers/systemd/caddy.container cp /ctx/caddy.container /etc/containers/systemd/caddy.container # Create /etc/caddy directory and copy Caddyfile mkdir -p /etc/caddy cp /ctx/Caddyfile /etc/caddy/Caddyfile # Create tmpfiles.d configuration to set up /var directories at runtime cat > /usr/lib/tmpfiles.d/caddy.conf << 'EOF' # Create Caddy directories at runtime d /var/log/caddy 0755 root root - d /var/caddy-data 0755 root root - d /var/caddy-config 0755 root root - EOF
That’s it. We now have a Containerfile using fedora-bootc:42 as base image, a build script installing cloud-init and installing Caddy via quadlet and copying the Caddy configuration as well as setting up Caddy’s internal directories.
We can now build our custom operating system. The process involved a Containerfile based on fedora-bootc:42, a build script that installed cloud-init and Caddy (configured via quadlet), and the necessary Caddy configuration and directory setup.
If you want your Caddy web server to serve a custom html page, you can copy the following files https://github.com/cverna/fedora-web-server/tree/main/build_files/web and edit the build.sh script as follows:
#!/bin/bash set -ouex pipefail ### Install packages dnf5 install -y --setopt=install_weak_deps=0 cloud-init # Copy caddy.container to /etc/containers/systemd/caddy.container cp /ctx/caddy.container /etc/containers/systemd/caddy.container # Create /etc/caddy directory and copy Caddyfile mkdir -p /etc/caddy cp /ctx/Caddyfile /etc/caddy/Caddyfile # Copy web content to /usr/share for the base image mkdir -p /usr/share/caddy/web cp -r /ctx/web/* /usr/share/caddy/web/ # Create tmpfiles.d configuration to set up /var directories at runtime cat > /usr/lib/tmpfiles.d/caddy.conf << 'EOF' # Create Caddy directories at runtime d /var/log/caddy 0755 root root - d /var/caddy-data 0755 root root - d /var/caddy-config 0755 root root - # Copy web content from /usr/share to /var at runtime d /var/www 0755 root root - C /var/www/index.html 0644 root root - /usr/share/caddy/web/index.html C /var/www/fedora-logo.png 0644 root root - /usr/share/caddy/web/fedora-logo.png C /var/www/caddy-logo.svg 0644 root root - /usr/share/caddy/web/caddy-logo.svg EOF
The image-template repositories equip you with the necessary tools for local image construction. Let’s begin by verifying that all dependencies are in place.
$ sudo dnf install just git jq podman
Then we can run just to build the container. The following shows the just command and subsequent output:
$ just build fedora-web-server latest [1/2] STEP 1/2: FROM scratch AS ctx [1/2] STEP 2/2: COPY build_files / --> Using cache 94ec17d1689b09a362814ab08530966be4aced972050fedcd582b65f174af3a3 --> 94ec17d1689b [2/2] STEP 1/3: FROM quay.io/fedora/fedora-bootc:42 [2/2] STEP 2/3: RUN --mount=type=bind,from=ctx,source=/,target=/ctx --mount=type=cache,dst=/var/cache --mount=type=cache,dst=/var/log --mount=type=tmpfs,dst=/tmp /ctx/build.sh && ostree container commit --> Using cache 8cac20d690bda884b91ae2a555c4239a71f162fbd4ff36a1e2ed5f35f5dfb05a --> 8cac20d690bd [2/2] STEP 3/3: RUN bootc container lint --> Using cache 5cb978e3db5a2bcd437018a6e97e1029d694180002f5fa098aaf540952941dd4 [2/2] COMMIT fedora-web-server:latest --> 5cb978e3db5a Successfully tagged localhost/fedora-web-server:latest
Just is a useful tool for running project-specific commands, similar to Makefiles, and uses a ‘justfile’. As the image functions like any other container image, we can inspect it using Podman.
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/fedora-web-server latest 5cb978e3db5a 4 hours ago 1.95 GB quay.io/fedora/fedora-bootc 42 586b146c456e 2 days ago 1.88 GB
The disk image for our server is built using just as follows:
$ just build-vm localhost/fedora-web-server latest
This will use the bootc-image-builder project to build a disk image of our bootable container. Once the command has finished, we have a qcow2 image in the output directory
$ ls output/qcow2 disk.qcow2
We can now use that qcow2 image to start a Virtual Machine and run our webserver.
To run the server we can use any virtualization software. In this case I am using virt-install:
$ sudo dnf install virt-install libvirt $ virt-install --cloud-init root-ssh-key=/path/to/ssh/public.key --connect qemu:///system --import --name fedora-web-server --memory 2048 --disk output/qcow2/disk.qcow2 --os-variant fedora41 Starting install... Creating domain... ... Fedora Linux 42 (Adams) Kernel 6.16.5-200.fc42.x86_64 on x86_64 (ttyS0) enp1s0: 192.168.100.199 fedora login:
Once the virtual machine is up and running, you can use ssh to login as root, using the local IP address of the virtual machine.
$ ssh root@192.168.100.199
$ bootc status
● Booted image: localhost/fedora-web-server:latest
Digest: sha256:a813a8da85f48d8e6609289dde87e1d45ff70a713d1a9ec3e4e667d01cb470f2 (amd64)
Version: 42.20250911.0 (2025-09-12T07:36:05Z)
Currently, the server’s update capability is limited because the images point to the localhost/fedora-web-server:latest container image. This can be resolved by building and pushing these container images to a container registry such as quay.io or ghcr.io. Detailed instructions for these steps are available in the README file of the ublue-os/image-template repository.
To verify that the web server is running successfully, access that same ip address from your web browser and you should get the following web page.
This guide demonstrates the power of image mode for Fedora Linux using bootc and Caddy to build a lightweight, custom web server. By leveraging container technologies for OS delivery and Caddy for simplified web serving, users can efficiently deploy and manage web applications, setting a strong foundation for future customization. Make sure to check the library of examples to get ideas on how to use bootc.
admin )
on 2025-09-22 08:00:00 UTC
Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. This article provides the steps to rebase to the newly released Fedora Linux 43 Beta, and how to revert if anything unforeseen happens.
NOTE: Before attempting an upgrade to the Fedora Linux 43 Beta, apply any pending upgrades.
Because Fedora LInux 43 Beta is not available in GNOME Software, the whole process must be done through a terminal.
First, check if the 43 branch is available, which should be true now:
$ ostree remote refs fedora
You should see the following line in the output:
fedora:fedora/43/x86_64/silverblue
If you want to pin the current deployment (this deployment will stay as an option in GRUB until you remove it), you can do it by running:
# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0
To remove the pinned deployment use following command ( “2” corresponds to the entry position in the output from rpm-ostree status ):
$ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora 43 branch.
$ rpm-ostree rebase fedora:fedora/43/x86_64/silverblue
Finally, the last thing to do is restart your computer and boot to Fedora Silverblue 43 Beta.
If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 43 Beta at all — it’s easy to go back. Pick the previous entry in the GRUB boot menu (you need to press ESC during boot sequence to see the GRUB menu in newer versions of Fedora Silverblue), and your system will start in its previous state. To make this change permanent, use the following command:
$ rpm-ostree rollback
That’s it. Now you know how to rebase to Fedora Silverblue 43 Beta and fall back. So why not do it today?
Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.
Question: Can I skip versions during rebase of Fedora Linux? For example from Fedora Silverblue 41 to Fedora Silverblue 43?
Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (41->42 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I got errors during rebase. How should I do the rebase?
Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:
rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release
After doing this you can follow the guide in this article.
Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?
Yes, you can follow the Updating using the terminal part of this guide for every ostree edition of Fedora. Just use the corresponding branch. For example for Kinoite use fedora:fedora/43/x86_64/kinoite
admin )
on 2025-09-19 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 15 Sep – 19 Sep 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 38 appeared first on Fedora Community Blog.
admin )
on 2025-09-19 08:00:00 UTC
This guide provides a step-by-step walk-through for integrating a uTrust FIDO2 security key (Identiv uTrust) with Fedora 42 to secure:
The guide is intended for instructional cybersecurity labs and intermediate Fedora users. It prioritizes PIN + Touch verification for strong security.
NOTE: Since misconfiguration can result in system lockout, readers should work only on non-production systems, maintain a fallback password, and back up all critical data before making changes.
The following technology is used in this walk-through:
FIDO2 (Fast Identity Online 2) is a standard for passwordless or multi-factor authentication using hardware tokens. It relies on public key cryptography and supports PIN or biometric verification. In this setup, FIDO2 provides secure, hardware-backed authentication using a PIN and a required physical touch on the key.
LUKS2 (Linux Unified Key Setup 2) is the full-disk encryption format used in modern Linux systems.
PAM (Pluggable Authentication Modules) and Polkit (PolicyKit) control authentication for logins and privilege escalation across both GUI and CLI actions.
This guide combines these technologies to deliver end-to-end security — from full-disk decryption at boot, to graphical login, to administrative elevation with sudo.
The following hardware/software is used in this implementation:
Hardware and Software:
FIDO2 Key: Identiv uTrust FIDO2
Disk Setup
The following phases occur during implementation:
Install required development and security packages:
sudo dnf install -y
gcc make cmake git autoconf automake libtool
pam-devel systemd-devel glibc-devel openssl-devel
libfido2 libfido2-devel fido2-tools u2f-host pam-u2f
pcsc-lite pcsc-lite-ccid pcsc-tools ccid opensc
authselect cryptsetup pam_passwdqc fprintd-pam gnome-keyring-pam
Enable and start the PC/SC daemon for smartcard support:
sudo systemctl enable --now pcscd
Polkit GUI prompts were not enabled on my test system (no /etc/pam.d/polkit-1 and no running user agent). If you want FIDO2 for Polkit dialogs, ensure a compatible agent is running (for Cinnamon: polkit-gnome-authentication-agent-1). In testing, GUI prompts were not enabled by default and required additional configuration.”
Screensaver unlock: When the screen is locked, Fedora may default to the password prompt. Click the small two-person icon to switch to the FIDO2 method. Keep a fall-back password available. In various tests some desktop prompts did not always default to FIDO2.
The following sequence of images shows the following:
Backup:
mkdir -p ~/fido2-audit/pam_restore
for file in sudo lightdm cinnamon-screensaver system-auth password-auth polkit-1;
do
sudo cp ~/fido2-audit/pam/$file ~/fido2-audit/pam_restore/$file
done
Restore if needed using TTY or Live USB.
Emergency Login:
Multiple FIDO2 Keys:
lsusb sudo usbreset /dev/bus/usb/001/003
Strengths:
Risks:
Recommendations:
| Component | Delay Added |
|---|---|
| Boot (FDE) | ~5–10 seconds |
| GUI Login | ~2–3 seconds |
| Sudo/Polkit | ~1–2 seconds |
This guide demonstrates the successful integration of a uTrust FIDO2 security key with Fedora 42 for secure authentication across LUKS2 full-disk encryption, LightDM login, and sudo elevation. The setup is stable, reproducible, and well-suited for labs or intermediate Fedora users.
Polkit integration is optional and may vary by desktop environment. In testing, GUI prompts were not enabled by default and required additional configuration.
admin )
on 2025-09-18 10:00:00 UTC
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.
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.
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.
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.
Please use the #git-forge-future tag on Fedora Discussion to communicate your feedback and the #fedora-forgejo:fedoraproject.org channel on Fedora Chat to collaborate with us.
The post Announcing the Soft Launch of Fedora Forge appeared first on Fedora Community Blog.
admin )
on 2025-09-17 08:00:00 UTC
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.
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:
By embracing complyctl, Fedora users can more easily maintain a strong security posture.
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.
First, install complyctl, if necessary. It is available as an RPM package in official repositories:
sudo dnf install complyctl
complyctl follows a logical, sequential workflow:
Let’s walk through these commands.
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:
sudo dnf install complyctl-openscap-plugin scap-security-guide
Step 4: Generate Policy Artifacts
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.
tree complytime/ complytime/ ├── assessment-plan.json └── openscap ├── policy │ └── tailoring_policy.xml ├── remediations │ ├── remediation-blueprint.toml │ ├── remediation-playbook.yml │ └── remediation-script.sh └── results
Step 5: Execute the Compliance Scan
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.
tree complytime/
complytime/
├── assessment-plan.json
├── assessment-results.json
├── assessment-results.md
└── openscap
├── policy
│ └── tailoring_policy.xml
├── remediations
│ ├── remediation-blueprint.toml
│ ├── remediation-playbook.yml
│ └── remediation-script.sh
└── results
├── arf.xml
└── results.xml
complyctl is an open-source tool built for and by the community. We encourage you to give it a try.
This outage impacts the copr-frontend and the copr-backend.
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!
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:
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.
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.
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.
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.
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 (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.
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.
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.
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.
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.
The post Fedora 43 Wallpaper Wrap Up appeared first on Fedora Community Blog.
We are running out of storage, and AI scraper load, Fedora Copr is now very slow or halted.
This outage impacts the copr-frontend and the copr-backend.