We will be updating and rebooting various servers. Services will be up or down during the outage window.
We might be doing some firmware upgrades, so when services reboot they may be down for longer than in previous "Update + Reboot" cycles.
We will be updating and rebooting various servers. Services will be up or down during the outage window.
We might be doing some firmware upgrades, so when services reboot they may be down for longer than in previous "Update + Reboot" cycles.
admin )
on 2026-01-22 10:40:39 UTC
You connected with CentOS in 2026
admin )
on 2026-01-22 05:58:32 UTC
You attended the 2026 iteration of DevConf.IN, an annual free and open source conference in India!
admin )
on 2026-01-21 12:00:00 UTC
There is heavy scraper activity against dl.fedoraproject.org. We are working to mitigate it.
admin )
on 2026-01-20 08:00:00 UTC
Prague is calling! The deadline for the Flock 2026 CFP (Call for Proposals) is fast approaching. You have until Monday, February 2nd to submit your session ideas for Fedora’s premier contributor conference.
We are returning to the heart of Europe (June 14–16) to define the next era of our operating system. Whether you are a kernel hacker, a community organizer, or an emerging local-first AI enthusiast, Flock is where the roadmap for the next year in Fedora gets written.
If you haven’t submitted yet, here is why you should.
This year isn’t just about maintenance; it is about architecture. As we look toward Fedora Linux 45 and 46, we are also laying the upstream foundation for Enterprise Linux 11. This includes RHEL 11, CentOS Stream 11, EPEL 11, and the downstream rebuilder ecosystem around the projects. The conversations happening in Prague will play a part in the next decade of modern Linux enterprise computing.
To guide the schedule, we are looking for submissions across our Four Foundations:
Freedom (The Open Frontier)How are we pushing the boundaries of what Open Source can do? We are looking for Flock 2026 CFP submissions covering:
Friends (Our Fedora Story)Code is important, but community is critical. We need sessions that focus on the human element:
Features (Engineering Core)The “Nitty-Gritty” of the distribution. If you work on the tools that build the OS every six months, we want you on stage:
First (Blueprint for the Future)Fedora is “First.” This track is for the visionaries:
If you require financial support to attend, please remember that the Flock 2026 CFP submission is separate from the Travel Subsidy application, but speakers are prioritized. Make sure to apply for the Travel Subsidy by March 8.
Don’t let the deadline slip past you. Head over to our CFP platform and draft your proposal today.
Submit to the Flock 2026 CFPSee you in Prague!
Note: AI (Google Gemini) edited human-generated content first written by me, the author, to write this article. I, the author, edited the AI-generated output before making this Community Blog article. If you notice mistakes, please provide a correction as a reply to this topic.
The post 2 Weeks Left: The Flock 2026 CFP Ends Feb 2 appeared first on Fedora Community Blog.
admin )
on 2026-01-16 10:00:00 UTC
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 12 Jan – 16 Jan 2026
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
This team is working on day to day business regarding Fedora CI and testing.
This team is working on deployment of forge.fedoraproject.org.
Ticket tracker
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 03 2026 appeared first on Fedora Community Blog.
admin )
on 2026-01-09 10:00:00 UTC
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 05 Jan – 09 Jan 2026
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 02 2026 appeared first on Fedora Community Blog.
admin )
on 2026-01-08 12:00:00 UTC
The tmt web app is a simple web application that makes it easy to explore and share test and plan metadata without needing to clone repositories or run tmt commands locally.
At the beginning, there was the following user story:
As a tester, I need to be able to link the test case(s) verifying the issue so that anyone can easily find the tests for the verification.
Traceability is an important aspect of the testing process. It is essential to have a bi-directional link between test coverage and issues covered by those tests so that we can easily:
Implementing the first direction in tmt was relatively easy: We just defined a standard way to store links with their relations. This is covered by the core link key which holds a list of relation:link pairs. Here’s an example test metadata:
summary: Verify correct escaping of special characters test: ./test.sh link: - verifies: https://issues.redhat.com/browse/TT-206
The solution for the second direction was not that straightforward. Thanks to its distributed nature, tmt does not have any central place where a Jira issue could point to. There is no server which keeps information about all tests and stores a unique id number for each which could be used in the link.
Instead of integers, we’re using the fmf id as the unique identifier. It contains url of the git repository and name of the test. Optionally, it can also define ref instead of using the default branch and path to the fmf tree if it’s not in the git root.
The tmt web app accepts an fmf id of the test or plan or both, clones the git repository, extracts the metadata, and returns the data in your preferred format:
The service is currently available at the following location:
Here’s an example of what the parameters would look like when requesting information about a test in the default branch of a git repository:
By default, a human-readable HTML version of the output is provided to the user. Include the format parameter in order to choose your preferred format:
It is possible to link a test, a plan, or both test and plan. The last option can be useful when a single test is executed under several plans. Here’s how the human readable version looks like:
In order to make the linking as smooth as possible, the tmt test create command was extended to allow automated linking to Jira issues.
First make sure you have the .config/tmt/link.fmf config prepared. Check the Link Issues section for more details about the configuration.
issue-tracker:
- type: jira
url: https://issues.redhat.com
tmt-web-url: https://tmt.testing-farm.io/
token: ***
When creating a new test, use the --link option to provide the issue which is covered by the test:
tmt test create /tests/area/feature --template shell --link verifies:https://issues.redhat.com/browse/TT-206The link will be added to both test metadata and the Jira issue. Just note that the Jira link will be working once you push the changes to the remote repository.
It’s also possible to use the tmt link command to link issue with already existing tests or plans:
tmt link --link verifies:https://issues.redhat.com/browse/TT-206 /tests/core/escapingIf both test and plan should be linked to the issue, provide both test and plan as the names:
tmt link --link verifies:https://issues.redhat.com/browse/TT-206 /tests/core/escaping /plans/features/coreThis is how the created links would look like in Jira:
As a proof of concept, for now there is only a single public instance of the tmt web app deployed, so be aware that it can only explore git repositories that are publicly available. For the future we consider creating an internal instance in order to be able to access internal repositories as well.
We are looking for early feedback. If you run into any problems or any missing features, please let us know by filing a new issue. Thanks!
The post Improve traceability with the tmt web app appeared first on Fedora Community Blog.
admin )
on 2026-01-08 08:00:00 UTC
The Fedora Linux 43 (F43) election cycle has concluded. In this election round, there was only one election, for the Fedora Engineering Steering Committee (FESCo). Congratulations to the winning candidates. Thank you to all candidates for running in this election.
Five FESCo seats were open this election. A total of 214 ballots were cast, meaning a candidate could accumulate a maximum of 1,498 votes. More detailed information on the voting breakdown is available from the Fedora Elections app in the Results tab.
| # votes | Candidate |
| 1013 | Kevin Fenzi |
| 842 | Zbigniew Jędrzejewski-Szmek |
| 784 | Timothée Ravier |
| 756 | Dave Cantrell |
| 706 | Máirín Duffy |
| 685 | Fabio Alessandro Locati |
| 603 | Daniel Mellado |
The post Fedora Linux 43 (F43) election results appeared first on Fedora Community Blog.
You got a "Change" accepted into the Fedora 47 Change list
You got a "Change" accepted into the Fedora 46 Change list
You got a "Change" accepted into the Fedora 45 Change list
You got a "Change" accepted into the Fedora 44 Change list
You got a "Change" accepted into the Fedora 43 Change list
admin )
on 2026-01-05 14:39:09 UTC
Voting is currently open for the Fedora Engineering Steering Committee (FESCo). You have approximately 2 days and 9 hours remaining to participate.
DEADLINE: 2026-01-07 at 23:59:59 UTC
VOTE HERE: https://elections.fedoraproject.org/about/f43-fesco
Please ensure your ballot for the Fedora Linux 43 FESCo Elections is cast before the cutoff.
The post DEADLINE 2026-01-07: Fedora Linux 43 FESCo Elections appeared first on Fedora Community Blog.
admin )
on 2025-12-31 08:00:00 UTC
Anaconda installer now supports installation of bootc based bootable container images using the new bootc command. It has supported several types of payload to populate the root file system during installation. These include RPM packages (likely the most widely used option), tarball images you may know from Fedora Workstation, ostree, and rpm-ostree containers. The newest addition to the family, from a couple of weeks ago, is bootc-based bootable containers.
We have added a new bootc kickstart command to Anaconda to support the new feature. This is very similar to the ostreecontainer command that has been present for some time. From the user’s perspective the two are very similar. The main difference, however, is under the hood.
One of the most important setup steps for a deployment is to create a requested partitioning in both cases. When the partitioning is ready, the ostreecontainer command makes Anaconda deploy the image onto the root filesystem using the ostree tool. It also executes the bootupctl tool to install and set up the bootloader. By contrast, with bootc containers installed using the bootc kickstart command, both the filesystem population and bootloader configuration is performed via the bootc tool. This makes the deployment process even more integrated.
The content of the container images used for installation is another difference. The bootc-enabled images are somewhat more versatile. Apart from installation using Anaconda, they provide a self-installing option via the bootc command executed from within a running container.
On the other hand, both options provide you with a way to install an immutable system based on a container image. This option may be useful for particular use cases where regular installation from RPM packages is not desired. This might be due to potentially lower deployment speed or inherent mutability of the resulting system.
In practice, you’d likely use a custom container with pre-configured services, user accounts and other configuration bits and pieces. However, if you want to quickly try out how the new Anaconda’s feature works, you just need to follow a few simple steps. Starting with a Fedora Rawhide ISO:
First, take an existing container from a registry and create a minimal kickstart file instructing Anaconda to install the bootable container image:
# Beware that this kickstart file will wipe out the existing disk partitions. # Use it only in an experimental/isolated environment or edit it accordingly! zerombr clearpart --all --initlabel autopart lang en_US.UTF-8 keyboard us timezone America/New_York --utc rootpw changeme bootc --source-imgref=registry:quay.io/fedora/fedora-bootc:rawhide
As a next step, place the kickstart file in some reachable location (e. g. HTTP server), point Anaconda to it by appending the following on the kernel command line:
inst.ks=http://url/to/kickstart
Now start the installation.
Alternatively, you may use the mkksiso tool provided by the lorax package to embed the kickstart file into the installation ISO.
When installation and reboot is complete, you are presented with an immutable Fedora Rawhide system. It will be running on your hardware (or VM) installed from a bootable container image.
You may ask if this option is limited to Fedora Rawhide container images. Technically speaking, you can use the Fedora Rawhide installation ISO to install, for instance, a CentOS Stream container image:
bootc --source-imgref=registry:quay.io/centos-bootc/centos-bootc:stream10
Nevertheless, keep in mind that for now Anaconda will handle it as Fedora installation in such a case. This is because it runs from a Fedora Rawhide boot ISO. This may result in unforeseen problems, such as getting a btrfs-based partitioning that CentOS Stream won’t be able to boot from. This particular issue is easily overcome by explicitly telling Anaconda to use some different partitioning type, e. g. autopart –fstype=xfs. We would like to address the lack of container images handling based on the contained operating system or flavour in the future. For now, one just needs to take the current behavior into consideration when using the bootc command.
There are a couple more known limitations in Anaconda or bootc at this point in time. These include lack of support for partitioning setups spanning multiple disks, support for arbitrary mount points, or for installation from authenticated registries. But we hope it won’t take long to solve those shortcomings. There are also plans to make the new bootc command available even on the RHEL-10 platform.
We invite you to try out this new feature and share your experience, ideas or comments with the Installer team. We are looking forward to hearing from you in a thread on discussion.fedoraproject.org!
admin )
on 2025-12-19 10:00:00 UTC
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 15 – 19 December 2025
This team is working on deployment of forge.fedoraproject.org.
Ticket tracker
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
This team is working on day to day business regarding Fedora CI and testing.
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 51 2025 appeared first on Fedora Community Blog.
admin )
on 2025-12-17 08:06:00 UTC
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
I have used Fedora as my daily driver since 2003 and have actively contributed to Fedora since 2004. (Example: I designed the current Fedora logo and website design.) I am very passionate about the open source approach to technology. I first started using Linux as a high school student (my first Linux was Red Hat 5.1) and being able to use free software tools like Gimp when I couldn’t afford Photoshop made an outsized impact on my life. (I explain my background in Linux and open source in-depth in this interview with Malcolm Gladwell: https://youtu.be/SkXgG6ksKTA?si=RMXNzyzH9Tr6AuwN )
Technology has an increasingly large impact over society. We should have agency over the technology that impacts our lives. Open source is how we provide that agency. We’re now in a time period with a new disruptive technology (generative AI) that – regardless if you think it is real or not, is having real impact on computing. Fedora and other open source projects need to be able to provide the benefits of this new technology, the open source way and using open source software. Small, local models that are easy for our users to deploy on their own systems using open source tooling will provide them the ability to benefit AI’s strengths without having to sacrifice the privacy of their data.
There is a lot of hype around AI, and a lot of very legitimate concerns around its usage including the intellectual property concerns of the pre-trained data, not having enough visibility into what data is part of pre-trained data sets, the working conditions under which some of the data is labeled under, the environmental impact of the training process, the ethics of its usage. Open source projects in particular are getting pummeled by scraping bots hungry to feed coding models. There are folks in the tech industry who share these legitimate concerns that prefer to avoid AI and hope that it the bubble will just pop and it will go away. This strategy carries significant risks, however, and we need a more proactive approach. The technology has legitimate uses and the hype is masking them. When the hype dies down, and the real value of this new technology is more visible, it will be important for the type of community members we have in Fedora with their commitment to open source principles and genuinely helping people to have had a seat at the table to shape this technology.
(You can see a short video where I talk a bit more indepth about the pragmatic, privacy and open source-focused approach I take to AI here: https://youtu.be/oZ7EflyAPUw?si=HSbNhq_3NelXoX2J)
In the past I have been quite skeptical about generative AI and worried about its implications for open source. (I continue to be skeptical and annoyed by the hype surrounding it.) I’ve spent the past couple of years looking at open source licensed models and building open source generative AI tooling – getting hands on, deep experience to understand it – and as a result I have seen first hand the parts of this technology that have real value. I want FESCo to be able to make informed decisions when AI issues come up.
My background is in user experience engineering, and I am so excited about what this technology will mean for improving usability and accessibility for users of open source software. For example, we never have enough funding or interest to solve serious a11y problems; now we could generate text summaries of images & describe the screen out loud with high-quality audio from text-to-voice models for low vision users! I want open source to benefit from these and even more possibilities to reach and help more people so they can enjoy software freedom as well.
I have served in multiple governance roles in Fedora including time on the Fedora Council, the Mindshare Committee, lead of various Fedora Outreachy rounds (I have mentored dozens of interns in Fedora), and founder / lead of the Design team over many years. More importantly, I have deep Linux OS expertise, I have deep expertise in user experience, and I have a depth in AI technology to offer to FESCo. I believe my background and skills will enable FESCo to make responsible decisions in the best interest of open source and user agency, particularly around the usage of AI in Fedora and in the Fedora community. We will absolutely need to make decisions as a governing group in the AI space, and they should be informed by that specific expertise.
I founded and ran the Fedora Design Team for 17 years. It was the first major Linux distribution community-lead design team, and often as a team we’ve been asked by other distros and open source projects for help (so we expanded to call ourselves the “Community Design Team.”) Over the years I’ve designed the user experience and user interfaces for many components in Fedora including our background wallpapers, anaconda, virt-manager, the GNOME font-chooser, and a bunch of other stuff. I moved on from the Fedora Design role to lead design for Podman Desktop and to work more with the Podman team (who are also part of the Fedora community) for a couple of years, and I also led the InstructLab open source LLM fine-tuning project and corresponding Linux product from Red Hat (RHEL AI.) For the past year or so I have returned to working on core Linux on the Red Hat Enterprise Linux Lightspeed team, and my focus is on building AI enhancements to the Linux user experience. My team is part of the Fedora AI/ML SIG and we’re working on packaging user-facing components and tooling for AI/ML for Fedora, so folks who would like to work with LLMs can do so and the libraries and tools they need will be available. This includes building and packaging the linux-mcp-server and packaging goose, a popular open source AI agent, and all of their dependencies.
My career has focused on benefiting Fedora users by improving the user experience of using open source technology, and being collaborative and inclusive while doing so.
Data is the best way to handle disagreements when working as part of a team. Opinions are wonderful and everyone has them, but decisions are based made with real data. Qualitative data is just as important as quantitative data, by the way. That can be gathered by talking directly to the people most impacted by the decision (not necessarily those who are loudest about it) and learning their perspective. Then informing the decision at hand with that perspective.
A methodology I like to follow in the face of disagreements is “disagree and let’s see.” (This was coined by Molly Graham, a leadership expert.) A decision has to be made, so let’s treat it like an experiment. I’ll agree to run an experiment, and track the results (“let’s see”) and advocate for a pivot if it turns out that the results point to another way (and quickly.) Being responsible to track the decision and its outcomes and bringing it back to the table, over time, helps build trust in teams like FESCo so folks who disagree know that if the decision ended up being the wrong one, that it can and will be revisited based on actual outcomes.
Another framework I like to use in disagreements is called 10-10-10, created by Suzy Welch. It involves thinking through: how will this decision matter in 10 minutes? How about 10 months? How about 10 years? This frame of thought can diffuse some of the chargedness of disagreement when all of the involved people realize the short or long term nature of the issue together at the same time.
Acknowledging legitimate concerns and facing them head on instead of questioning or sidelining others’ lived experience and sincerely-held beliefs and perspectives is also incredibly important. Listening and building bridges between community members with different perspectives, and aligning them to the overall projects goals – which we all have in common as we work in this community – is really helpful to help folks look above the fray and be a little more open-minded.
I understand there is a campaign against my running for FESCo because myself and a colleague wrote an article that walked through real, undoctored debugging sessions with a locally-hosted, open source model in order to demonstrate the linux-mcp-server project.
I want to make it clear that I believe any AI enhancements that are considered for Fedora need a simple opt-in button, and no AI-based solutions should be the default. (I’ve spoken about this before, recently on the Destination Linux Podcast: https://youtu.be/EJZkJi8qF-M?t=3020) The user base of Fedora and other open source operating systems come to their usage in part due to wanting agency over the technology they use and having ownership and control over their data. The privacy-focused aspects of Fedora have spanned the project’s existence and that must be respected. We cannot ignore AI completely, but we must engage with it thoughtfully and in a way that is respectful of our contributors and user base.
To that end, should you elect to grant me the privilege of a seat to FESCo this term:
My core software engineering background is in user experience and usability, and I believe in the potential of small, local models to improve our experience with software without compromising our privacy and agency. I welcome ongoing community input on these principles and other boundaries you’d like to see around emerging technologies in Fedora.
The post F43 FESCo Elections: Interview with Máirín Duffy (duffy/mizmo) appeared first on Fedora Community Blog.
admin )
on 2025-12-17 08:05:00 UTC
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
I want to be a member of FESCo to represent the interests of users, developers and maintainers of what we call Atomic, Bootable Container, Image Based or Immutable variants of Fedora (CoreOS, Atomic Desktops, IoT, bootc, etc.).
I think that what we can build around those variants of Fedora is the best path forward for broader adoption of Fedora and Linux in the general public and not just in developer circles.
I thus want to push for better consideration of the challenges specific to Atomic systems in all parts of Fedora: change process, infrastructure, release engineering, etc.
I also want to act as a bridge with other important communities built around this ecosystem such as Flathub, downstream projects such as Universal Blue, Bazzite, Bluefin, Aurora, and other distributions such as Flatcar Linux, GNOME OS, KDE Linux, openSUSE MicroOS, Aeon or ParticleOS.
I primarily contribute to Fedora as a maintainer for the Fedora Atomic Desktops and Fedora CoreOS. I am also part of the KDE SIG and involved in the Bootable Containers (bootc) initiative.
My contributions are focused on making sure that those systems become the most reliable platform for users, developers and contributors. This includes both day to day maintenance work, development such as enabling safe bootloader updates or automatic system updates and coordination of changes across Fedora (switching to zstd compressed initrds as an example).
While my focus is on the Atomic variants of Fedora, I also make sure that the improvements I work on benefit the entire Fedora project as much as possible.
I’ve listed the Fedora Changes I contributed to on my Wiki profile: https://fedoraproject.org/wiki/User:Siosm.
Disagreements are a normal part of the course of a discussion. It’s important to give the time to everyone involved to express their positions and share their context. Limiting the scope of a change or splitting it into multiple phases may also help.
Reaching a consensus should always be the preferred route but sometimes this does not happen organically. Thus we have to be careful to not let disagreements linger on unresolved and a vote is often needed to reach a final decision. Not everyone may agree with the outcome of the vote but it’s OK, we respect it and move on.
Most decisions are not set in stone indefinitely and it’s possible to revisit one if the circumstances changed. A change being denied at one point may be accepted later when improved or clarified.
This is mostly how the current Fedora Change process works and I think it’s one of the strength of the Fedora community.
I’ve been a long time Fedora user. I started contributing more around 2018 and joined Red Hat in 2020 where I’ve been working on systems such as Fedora CoreOS and RHEL CoreOS as part of OpenShift. I am also part of other open source communities such as Flathub and KDE and I am committed to the upstream first, open source and community decided principles.
The post F43 FESCo Elections: Interview with Timothée Ravier (siosm/travier) appeared first on Fedora Community Blog.
admin )
on 2025-12-17 08:04:00 UTC
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
I accepted this nomination because I believe FESCo would benefit from fresh perspectives, and I think that these new perspectives will also help to lower the entrance barriers for Fedora.
Governance bodies stay healthy when they welcome new voices alongside experienced members, and I want to be part of that renewal.
Technologies like eBPF are redefining what’s possible in Linux–observability, security, networking–but they also bring packaging challenges that we haven’t fully solved, such as kernel version dependencies, CO-RE relocations, BTF requirements, and SELinux implications.
On FESCo, I want to help Fedora stay ahead of these challenges rather than merely reacting to them. I want to advocate for tooling and guidelines that will help make complex kernel-dependent software easier to package.
I founded and currently lead the Fedora eBPF Special Interest Group. Our goal is to make eBPF a first-class citizen in Fedora, improving the experience for the developers who are building observability, security, and networking tools and figuring out how to package software that has deep kernel dependencies.
On the packaging side, I maintain bpfman (an eBPF program manager) and several Rust crates that support eBPF and container tooling. I’ve also learned the hard way that Rust dependency vendoring is… an adventure. 
Before Fedora, I spent years in the OpenStack community. I served as PTL (Project Team Lead) for the Kuryr project, the bridge between container and OpenStack networking and was active in the Kubernetes SIG. That experience taught me a lot about running open source projects: building consensus across companies, mentoring contributors, managing release cycles, and navigating the politics of large upstream communities.
I try to bring that same upstream, community-first mindset to Fedora. My hope is that the patterns we establish in the eBPF SIG become useful templates for other packagers facing similar challenges.
I start by assuming good intent. If someone is in the discussion, it’s because they do also care about the outcome, even though they may have another point of view.
I also try not to speculate about why someone holds a particular view. Assigning motives derails technical conversations fast. Instead, I focus on keeping things facts-driven: what does the code actually do, what do users need, what are the real constraints? Egos don’t ship software, and sticking to concrete data keeps discussions productive.
When disagreements persist, I find it helps to identify what everyone does agree on and use that as a new starting point. You’d be surprised how often this unblocks a stalled conversation.
Also, I think that it’s important to step back. It’s tempting to want the final word, but that can drag things on forever without real progress. Miscommunication happens and not every discussion needs a winner.
I believe in Fedora’s Four Foundations: Freedom, Friends, Features, First. What draws me to this community is the “Friends” part: there’s a place in Fedora for anyone who wants to help, regardless of background or technical skill level. Open source is at its best when it’s genuinely welcoming, and I want FESCo to reflect that.
From my time in the OpenStack community, I learned that healthy projects focus on protecting, empowering, and promoting: protecting the open development process and the values that make the community work; empowering contributors to do great work without painful barriers; and promoting not just the software, but the people who build and use it. I try to bring that mindset to everything I do.
I also believe strongly in working upstream. The changes we make should benefit not just Fedora users, but the broader open source ecosystem. When we solve a hard problem here, that knowledge should flow back to upstream projects and other distributions.
I’ll be at FOSDEM 2026. FOSDEM embodies what I love about open source: a non-commercial space where communities meet to share knowledge freely. If you’re there, come say hi.
The post F43 FESCo Elections: Interview with Daniel Mellado (dmellado) appeared first on Fedora Community Blog.
admin )
on 2025-12-17 08:03:00 UTC
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
noc -> day to day infra stuff, handling alerts, talking with other infra folksadmin -> answering questions, helping fix issues, some team discussionsreleng -> release engineering team discussions, answering questions, handling issues, etc.I think I still provide useful historical information as well as being able to pull on that long history to know when things are good/bad/have been tried before and have lessons to teach us.
Based on the proposals we approve or reject we can steer things from FESCo. I do think we should be deliberate, try and reach consensus and accept any input we can get to try to come to good decisions. Sometimes things won’t work out that way, but it should really be the exception instead of the rule.
I’m lucky to be paid by Red Hat to work on infrastucture, I like to hope it’s useful to the community
In my spare time I work on packages, answering questions where I can, unblocking people, release engineering work, matrix and lists moderation.
I really hope my contributions contribute to a happier and more productive community.
I try and reach consensus where possible. Sometimes that means taking more time or involving more people, but If it can be reached I think it’s really the best way to go.
Sometimes of course you cannot reach a consensus and someone has to make a call. If thats something I am heavily involved in/in charge of, I do so. I’m happy that we have a council as a override of last resort in case folks want to appeal some particularly acromonious decision. Also, as part of a team you have to sometimes delegate something to someone and trust their judgement in how it’s done.
I think there’s been a number of big debates recently and probibly more to come. We need to remember we are all friends and try and see things from other people’s point of view.
My hero these days seems to be treebeard: “Don’t be hasty”
My matrix/email is always open for questions from anyone…
The post F43 FESCo Elections: Interview with Kevin Fenzi (kevin/nirik) appeared first on Fedora Community Blog.
admin )
on 2025-12-17 08:02:00 UTC
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
I have been part of the Fedora community for many years now: my FAS account dates back to January 2010 (over 15 years ago!), and I’ve contributed in many different roles to the Fedora project. I started as an ambassador, then became a packager and packaging mentor, and joined multiple SIGs, including Golang, Sway, and Atomic Desktop. For many years, I’ve been interested in immutable Linux desktops, Mobile Linux, and packaging challenges for “new” languages (such as Go), which are also becoming more relevant in the Fedora community now. Having contributed to the Fedora Project for a long time in many different areas, and given my experience and interest in other projects, I can bring those perspectives to FESCo.
Currently, many of my contributions fall in the packaging area: I keep updating the packages I administer and exploring different solutions for packaging new languages and maintaining the Sway artifacts.
My current contributions are important to keeping Fedora first, not only in terms of package versions but also in terms of best practices and ways to reach our users.
Additionally, I served for the last two cycles (F41/F42) as a FESCo member, steering the community toward engineering decisions that were both sensible in the short and long term.
I think disagreements are normal in communities. I have a few beliefs that guide me in entering and during any disagreement:
Thanks to my beliefs, I always manage to keep disagreements civil and productive, which often leads to a consensus. It is not always possible to agree on everything, but it is always possible to disagree in a civil, productive way.
Let’s start with the fact that I’m a Red Hat employee, though what I do in my day job has nothing to do with Fedora (I’m an Ansible specialist, so I have nothing to do with RHEL either), so I have no ulterior motives for my contributions. I use Fedora on many devices (starting from my laptop) and have done so for many years. I contribute to the Fedora Project because I found in it and its community the best way to create the best operating system :).
I’ve been using Sway exclusively on my Fedora desktop since I brought it into Fedora in 2016. On the other systems, I use either Fedora Server, Fedora CoreOS, or Fedora IoT, even though lately, I prefer the latter for all new non-desktop systems.
I see the Fedora Community as one community within a sea of communities (upstream, downstream, similarly located ones, etc.). I think the only way for all those communities to be successful is to collaborate, creating a higher-level community where open-source communities collaborate for the greater good, which, in my opinion, would be a more open-source world.
The post F43 FESCo Elections: Interview with Fabio Alessandro Locati (fale) appeared first on Fedora Community Blog.
admin )
on 2025-12-17 08:01:00 UTC
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
I have been a member of FESCo for a while now and enjoy doing it. Fedora is really good at bringing in new technologies and ensuring that we minimize disruption for users. I enjoy the technical discussions and working together to ensure that changes account for everything before we bring them in. Making and having a plan is often difficult and requires a lot of coordination.
I am also interested in mentoring people interested in running for FESCo and introducing some changes to how we staff FESCo. There are discussions going on right now for that, but an important thing for me is ensuring we have a succession plan for FESCo that keeps Fedora going without burning people out. If you are interested in being on FESCo, please reach out to me!
Lastly, I feel very strongly about open source software and the licenses we have around it. I believe that it has fundamentally changed our industry and made it a better place. We continue to see changes come in to Fedora that bring challenges to those ideas and I want to ensure that Fedora’s position around open source, creator rights, and licensing are not lost or eroded.
My job at Red Hat is working on the Software Management team. The two big projects on that team are dnf and rpm. But we also have a lot of dnf and rpm adjacent software. I am upstream for or contribute to numerous other projects. I also maintain a variety of packages in Fedora and EPEL as well as RHEL (and by extension CentOS Stream).
I am a sponsor for new contributors and I help mentor new developers in both the community and at Red Hat (that is, developers at Red Hat wanting to participate more in Fedora).
I am a member of the Fedora Council where I focus on engineering issues when we discuss large topics and strategy.
Communication has always been a challenge in our industry and community. We have language differences, cultural differences, and communication medium differences. One thing I notice a lot is that some discussions lead to people taking things personally. Often the root cause of that is people feeling like they are not being heard. A solution I have found is to suggest changing the communication medium. I am perfectly fine communicating over email, or chat, or other online methods. But talking in person can go a long way. We know the value of having in-person events and a lot of people find that their interactions with people in the community improve simply because they finally met someone in person at an event. While that is not always possible, we do have video conference capabilities these days. I do use that in Fedora and it helps quite a bit.
For everyone, if you find yourself in a frustrating situation, I recommend first stepping away and collecting your thoughts. Then remind yourself why everyone is involved in the first place. We all want to achieve the same things, so let’s try to work towards that and find common ground. And if necessary, suggest an alternate communication mechanism.
Most people are surprised to learn that I support protons more than electrons. I like being positive in everything I pursue. It’s ok for us to disagree. It’s ok to have a position, learn something new, and then change that position. The important thing to me is that Fedora ultimately remains a fun project.
My favorite color is orange. I use an Android mobile phone. I do not use current Apple hardware, but I am a big fan of the Apple II series and 68k Macintosh series. If you corner me, I will likely talk your ear off about the Apple IIgs or any Macintosh Quadra (particularly the various crazy and horrible operating systems Apple made for the platform).
The post F43 FESCo Elections: Interview with Dave Cantrell (dcantrell) appeared first on Fedora Community Blog.
admin )
on 2025-12-17 08:00:00 UTC
This is a part of the Fedora Linux 43 FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Wednesday 17th December and closes promptly at 23:59:59 UTC on Wednesday, 7th January 2026.
I think Fedora as a project is in a good place. Our core responsibility is to put out a new release every six months, and we are doing that on schedule and with high quality. But there are always new challenges and issues that need to be solved. As a member of FESCo, I take the Change process seriously, trying to work with submitters to improve their proposals before they are approved, and keeping track of what remains to be done. I do my best to move the things I’m personally working on in the right direction, and I try to help others move the things they are working on.
Most of the proposals that FESCo gets to vote on are obvious. But every once in a while there are proposals which are a mistake. The tough part of the job is to distinguish between something that is risky but will be good for the project if done correctly, and ideas that are a mistake and should be rejected. FESCo is in the position to push back, and needs to do that with enough strength and visiblity to be effective.
The part of being in FESCo that I (and everybody else) likes the least is the slow-as-molasses tickets that get stuck on infrastructure changes or other external constraints. FESCo should do a better job of regularly returning to those, pushing for updates, and figuring out how to finally solve the problem. I like the idea of introducing the limits on consecutive terms of FESCo members
to bring in new people and hopefully use this energy to tackle some long-standing issues.
I maintain systemd and a bunch of other packages in the python scientific stack,
a bunch of tools related to installing Linux (mkosi, pacman, archlinux-keyring), and
tooling for reproducibile builds (add-determinism).
I’m active in FESCo and I contribute to the Packaging Guidelines and in various other places that need help. Over the last year I worked on build reproducibility (https://fedoraproject.org/wiki/Changes/Package_builds_are_expected_to_be_reproducible), bin-sbin unification (https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin), and helped with introduction of nix (https://fedoraproject.org/wiki/Changes/Nix_package_tool).
Discuss. Evaluate. Discuss again. Reach a compromise.
Rarely there is an issue where compromise is not possible. If the issue is worth fighting for, agree to disagree, try to convince everyone else.
n/a
The post F43 FESCo Elections: Interview with Zbigniew Jędrzejewski-Szmek (zbyszek) appeared first on Fedora Community Blog.
admin )
on 2025-12-16 12:00:00 UTC
We're getting heavy attacks on accounts.fedoraproject.org which is impacting the ability to register new accounts. Timeouts are likely, but password reset should work afterwards.
We are investigating and trying to mitigate it.
admin )
on 2025-12-15 08:00:00 UTC
The core motivation behind data analysis pipelines, and the focus of this article, is the need to establish a clear path from unprocessed data to actionable insights for contributor engagement and impact. The key question is “what are we trying to measure to ensure the continuity of community work?”
As a side note, my preparation for the ADSP (Advanced Data Analysis Semi-Professional) certification in Korea utilized RStudio Desktop, running on a Fedora Linux environment. I got hands-on with R’s core statistical toolkit, leveraging base functions. Among these were summary()1 and lm()2 as the basis for fundamental hypothesis testing and regression analysis3. I became more intrigued by R’s power after testing its data manipulation packages (especially the key package dplyr).
With this background in mind, the article focuses on the design of an analysis pipeline that fulfills three objectives:
Establishing such a robust foundation is essential for producing reliable and validated metrics for the contributor community, which itself is subject to ongoing definition and validation.
Acknowledgement: I extend my sincere gratitude to Justin Wheeler for connecting me with the Fedora Data Working Group (FDWG), and to Michael Winters and K Naraian for their guidance, discussion, and support throughout the design and validation of this data analysis pipeline.
Scope and Tool Selection: Please note that this analysis pipeline represents a combination of tools and methods chosen from my perspective as a data analyst, particularly one with a background in the CRM (Customer Relationship Management) domain and consumer electronics industry. Therefore, other analysts or data engineers may utilize different combinations of technologies based on their own expertise or project requirements.
The role of the analyst is undergoing a fundamental transformation in 2025. We are moving beyond the traditional responsibility of performing statistical analysis and presenting visualization on pre-cleaned data. Today, the modern analyst must evolve into a “Data Ops(Operations)”. This requires a holistic understanding of the data lifecycle and bridging the gap between business context and data engineering. This expansion mandates a familiarity with ELT/ETL processes to examine the quality and structure of the data source.
Moreover, data analysts must be adept at processing diverse data types such as semi-structured data (for example, schema-less JSON strings or variant) and understanding various data access methods such as leveraging the efficiency of in-situ processing over the constraints of in-memory loading of datasets.
My ADSP examination requirements motivated my initial deep dive into RStudio. However, it is worth highlighting its utility as a tool for any data professional. The most significant benefit of using RStudio is its seamless ability to leverage the best tools from both the R and Python language ecosystems. This eliminates the need for the analyst to switch environments which leads to dramatically higher operational efficiency. This unified approach streamlines the analysis lifecycle from code execution to final reporting.
Use Python’s libraries like Pandas for efficient ETL/ELT operations, data manipulation on large datasets, and integrating with production environments or machine learning workflows (TensorFlow/PyTorch).
Utilize R’s statistical packages and its superior data visualization capabilities (ggplot2, R Shiny) for data analysis modeling, beautiful reporting, and creating customized, publication-ready graphics.
Install R base packages using the terminal and verify:
$ sudo dnf install R
$ R --version
Now, install RStudio from the Fedora COPR repository. Note that these COPR packages conflict with the binary package provided by Posit. Remove the existing Posit RStudio binary package if you installed it.
$ sudo dnf copr enable iucar/rstudio
$ sudo dnf install rstudio-desktop
Dependencies and dev tools are required so install them:
$ sudo dnf install @development-tools
$ sudo dnf install libxml2-devel openssl-devel curl-devel
Launch the RStudio. When the < prompt appears on the RStudio Console enter the following commands. Note that this prompt should appear in the bottom-left pane of the default layout.
Install the reticulate package and execute the function reticulate::py_install() to manage Python dependencies:
install.packages("reticulate")
reticulate::py_install(packages = c("duckdb", "pandas"))
Set the global options for all code chunks within the R Markdown Canvas:
knitr::opts_chunk$set(echo = TRUE, message = FALSE, warning = FALSE)
ragg is an indirect but critical dependency of core Tidyverse packages (such as ggplot2):
install.packages("ragg")
Install base packages for data manipulation:
install.packages("tidyverse")
DBI, tools for database interface, is an essential R package that provides a standardized, vendor-agnostic interface for connecting to and interacting with various database systems (both local and remote)
install.packages("DBI")
Install tools for Parquet files and S3 data lake access:
install.packages("arrow")
Install R Markdown for combining R code, and install Quarto for combining R/Python/SQL with its execution results, and explanatory text into reproducible data pipelines directly within the environment. The Quarto (.qmd) file runs code chunks in R, Python, and SQL in a single document.
install.packages(c("rmarkdown","quarto"))
Load packages for ELT and EDA:
library(tidyverse)
library(arrow)
The specific dataset chosen, Datanommer (Fedora Messaging Streams), aligns with the strategic objectives of the Fedora Data Working Group, where I contribute. The data is stored in the Bronze Data Layer where raw data from source systems is ingested and stored, as-is, for scalable data lake storage. The Bronze Layer allows for schema evolution without breaking downstream processes.
To provide the Working Group with transparent access and initial insight into this data, I have prepared a shared Initial Exploratory Data Analysis (EDA) Notebook. This notebook serves as the initial public view of the data quality and patterns, and it informed the subsequent architectural decisions for the scalable pipeline I am about to outline.
Given the complexity of the architecture, I will proceed with an outline of the core components, organized by their role in the ELT pipeline:
This restructured pipeline, leveraging the new Lakehouse architecture, unlocks several core benefits crucial for scaling contributor analysis and enabling future insights:
DuckDB acts as a high-performance analytical engine that enables In-Situ Processing. It queries data directly from storage (specifically the Parquet files) without requiring the entire dataset to be loaded into RAM. This not only solves the memory problem but also delivers rapid query execution and significantly lowers operational costs associated with large computational clusters hosted on the OpenShift/Fedora AWS infrastructure.
The shift to a Lakehouse model ensures the pipeline is ready for growth and evolving data complexity. Future integration of Apache Iceberg and Apache Polaris will provide schema evolution capabilities. This ensures the pipeline is fully future-proofed against changes in underlying data structures.
I have redefined the processing workflow from a bottlenecked ETL model to a resilient Extract-Load-Transform (ELT) pattern. Parquet files with the variant type store semi-structured data (like JSON/nested structures), loaded raw into S3, simplifies the ingestion stage. When using R, it is recommended to read Parquet files using the Apache Arrow library.
The parsed data is then accessible by multiple analytical platforms (R Shiny, Python, BI tools) without duplication or manual preparation. This multi-lingual access maximizes the utility of the clean data layer, supporting a growing number of analytical users and more complex queries necessary for defining long-term contributor metrics.
The preliminary Exploratory Data Analysis (EDA) was conducted within the Jupyter Notebook format. This allowed broad compatibility with the existing execution and review environment of the Fedora Data Working Group.
The Initial EDA Notebook is documented to ensure complete reproducibility. This included all necessary steps for the Python library installation and environment setup. Any standard Python script containing ELT logic can be seamlessly run within RStudio’s Python mode or “knitting8” an R Markdown document or rendering a Quarto file.
The establishment of this analysis pipeline represents a crucial step in transforming unprocessed Fedora data into actionable insights. By addressing the core challenges of scaling and in-memory processing through DuckDB, and enabling transparent analysis via the hybrid RStudio/Jupyter workflow, I have demonstrated viable methods for performing Exploratory Data Analysis (EDA) and Extract, Load, Transform (ELT) processes on vast community datasets. In conclusion, the purpose of this work is to foster deeper engagement across a broader community by analyzing data with a view that relates to the Fedora Project community.
I hope this pipeline will serve as the technical foundation that activates and focuses the community discussion around the specific variables and metrics needed to define and ensure the continuity of community contributions.
The ideation, structural planning, and terminology refinement of the pipelines were assisted by Gemini and Figma.
RStudio Desktop 2025.05.1 Build 513 (Fedora COPR repository)
R version 4.5.2 (2025-10-31) / Python 3.14.0
︎︎︎︎︎︎︎︎
admin )
on 2025-12-12 08:00:00 UTC
This article series takes a closer look at interesting projects that recently landed in Copr.
Copr is a build-system for anyone in the Fedora community. It hosts thousands of projects with a wide variety of purposes, targeting diverse groups of users. Some of them should never be installed by anyone, some are already transitioning into the official Fedora repositories, and others fall somewhere in between. Copr allows you to install third-party software not found in the standard Fedora repositories, try nightly versions of your dependencies, use patched builds of your favourite tools to support some non-standard use-cases, and experiment freely.
If you don’t know how to enable a repository or if you are concerned about whether is it safe to use Copr, please consult the project documentation.
Vicinae is a fast application launcher written in C++/QT. Inspired by tool Raycast, it provides instant app and file search and clipboard history. It also includes built-in utilities such as a calculator and web search, along with support for extensions written in TypeScript. It is designed to be highly responsive and native for Wayland environment. Therefore, if you like keeping your hands on the keyboard or want a customizable, extensible launcher for your desktop, Vicinae may be worth trying.
The repo currently provides vicinae for Fedora 42, 43, and Fedora Rawhide. To install it, use these commands:
sudo dnf copr enable scottames/vicinae
sudo dnf install vicinae
UZDoom is a modern DOOM source port that builds upon classic GZDoom engine, offering hardware-accelerated rendering, an updated scripting system, improved mod support, and high-quality audio playback. At the same time, it maintains compatibility with classic WAD files while making the experience smooth on current systems.
Whether you are playing the original episodes or diving into extensive mod packs, UZDoom offers a convenient way to enjoy them.
The repo currently provides uzdoom for Fedora 42, 43, and Fedora Rawhide. To install it, use these commands:
sudo dnf copr enable nalika/uzdoom
sudo dnf install uzdoom
Plasma Panel Colorizer is a widget for KDE Plasma that allows you to customize the panel’s appearance. In addition, it offers options for background tinting, blur, custom opacity levels, shadows, floating panels, or themes that differ from the stock Plasma look. It also includes full blur support and is updated for Plasma 6, making it easy to adjust your panel exactly the way you want.
The repo currently provides plasma-panel-colorizer for Fedora 42, 43, and Fedora Rawhide. To install it, use these commands:
sudo dnf copr enable peridot-augustus/plasma-panel-colorizer
sudo dnf install plasma-panel-colorizer
Sfizz-ui is the graphical interface for the sfizz sampler engine, which is an open-source player for SFZ instrument libraries. The UI provides an accessible way to load SFZ instruments, adjust parameters, and integrate the sampler into your workflow. It also includes plugin support such as LV2 and VST3, making it suitable for music creation in a Linux DAW environment.
For musicians, sound designers, or anyone using SFZ sample libraries, sfizz-ui offers a polished interface.
The repo currently provides sfizz-ui for Fedora 41, 42, and 43. To install it, use these commands:
sudo dnf copr enable lexridge/sfizz-ui
sudo dnf install sfizz-ui
Element Matrix services will be upgrading our fedora.im and fedoraproject.org servers to use the new Matrix Authentication Server. This will allow clients to use the new element X and similar clients.
During the outage matrix servers will be unavailable, but messages will be received after the outage is …
admin )
on 2025-12-10 08:00:00 UTC
Generative AI systems are changing the way people interact with computers. MCP (model context protocol) is a way that enables LLMs to run commands and use tools to enable live, conversational interaction with systems. Using the new linux-mcp-server, let’s walk through how you can talk with your Fedora system for understanding your system and getting help troubleshooting it!
Large language models (LLMs) can be an invaluable tool when investigating an issue on a Linux system. However, this can involve a lot of copy/pasting of information from the Linux terminal into a web based interface to an LLM model.
The model context protocol (MCP) acts as a bridge, enabling LLMs to interact with external tools and data sources. The linux-mcp-server utilizes this protocol to give LLMs the ability to interact with a Fedora Linux system. Instead of you manually copying and pasting terminal output, the linux-mcp-server enables the LLM to directly query system information and log entries.
By enabling an LLM direct access to system information and logs, it is transformed into an active part of the investigation process when troubleshooting an issue. It empowers an LLM to directly query the system state, allowing it to help identify performance bottlenecks, and identify important log entries that might be missed by a manual review.
Anthropic introduced MCP in November 2024 as an open standard for LLM tool use. This provides a way for LLMs to interact with outside systems and data sources.
Prior to MCP, there wasn’t as strong a standard and ecosystem for LLM systems to call tools. LLMs were thus frequently limited to have only the information contained in their training. They were isolated from the outside world. For example, if you asked an LLM “what is the weather going to be next week”, the LLM would respond with a message indicating that it doesn’t know what the weather will be, as it doesn’t have access to that information. MCP helps solve this problem by enabling a standardized way for an LLM to access an outside data source, such as the weather forecast.
At a high level, users can use an AI agent application, such as Goose (open source), or Claude Desktop, and specify which MCP servers they would like to use. The AI agent application informs the LLM that there are tools available via these MCP servers that can be used to help answer the requests from the user. The LLM model can then decide when to invoke these tools.
MCP is an open standard. You have the flexibility to use MCP servers, such as linux-mcp-server, with either open source-licensed LLM models, or hosted proprietary LLM models.
The linux-mcp-server is a project started by Red Hat’s RHEL Engineering team. It provides a number of tools that enable an LLM to query information from a Linux system, such as system info, service information and logs, process information, journald and other logs, network information, and storage and disk information. For a full list of the tools provided, refer to the project’s Github page.
These tools, provided by linux-mcp-server, are focused on providing the LLM access to read-only information. In the future, we’ll be exploring expanding past these read-only use cases.
The linux-mcp-server can be used to interact with the local Fedora Linux system that it is running on. It can also be used to interact with remote Fedora Linux systems over SSH. For example, if you have SSH key authentication setup with the remote systems, you could make a request to your AI agent application such as “Determine the current memory usage on the fedora1.example.com, fedora2.example.com, and fedora3.example.com servers”.
The main components needed are an AI agent application, access to LLM model inference, and the linux-mcp-server.
There are a number of options for the AI agent application, both open source and proprietary. An example of an open source AI agent is Goose, which provides an RPM that can be installed on Fedora.
There are several LLM model inference options, ranging from locally hosted open source models, to proprietary hosted LLM models. If hosting a model locally, you generally need to have GPU/accelerator hardware available. Open source tools that can be used to locally host LLM models include RamaLama, llama.cpp, and Ollama. There are a number of open source LLM models capable of tool calling. These include models such as gpt-oss-20b and Granite 4 small.
Once you’ve installed your preferred AI agent application, the next step is to install the linux-mcp-server and configure your AI agent application to use it. The linux-mcp-server Github page includes installation instructions, and configuration details for Goose and Claude Desktop.
NOTEThe example scenarios below include LLM generated output. The output is presented here as it was generated by the AI systems cited so you can assess the quality of the output they are capable of, particularly in a non-cloud, self-hosted scenario.
The sample LLM output provided here is not intended to be run by readers without the same level of review we recommend anyone perform on AI generated content prior to use on their systems.
Has this happened to you? Time to hop on a call and give a demo. You’re pumped. It’s your go-time aaaaand… your system starts lagging. Folks on the call say your video is choppy or they can’t understand you. OH NO.
You’ve got to assess what’s up, quickly. Run `top`, check `dmesg`, check your network connection (read the man page for `netstat` because you can’t remember the flag you want), check `journalctl`, cross-reference what you’re seeing, then start killing processes, restarting services, reloading kernel modules willy-nilly based on hastily-crafted theories, see if it improves…
This is a case where you could actually ask the system to tell you why it’s slow and give it the ability to do the analysis via linux-mcp-tools. The LLM you connect with won’t just run the commands through the MCP server; it will understand what the numbers it gets means in context and be able to explain in human terms.
So let’s start working with a relatively new laptop. It’s a Thinkpad T14S with the AMD Ryzen
AI Pro 7 ( Ryzen AI 360 chip.) Recently one of the wifi networks it must connect to regularly was upgraded. It now has issues with the network connection stability. So let’s talk to Goose + gpt-oss:20b + linux-mcp-server about it. Here’s the initial prompt I used:
My Wifi doesn't work very well. It cuts out after a few minutes. Help me fix it. Can you find the error messages in the system logs and diagnose the problem?
It responded with the following:
I'll help you diagnose your WiFi connectivity issues by examining the system logs for error messages related to your network interfaces and wireless connectivity. Let me start by gathering information about your system and checking the relevant logs.
LLM output I’ll help you diagnose your WiFi connectivity issues by examining the system logs for error messages related to your network interfaces and wireless connectivity. Let me start by gathering information about your system and checking the relevant logs.
It then made a series of tool calls, including Get System Information, Get Network Interfaces, Get Journal Logs, Get Hardware Information, Get Service Status service_name:NetworkManager, Get Service Status service_name:wpa_supplicant, Read Log File. The result was this analysis, which is the actual problem I was hoping it could find!
LLM output 
Problem SummaryYour ATH12K PCI (Qualcomm 802.11ax) wireless card repeatedly reports
ath12k_pci 0000:c2:00.0: failed to enqueue rx buf: -28
every few minutes, which triggers a drop of the wireless link. The driver is trying to enqueue an RX buffer for the hardware but fails with errno ‑28.
‑28 →
(out‑of‑memory for the driver buffer); the kernel cannot allocate a DMA‑coherent RX descriptor.-ENOMEM
Likely Root Causes| Cause | Evidence / Typical Scenario | Fix / Work‑around |
|---|---|---|
| Driver bug or missing patch | The kernel’s ath12k driver has had a long‑running issue with RX ring management in older 5.15/5.4 series. | Update the kernel or apply the latest patch from the
linux ath12k |
| Out‑of‑memory in the driver | The error itself is “‑28” – a memory‑allocation failure inside the driver. | Reduce the number of RX descriptors, or enable fast‑RX disabled mode (
modprobe ath12k_pci ath12k_pci_disable_fast_rx=1 |
| Firmware mismatch / corruption | Old firmware (
ath12k_hwgen |
Reinstall firmware from your distro (
sudo apt‑install --reinstall linux‑firmware |
| System memory pressure | If many big processes run, DMA‑coherent memory pool can be exhausted. | Free RAM, close memory‑heavy apps, or add swap. |
| ACPI/PCIe power‑management quirk | Some laptops throttle the Wi‑Fi device after idle, resetting the buffer queue. | Add
pci_bus_reset = off ath12k_pci_disable_ps=1 |
| Hardware issue (e.g., faulty PCIe slot or NIC) | Persistent failure after multiple driver/kernel upgrades. | Test on another machine/PCIe slot or replace the card. |
Diagnostic Checklistuname -r
modinfo ath12k_pci | grep ^version:
cat /sys/module/ath12k_pci/parameters/*
– See if
ls /lib/firmware/ath12k/ath12k/ar9009/ | grep wlan0 | head
– If the files are missing or older than the driver, copy newer ones from
sudo dmesg --ctime | grep -A3 'ath12k_pci 0000:c2:00.0'
– Observe if there are any other “-ENOMEM” or “resource exhaustion” messages.
free -h
vmstat 1 5
sudo lspci -vvv -s c2:00.0 | grep -iE "link|latency"
Quick‑Fix Path (Try in this order)| Step | Command | What it does |
|---|---|---|
| 1 |
|
Refresh firmware to the latest distro version. |
| 2 |
|
Apply latest kernel with patched ath12k driver (or switch to 5.18+ if still on 5.15). |
| 3 |
|
Force the driver to use a more conservative RX scheme. |
| 4 | Reboot and monitor:
dmesg -T | grep ath12k_pci |
Verify the error disappears. |
| 5 | Optional: test on another machine or use a USB‑WiFi dongle (USB 802.11ax / 802.11ac) as a temporary workaround. | Ensure the issue is not hardware‑specific. |
**Tip:** After reboot, you can also verify driver parameters:
Advanced Debugging (if basic fixes don’t help)sudo bash -c 'echo 1 > /sys/module/ath12k_pci/parameters/debug'
sudo dmesg -T | grep ath12k
sudo lspci -vv -s c2:00.0
sudo ethtool -S wlp4s0
grep -i 'ath12k' /var/log/syslog
Bottom LineThe “failed to enqueue rx buf: –28” is an internal driver allocation failure that typically follows one of two paths:
If you're still stuck after following the quick‑fix path, it's worth capturing more detailed logs with the above diagnostic commands and sharing them. We can then cross‑reference the exact kernel version/driver commit to see if a known patch exists.
Feel free to let me know which step you’ve tried or if you encounter any new log messages, and we’ll dig deeper!
Not too bad an analysis and set of debugging steps! I’ll follow up in the comments and let you know if the solution works.
Trawling through `du` on the command line, converting the numbers in your head, sorting them – it can be tedious. We even have graphical tools like `baobab`, but it takes time to load in the results and explore the data. And sometimes you might have questions it can’t answer in terms of the risk of deleting a specific directory, or the age of a specific file. It’s easier to be sloppy and just let the disk fill up. But there comes a time where that is no longer an option.
You can ask the system using the linux-mcp-server to analyze your disk usage, give you a hitlist of the top space-eating places on the file system, and give you advice with a risk analysis of how to clean it up.
Here’s my prompt:
I need help analyzing disk usage on my system. Can you: 1. Show me the current disk usage across all filesystems using get_disk_usage 2. Use list_directories_by_size to show me the 10 largest directories (this will help identify where disk space is being consumed) 3. Check if there are any large log files consuming space using get_journal_logs or read_log_file 4. Review running processes with list_processes to see if any are consuming excessive resources or creating temporary files After gathering this information, help me identify potential space-saving opportunities and assess the safety of cleaning up specific directories. Please don't only examine top-level directories. I want you to go deep if needed to find out where the largest files are!
I ran this prompt on my Fedora 42 system using linux-mcp-server with Goose connected to locally-served gpt-oss:20b, and here’s the output I got:
LLM output Disk‑space overview (as of Nov 24 2025 15:21)
| Filesystem | Size | Used | Avail | Use % | Mounted on |
| /dev/mapper/luks‑61cedb0e… | 952.3 GB | 548.9 GB | 399.6 GB | 57.9 % | / |
| /dev/mapper/luks‑61cedb0e… | 952.3 GB | 548.9 GB | 399.6 GB | 57.9 % | /home |
| /dev/nvme0n1p2 | 973.4 MB | 462.8 MB | 443.4 MB | 51.1 % | /boot |
| /dev/nvme0n1p1 | 598.8 MB | 19.3 MB | 579.6 MB | 3.2 % | /boot/efi |
Overall usage is comfortably below 60 % of a 952 GB volume, so immediate capacity pressure isn’t a concern. The biggest contributors to disk space today are in the ~/. hierarchy.
| Path (relative to the mount point) | Size (≈) | Notes |
| ~/ – User home (2 mounts: /home + /) | 1 TB total | 57 % used; the bulk of the space is in ~/ |
| ~/duffy/.local/share | 238 GB | Containers sub-dir, followed by Trash (7GB) – typical podman/docker container images |
| ~/duffy/.local/share/containers | 238 GB | Container layers, images, root filesystems – the prime candidate for cleanup |
| ~/duffy/.local | 266 GB | share (237 GB) dominates it |
| ~/duffy/.local/share/containers (inside share) | 238 GB | Same as above – just a different view |
| ~/duffy/.local/lib | 13 GB | Likely a virtual‑environment library set |
| ~/duffy/.local/bin | 4 GB | Helper binaries |
| ~/duffy/.local/share/Trash | 7 GB | User‑deleted items still resident on disk |
| ~/duffy/.local/share/containers (nested) | 238 GB | Same as above; redundant listings from recursive depth‑1 scans |
| ~/duffy/.local/share (top‑level) | 238 GB | containers is the absolute largest item |
Take‑away – 75 % of the 238 GB live inside three nested directories:
| Category | Recommendation | Rationale |
| Containers | podman system prune -a (or docker system prune -a if Docker is in use) | Removes unreferenced images, containers, and caches. This can reclaim 200–250 GB if most containers are outdated or no longer referenced. |
| Trash | gio trash –empty | The 7 GB in Trash is still taking physical space; simply emptying it will free that amount. |
| Large libs/binaries | Check ~/duffy/.local/lib – 13 GB, and ~/duffy/.local/bin – 4 GB | If these are not actively used by a project, consider uninstalling or moving them to a secondary, less‑frequented store. |
| Ramalama & UV | 9 GB (ramalama), 8 GB (uv) | Possibly temporary files or caches from development tools. Inspecting the contents of these directories (du -h) can reveal if they are still needed. |
| Other caches | pnpm store prune, virtualenv or pip cache purge | Development tool caches often accumulate; they’re usually safe to delete once you’re done with the current development sessions. |
| Logs | The system journal shows normal activity, and syslog access is blocked by policy. | Systemd journal stores are rotated automatically; no urgent action required. |
| Boot partitions | Not relevant – they’re low‑usage (boot/efi only 3 % used). | No action needed. |
# 1. Empty Trash
gio trash --empty
# 2. Prune unused containers/images
podman system prune -a # or docker system prune -a
# 3. Remove leftover caches
pnpm store prune # if pnpm is installed
pip cache purge # for Python
virtualenv --clean # optional
# 4. Inspect large “RAM” directories manually if you need deeper cleanup
du -h --max-depth=1 ~/duffy/.local/share/containers
Tip: After each step run df -h /home or du -sh ~/duffy/.local/* to see the impact.
| Action | Why it’s safe (or risk) |
| Emptying Trash | Deletes only user‑deleted files; confirm you don’t need the content. |
| podman system prune -a | Deletes container images, containers, and volumes that are not referenced by any running or stopped container. Verify with podman ps -a before pruning. |
| Removing lib/bin from .local | Only safe if you’re sure those libraries/bin files aren’t part of a running application. |
| Caution with tmpfs or moving large directories | If you move a directory on‑the‑fly, ensure no running application depends on that path. |
Feel free to ask what next steps you’d like to dig into (e.g., detailed contents of the containers dir, specific application logs, or targeted pruning commands).
So you may have noticed a little detail above – the system is a Fedora 42 system… and Fedora 43’s been out a month now! 
So, time to upgrade.
This example shows where we have some tools missing from the set provided in the linux-mcp-server. We’re including it for two reasons:
Here’s the prompt I started with, with the same Goose + gpt-oss:20b + linux-mcp-server combination:
You are a Linux system administrator assistant analyzing a Fedora system for upgrade readiness. TASK: Examine this Fedora 42 system and provide a comprehensive upgrade readiness report for Fedora 43. ANALYSIS CHECKLIST: 1. Check current Fedora version: cat /etc/fedora-release 2. Review system updates status: dnf check-update 3. Identify third-party repositories: dnf repolist 4. List installed packages from non-Fedora repos: dnf list installed | grep -v @fedora 5. Check for broken dependencies: dnf check 6. Review disk space on root partition: df -h / 7. Check for unsupported or deprecated packages 8. Identify custom kernel modules: lsmod | grep -v "^Module" 9. Review SELinux status: sestatus 10. Check for pending system updates: dnf upgrade --refresh --assumeno REPORT FORMAT: # Fedora 43 Upgrade Readiness Report ## Current System Status - Fedora version: [version] - Kernel: [kernel version] - Updates status: [current/outdated] ## Potential Issues [List blocking issues with HIGH/MEDIUM/LOW severity] ## Third-Party Software [List non-Fedora packages that may need attention] ## Recommendations [Specific pre-upgrade steps needed] ## Overall Readiness: [READY/NEEDS ATTENTION/NOT READY] Run the necessary commands and provide this analysis. Be specific about any issues found and give actionable recommendations.
Now, right away the model came back to me to complain it doesn’t have access to `dnf`, `cat`, etc. And that’s expected here. What it did was give me a list of homework to run for it to complete the analysis… for example, `dnf check-update` and `cat /etc/fedora-release`. I had a little back and forth in Goose with the model where it would ask me to run a command and I’d copy the output into the context. This resulted, finally, in the following report:
LLM output Analyzed System – Fedora 42 (Kernel 6.17.7‑200.fc42.x86_64)
Date – 2025‑11‑24
| Item | Value |
| Fedora release | 42 (Adams) |
| Kernel | 6.17.7‑200.fc42.x86_64 |
| Root filesystem | 953 GB LUKS, 58 % used (411 GB free) – > 15 % free |
| /var /usr | Same as root partition (mounted the same LUKS device) |
| SELinux | enabled (policy targeted), currently permissive |
| System‑wide packages | No held packages (dnf versionlock list empty) |
| System modules | No modules held. |
TL;DR – The base system is clean; the kernel is up‑to‑date for 42, there is ample disk space, and there are no version‑locked packages.
| Repository | Description | Current dnf repolist status |
| rpm-fusion-free, rpm-fusion-nonfree, rpm-fusion-updates | Widely used RPM‑Fusion components | Enabled |
| google-cloud-cli | Google Cloud SDK (RPM built for EL 10) | Enabled |
| visual-studio-code | Microsoft VS Code RPMs | Enabled |
| command‑line‑assistant, google‑chrome, PyCharm, unsupported‑fedora‑packages, goose, leaktk | Various Copr builds (mostly Fedora‑42 based) | Enabled |
What we need to verify
| Issue | Severity | Why it matters | Immediate Remedy |
| Non‑Fedora packages (e.g., google‑cloud‑cli) | MEDIUM | May contain packages built for EL 10; could conflict with Fedora 43 libs. | Verify if a Fedora 43 build exists or plan to remove/re‑build it. |
| Third‑party repos without 43 builds | MEDIUM | dnf system-upgrade pulls all enabled repos; lacking 43 packages causes transaction failure. | Disable such repos temporarily (dnf config-manager –set-disabled <repo>) or enable the 43 stream when available. |
| Custom kernel modules | LOW | Modules compiled against 42 kernel won’t load on 43; services may drop. | Re‑compile or patch modules after upgrade. |
| Broken dependencies reported by dnf check | HIGH | Would block the upgrade transaction. | Run sudo dnf check now; fix any reported issues. |
| Insufficient disk space | HIGH | Upgrade scripts need > 15 % free. | Not an issue (58 % free). |
Current High‑Risk Items – None detected yet.
Next Action – Confirm each third‑party repo has 43‑compatible packages and set SELinux to enforcing.
| Step | Command | Purpose |
| Confirm 43‑stream packages | `dnf list –available * | grep <repo-id>` |
| Verify SELinux enforcement | sestatus | Should show enforcing. |
| Check for broken dependencies | sudo dnf check | No errors should appear. |
| Refresh all repos | sudo dnf upgrade –refresh | Pull latest metadata. |
| Dry‑run upgrade | sudo dnf system-upgrade download –releasever=43 –allowerasing | Detect any missing packages or conflicts. |
| Optional: Disable problematic repos | sudo dnf config-manager –set-disabled <repo> | Prevent upgrade crash if a repo has no 43 build. |
| Persist SELinux config | sudo sed -i ‘s/SELINUX=permissive/SELINUX=enforcing/’ /etc/selinux/config | Make enforcement permanent. |
| Criteria | Status | Comment |
| Disk space | Ready | 58 % free |
| Package health | Ready | No held or broken packages |
| Third‑party repos | Conditional | Verify 43‑compatibility |
| Custom modules | Pending | Need to identify modules and re‑compile |
| Final verdict | READY (after addressing above points) |
Next step – Run the three verification commands below and share the output with me:
sudo dnf check
sudo dnf repolist
dnf list installed | grep -v @fedora
With those outputs I can pinpoint any remaining blockers and give you a final, ready‑to‑proceed plan.
Happy upgrading!
You can see from these few examples that tool calling with LLMs is a valuable tool for troubleshooting Linux systems. We could use your help building this and making it awesome! How can you help?
Join us upstream at https://github.com/rhel-lightspeed/linux-mcp-server! And come chat with us in the Fedora AI/ML SIG chat room on Matrix!
admin )
on 2025-12-10 07:00:00 UTC
This outage impacts the Fedora Copr Frontend. Seems like these bots were attracted by our outage announce: Baudispider, YandexBot, ClaudoBot, AmazonBot, Presto, https://openai.com/bot TikTokSpider, which are currently DDoSing us and causing performance degradation.
admin )
on 2025-12-09 08:00:00 UTC
Apply now for the Flock to Fedora 2026 Call for Proposals (CfP) at cfp.fedoraproject.org. This year, the submission deadline for the Flock CfP is Monday, February 2nd, 2026.
Last month we announced that we’ll be convening again in Prague for Flock 2026 in June. Everyone interested in attending can head over to the Flock 2026 website and register today! For those of you who want to contribute to Flock by presenting your thoughts and ideas in front of your fellow contributors, we’ve got some inspiration for you in the form of updated proposal themes.
This year’s proposal themes are inspired by Fedora’s four foundations:
These themes are here to help get you thinking about topics you’d like to present. If you have something you want to talk about that doesn’t quite fit neatly into these themes, but you feel it belongs at Flock, go ahead and submit anyways! The reviewers are open to alternative topics. They are on the look out for topics that Fedora contributors are interested in discussing.
Financial travel assistance applications are now open as well. When you go to register to attend on the Flock 2026 website, you should also see links on how to apply for travel assistance if you need it. Financial assistance will be open until March 8th (several weeks after CfP closes on Febuary 8th). This is to give those with accepted talks an opportunity to figure out if they’ll need travel assistance.
admin )
on 2025-12-08 13:00:00 UTC
We will be powering off hardware in our rdu2 datacenter, it will be deracked and moved to our rdu3 datacenter, reracked, and reconfigured for the new network.
retrace/abrt/faf will be down and not accepting user reports smtp-auth-cc-rdu01 will be down and not accepting emails download-cc-rdu01 will be down …
admin )
on 2025-12-06 16:30:00 UTC
There is heavy scraper activity cauing high load and slow load times on https://src.fedoraproject.org.
We are investigating and trying to mitigate it.
The issue was scrapers hitting /history/ and /blame/ endpoints recursively. We have at least for now blocked those endpoints. Please git clone locally if you …
admin )
on 2025-12-05 15:43:00 UTC
TL;DNR: The Fedora Linux 43 Election schedule has been extended. Voting will now take place from 15 December 2025 through 7 January 2026.
Due to unforeseen delays in the interview coordination process, we are adjusting the election timeline. To ensure all candidates have ample opportunity to present their platforms and the community has sufficient time to vote, the election period will now extend through the year-end holidays.
Please mark your calendars with the following new critical dates:
New Election ScheduleTransparency is an important value of the Fedora Project, and I want to provide context on why this shift was necessary. I recently returned from two weeks of bereavement leave on Wednesday, 3 December. During my absence, the coordination work required to collect and process nominee interviews for the Fedora Engineering Steering Committee (FESCo) did not occur as originally planned.
Consequently, we missed the window to launch the elections today, Friday, 5 December. Rather than rushing the process, we are opting to extend the timeline. This ensures that our candidates are properly featured and that the election remains fair and accessible to all voters, despite the holiday season overlap.
The official Fedora schedule calendar is being updated to reflect these changes shortly. Thank you for your patience and understanding.
The post Important Update: Fedora Linux 43 Election Schedule Extended appeared first on Fedora Community Blog.
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: December 1 – December 5 2025
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
Updates of the team responsible for Fedora Forge deployment and customization.
Ticket tracker
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 49 appeared first on Fedora Community Blog.
Planned Outage - pagure.io migration - 2025-12-03 21:00-23:00 UTC
We will be migrating pagure.io to a new network in our rdu3 datacenter. All services on pagure.io will be taken down, all data synced, and then services will be restored on the new server/datacenter. IP addresses for …
admin )
on 2025-12-02 12:00:00 UTC
The FreeIPA WebUI became new interface for freeipa
The post Test Day:2025-12-02 FreeIPA-WebUI Test Day appeared first on Fedora Community Blog.
We're updating Copr servers to F43
This outage impacts the copr-frontend and the copr-backend.
It’s finally here. We have an end date for OpenID in Fedora. The date is 1st May 2026. You can see it on the banner on https://id.fedoraproject.org/openid and it will be shown to you every time when trying to authenticate with OpenID. The date 1st May 2026 should give anybody still using OpenID authentication enough time to migrate to OpenID Connect.
We started our move to OpenID Connect and away from old OpenID authentication 4 years ago. This was a long road with plenty of obstacles on the way. We first ported all apps we own in Fedora Infrastructure to OpenID Connect. That took time, but we had at least control over these applications.
After porting all our applications we started to look at the application using OpenID authentication outside of Fedora ecosystem. This proved to be really difficult as those clients don’t need to register with Fedora Authentication System.
After some failures to contact the projects that we at least identified to use OpenID in Fedora, we decided that the best course of option is to separate the OpenID authentication system (the service that is providing it is called Ipsilon, which we want to decommission as well). I spent the last two months working on separating the OpenID authentication from OpenID Connect and SAML2. You can see the result on https://id.fedoraproject.org/openid.
This will now allow us to replace Ipsilon for both OpenID Connect and SAML2 and as most of the separation logic is in proxies, we should have no issue to reuse that for the new solution. This should resolve plenty of issues we are experiencing with current authentication system and let us remove one service from the portfolio of services we own in Fedora Infrastructure. We are looking forward to brighter future!
The post End of OpenID in Fedora appeared first on Fedora Community Blog.
admin )
on 2025-11-21 15:38:20 UTC
You attended the F43 Virtual Release Party!
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 17 November – 21 November 2025
This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker
Updates of the team responsible for Fedora Forge deployment and customization.
Ticket tracker
Minor update of FMN from 3.3.0 to 3.4.0
Minor update of FASJSON from 1.6.0 to 1.7.0
Minor update of Noggin from 1.10.0 to 1.11.0
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update – Week 47 appeared first on Fedora Community Blog.
We will be updating and rebooting various servers. Services will be up or down during the outage window.
admin )
on 2025-11-20 12:00:00 UTC
Hi,
I’m Jef, the Fedora Project Leader.
As FPL I believe Fedora needs to be part of a healthy flatpak ecosystem. I’d like to share my journey in working towards that over the last few months with you all, and include some of the insights that I’ve gained. I hope by sharing this with you it will encourage those who share my belief to join with me in the journey to take us to a better future for Fedora and the entire ecosystem.
First, my immediate goal is to get the Fedora ChangeProposal that was submitted to make Flathub the default remote for some of the Atomic desktops accepted on reproposal. I believe implementing the idea expressed in that ChangeProposal is the best available option for the Atomic desktops that help us down the path I want to see us walking together.
There seems to be wide appeal from both the maintainers of specific Fedora outputs, and the subset of Fedora users of those desktop outputs, that using Flathub is the best tradeoff available for the defaults. I am explicitly not in favor of shuttering the Fedora flatpaks, but I do see value in changing the default remote, where it is reasonable and desirable to do so. I continue to be sensitive to the idea that Fedora Flatpaks can exist because it is delivering value to a subset of users, even when it’s not the default remote but still targeting an overlapping set of applications serving different use cases. I don’t view this as a zero-sum situation; the important discussion right now is about what the defaults should be for specific Fedora outputs.
There is a history of change proposals being tabled and then coming back in the next cycle after some of the technical concerns were addressed. There is nothing precedent-setting in how the Fedora Engineering Steering Committee handled this situation. Part of getting to the immediate goal, from my point of view, was doing the due diligence on some of the concerns raised in the FESCo discussion leading to the decision to table the proposal in the last release. So in an effort to get things in shape for a successful outcome for the reproposal, I took it on myself to do some of the work to understand the technical concerns around the corresponding source requirements of the GPL and LGPL licenses.
I felt like we were making some good progress in the Fedora discussion forums back in July. In particular, Timothee was a great help and wrote up an entirely new document on how to get corresponding sources for applications built in flathub’s infrastructure. That discussion and the resulting documentation output showed great progress in bringing the signal to noise ratio up and addressing the concerns raised in the FESCo discussion. In fact, this was a critical part of the talk I gave at GUADEC. People came up to me after that talk and said they weren’t aware of that extension that Timothee documented. We were making some really great progress out in the open and setting a stage for a successful reproposal in the next Fedora cycle.
Okay, that’s all context intended to help you, dear reader, understand where my head is at. Hopefully we can all agree my efforts were aligned with the goal leading up to late July. The next part gets a bit harder to talk about, and involves a discussion of communication fumbles, which is not a fun topic.
Unfortunately, at GUADEC I found a different problem, one I wasn’t expecting to find. Luckily, I was able to communicate face to face with people involved and they confirmed my findings, committed on the spot to get it fixed, and we had a discussion on how to proceed. This started an embargo period where I couldn’t participate in the public narrative work in the community I lead. That embargo ended up being nearly 3 months. I don’t think any of us who spoke in person that day at GUADEC had any expectation that the embargo would last so long.
Through all of this, I was in communication with Rob McQueen, VP of the Gnome Foundation, and one of the Flathub founders, checking in periodically on when it was reasonable for me to start talking publicly again. It seems that the people involved in resolving the issues took it so seriously that they not only addressed the deficiencies I found -missing files- but committed to creating significant tooling changes to help prevent it from happening again. Some characterized that work as “busting their asses.” That’s great, especially considering much of that work is probably volunteer effort. Taking the initiative to solve not just the immediate problem, but building tooling to help prevent it is a fantastic commitment, and in line with what I would expect from the volunteers in the Fedora community itself. We’re more aligned than we realize I think.
What I’ve learned from this is there’s a balance with regard to embargos that must be struck. Thinking about it, we might have been better served if we had agreed to scope the embargo at the outset and then adjusted later with a discussion on extending the time further, that also gave me visibility into why it was taking additional time. It’s one of the ideas I’d like to talk to people about to help ensure this is handled better in the future. There are opportunities to do the sensitive communications a bit better in the future, and I hope in the weeks ahead to talk with people about some ideas on that.
Now with the embargo lifted, I’ve resumed working towards a successful change reproposal. I’ve restarted my investigation of corresponding source availability for the runtimes. We lost 3 months to the embargo, but I think there is still work to be done. Already, in the past couple of weeks, I’ve had one face to face discussion with a FESCo member, specifically about putting a reproposal together, and got useful feedback on the approach to that.
So that’s where we are at now. What’s next?
I am still working on understanding how source availability works for the Flathub runtimes. I think there is a documentation gap here, like there was for the flatpak-builder sources extension. My ask to the Fedora community, particularly those motivated to find paths forward for Flathub as the default choice for bootc based Fedora desktops, is to join me in clarifying how source availability for the critical FLOSS runtimes works so we can help Flathub by contributing documentation that all Flathub users can find and make use of.
Like I said in my GUADEC talk, having a coherent (but not perfect) understanding of how Fedora users can get the flatpak corresponding sources and make local patched builds is important to me to figure out as we walk towards a future where Flathub is the default remote for Fedora. We have to get to a future where application developers can look at the entire linux ecosystem as one target. I think this is part of what takes the Linux desktop to the next level. But we need to do it in a way that ensures that end users have access to all the necessary source code to stay in control of their FLOSS software consumption. Ensuring users have the ability to patch and build software for themselves is vital, even if it’s never something the vast majority of users will need to do. Hopefully, we’re just a couple more documents away from telling that story adequately for Flathub flatpaks.
I’ve found that some of the most contentious discussions can be with people with whom you actually have a significant amount of agreement. Back in graduate school, when my officemate and I would talk about anything we both felt well-informed about and were in high agreement on: politics, comic books, science, whatever it was.. we’d get into some of the craziest, heated arguments about our small differences of opinion, which were minor in comparison to how much we agreed on. And it was never about needing to be right at the expense of the other person. It was never about him proving me wrong or me proving him wrong. It was because we really deeply wanted to be even more closely aligned. After all, we valued each other’s opinions. It’s weird to think about how much energy we spent doing that. And I get some of the same feeling that this is what’s going on now around flatpaks. Sometimes we just need to take a second and value the alignment we do have. I think there’s a lot to value right now in the Fedora and Flathub relationship, and I’m committed to find ways both communities can add value to each other as we walk into the future.
The post A statement concerning the Fedora and Flathub relationship from the FPL appeared first on Fedora Community Blog.
You dropped by the Fedora booth at FOSDEM '26
admin )
on 2025-11-14 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 10th – 14th November 2025
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 46 2025 appeared first on Fedora Community Blog.
admin )
on 2025-11-14 08:00:00 UTC
We did it again, Fedora at Kirinyaga university in Kenya. This time, we didn’t just introduce what open source is – we showed students how to participate and actually contribute in real time.
Many students had heard of open source before, but were not sure how to get started or where they could fit. We did it hands-on and began with a simple explanation of what open source is: people around the world working together to create tools, share knowledge, and support each other. Fedora is one of these communities. It is open, friendly, and built by different people with different skills.
We talked about the many ways someone can contribute, even without deep technical experience. Documentation, writing guides, design work, translation, testing software, and helping new contributors are all important roles in Fedora. Students learned that open source is not only for “experts.” It is also for learners. It is a place to grow.
After the introduction, we moved into a hands-on workshop. We opened Fedora Docs and explored how documentation is structured. Students learned how to find issues, read contribution instructions, and make changes step-by-step. We walked together through:
By the end of the workshop, students had created actual contributions that went to the Fedora project. This moment was important. It showed them that contributing is not something you wait to do “someday.” You can do it today.
“This weekend’s Open Source Event with Fedora, hosted by the Computer Society Of Kirinyaga, was truly inspiring! 
Through the guidance of Cornelius Emase, I was able to make my first pull request to the Fedora Project Docs – my first ever contribution to the open-source world. 
”
– Student at Kirinyaga University
Huge appreciation to:
And to everyone who played a part – even if your name isn’t listed here, I see you. You made this possible.
The students showed interest, curiosity, and energy. Many asked how they can continue contributing and how to connect with the wider Fedora community. I guided them to Fedora Docs, Matrix community chat rooms, and how they can be part of the Fedora local meetups here in Kenya.
We are introducing open source step-by-step in Kenya. There is a new generation of students who want to be part of global technology work. They want to learn, collaborate, and build. Our role is to open the door and walk together(I have a discourse post on this, you’re welcome to add your views).
This event is part of a growing movement to strengthen Fedora’s presence in Kenya. More events will follow so that learning and contributing can continue.
We believe that open source becomes strong when more people are included. Fedora is a place where students in Kenya can learn, grow, share, and contribute to something global.
We already had a Discourse thread running for this event – from the first announcement, planning, and budget proposal, all the way to the final workshop. Everything happened in the open. Students who attended have already shared reflections there, and anyone who wants to keep contributing or stay connected can join the conversation.
You can check the events photos submitted here on Google photos(sorry that’s not FOSS:))
Cornelius Emase,
Your Friend in Open Source(Open Source Freedom Fighter)
admin )
on 2025-11-12 13:18:27 UTC
Today, the Fedora Project begins the nomination period during which we accept nominations to the “steering bodies” of the following teams:
This period is open until Wednesday, 2025-11-26 at 23:59:59 UTC.
Candidates may self-nominate. If you nominate someone else, check with them first to ensure that they are willing to be nominated before submitting their name.
Nominees do not yet need to complete an interview. However, interviews are mandatory for all nominees. Nominees not having their interview ready by end of the Interview period (2025-12-03) will be disqualified and removed from the election. Nominees will submit questionnaire answers via a private Pagure issue after the nomination period closes on Wednesday, 2025-11-26. The F43 Election Wrangler (Justin Wheeler) will publish the interviews to the Community Blog before the start of the voting period on Friday, 2025-12-05.
The elected seats on FESCo are for a two-release term (approximately twelve months). For more information about FESCo, please visit the FESCo docs.
The full schedule of the elections is available on the Elections schedule. For more information about the elections, process see the Elections docs.
The post F43 election nominations now open appeared first on Fedora Community Blog.
admin )
on 2025-11-10 12:00:00 UTC
We have ongoing intermittent issues with the communication between the Fedora proxies and the backend services. This manifests as intermittent 502 / 503 errors when talking to services such as Koji, Src, and so on.
We are working with the networking team to track it down, see the Pagure ticket for …
admin )
on 2025-11-07 17:00:00 UTC
Many services at our main datacenter are down/unresponsive. There seems to be a networking event going on. We are working with networking to track down and mitigate things. Updates as they become available.
All services have been restored.
admin )
on 2025-11-07 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you with both an infographic and a text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in-depth details, look below the infographic.
Week: 03rd – 07th November 2025
The purpose of this team is to take care of day-to-day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces, etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Infra and RelEng Update – Week 45, 2025 appeared first on Fedora Community Blog.