Fedora People
Blog List

RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll

Flock to Fedora 2026: What Happened

Posted by Justin Wheeler ( Fedora Account System Username

jflory7 ) on 2026-06-30 08:00:00 UTC

In the blink of an eye, it was over almost as quickly as it began. But the three days at the annual Flock to Fedora conference from 14–16 June 2026 in Prague, Czechia were packed with the kind of engagement that keeps the Fedora community going. Flock to Fedora, or often simply referred to as Flock, is the flagship contributor community event for the Fedora community. Flock is a place where the "doers" of our community gather annually to share our work, discuss ongoing collaborations, and shape the future of our next year ahead. Ultimately, it is one of my favorite parts of the Fedora Project. Being one of the lead organizers is one of the greatest privileges of serving in the Fedora Community Architect role at Red Hat.

This blog post is my attempt to capture the highlights of Flock 2026 while they are fresh in mind. The Linux and open source media already began their coverage. So, I thought this was a good moment to share my perspective on the event. This was my ninth Flock that I have attended and the fourth Flock where I played a leading role as an organizer.

The Hallway Track

I often tell people that the 45 days before Flock are some of the most stressful days of my entire year. But all four times I have done this, once I actually arrive at Flock and the conference gets going, the stress melts away. I am still running around a lot, taking care of this or that, but the important things always come together. Our speakers deliver great content, people reconnect after a long time of not seeing someone, and the hallway track is constantly lively. This year was no exception. I was pleasantly pleased to see and hear the community vibe which is essential to Flock was once again re-created.

Both my lived experience from nine years of Flock and the post-event data since we began collecting it in 2024 tells us one thing, absolutely. One of the most-valued parts of the Flock to Fedora experience is what is commonly known as "hallway track." If this is a new term to you, it is not too hard to understand. It plays on the idea that while there are usually tracks of speaker programming and content at a conference, there is also an unspoken track on the schedule. This "hallway track" is the informal conversations that take place outside of the speaker halls. They happen organically and they are usually unscripted. In-person attendees of Flock have been telling us for years that the "hallway track" at Flock is a critical, spotlight part of what makes the event worth attending.

A group selfie of several individuals wearing blue Flock to Fedora conference lanyards gathered around a long dining table in a room with large glass windows. A handwritten sign reading "Development" sits on the table among plates and glasses as the group poses for the camera held by a man in the foreground.

Figure 1. A group selfie of people wearing blue Flock to Fedora conference lanyards seated at a dining table featuring a handwritten "Development" sign.

So, while it appears the Fedora community has vast opinions about Flock, what it is, and what it is supposed to be, we all seem to agree on one thing. Getting the face-time to speak with other Fedora contributors is invaluable and drives critical engagement that keeps people in our community. I genuinely think without Flock to bring our core contributor community together once a year, we might all be burnt-out, exhausted, and tired from the online engagement we have been doing for more than 23 years. The in-person time is where the Fedora Friends Foundation comes out on full display. The hallway track is where people can go from colleagues to friends. When we talk about building trust in a community, it is experiences like the Flock to Fedora hallway track that turn trust-building from a concept to a concrete, practical thing.

"Generational Switchover" and Packager Data Trends

One of the most poignant parts of Flock 2026 came in the "State of Fedora" keynote delivered by the Fedora Project Leader, Jef Spaleta. Several thoughts were put forward, but what clearly generated buzz was a graph produced by Michael Winters from the Fedora Data Working Group.

A line graph titled "Year-over-Year Package Committers by Month." The x-axis tracks the month from 1 to 12. The y-axis measures unique Fedora package committers from 320 to 460. The graph plots data and dashed trend lines for three distinct years: 2020 in blue with a trend slope of -1.90, remaining mostly above 420; 2023 in orange with a steeper trend slope of -6.02, steadily declining from roughly 410 to 335; and 2026 in green, which only includes data for months 1 through 4, starting at 350 and dropping to 325 with the steepest trend slope of -8.70.

Figure 2. A line graph titled "Year-over-Year Package Committers by Month" showing a downward trend in the number of unique Fedora package committers across the years 2020, 2023, and early 2026.

Michael single-handedly developed user-level access to the wealth of packaging data we have been working to analyze, and the result was a striking visualization of the number of unique package committers in Fedora over a six-year span. The graph shows what seems to be a significant decline of the number of unique packagers actually working in Fedora Linux over a six-year span. The data appears to indicate a sharp decline in the number of unique packagers in 2026 so far versus the unique packagers in 2020 and 2023. It is a graph that is certainly concerning.

Jef put forward theories of what he thought the data could be indicating. At one point, he mentioned the idea of generational switchover, and that one era is ending and a new one is beginning. In the session following his keynote, the Fedora Council Q&A, this topic of generational switchover came up even more. Obviously, people felt concerned or triggered in some sort of way by this data. While the Fedora Council originally planned for the panel to focus more on a "what/how" conversation, we ended up having more of a "why" conversation with attendees.

It was a comment made by Aleksandra Fedorova which really stuck with me. At one point, she and I had touched on a shared experience for an in-person F41 Release Party in Potsdam, Germany. The interesting part of this was the unique intersection of both the local organizer, René Kuhn, and newcomer, junior students from the university (i.e., where the event was held) and old-timer, experienced contributors like myself and Aleksandra. Aleksandra mentioned that her experience at this F41 Release Party reminded her that the young people and students of today were just like many of us with several years behind us were when we began in Free Software and Open Source. She said that it was not actually young people who were changing, but us, the people who had been here for years, who have changed. We are no longer the same young people we were. We are more experienced, more exhausted, perhaps more burnt-out, than we were in our own youth and entry to the Free Software movement. I encourage you to watch the full panel discussion once it is available, but this is a thought that is sticking with me after Flock ended.

Record-Breaking Sponsor Engagement

We had a record-breaking level of engagement on the sponsor side of Flock 2026. We raised more sponsorship funding from a larger number of unique sponsors than we have received in years. This milestone shows us a couple of things:

We have a diverse group of engaged sponsors, mostly from downstream products and companies, which care about the sustainability and well-being of Fedora.
We are growing the amount of sponsorship for Flock to Fedora, which can enable us to think on a bigger, grander scale for future editions.
Our processes are getting better at selling Flock sponsor packages, and processing contracts, purchase orders, and invoices.

The sponsorship side of Flock really became more critical after the COVID-19 pandemic, when we returned to Flock to Fedora after a few years of Nest with Fedora virtual conferences. I remember as an attendee from 2015 to 2019 that while there were other sponsors, it was obviously Red Hat who was the most engaged, the most committed, and the one footing most of the actual costs. To be honest, this is still true today. However, the pool of engaged sponsors is diversifying. We have more commercial downstreams from Fedora Linux than we have ever had at any point in our history. To me, this represents healthy growth, even if it does raise more questions about how to sustain that growth and balance the increasing interest in Fedora Linux in a fair and equitable way.

Everyone tries to influence the direction of a project they care about. That is simply how communities work. What matters is whether the processes for exerting that influence are fair, equitable, and open to everyone. In Fedora, they are. Our sponsors do not buy influence in Fedora Linux. What is impressive about most of our Flock sponsors is that there are often coordinated groups of paid engineers and contributors from these companies who show up to do real, actual work in the Fedora community. They submit Fedora Changes, get them reviewed by FESCo, and integrated into Fedora Linux — the same process available to anyone. Our hardware vendor sponsors can also participate in initiatives like Fedora Ready, to provide greater assurance and information for Linux consumers to purchase hardware which has a guaranteed quality experience with Fedora Linux. Our sponsors are not complacent and they do not rely on financial sponsorship to get them special favors. If they want something done, they show up and do the work themselves, together with the input and participation of the rest of the community.

A special thank-you to the individual folks at our various sponsoring organizations who raise the Fedora Project flag in their teams, departments, and entire organization. Without you, these special, collaborative relationships we have would not be possible.

Fill Out the Flock 2026 Post-Event Survey!

If you are reading this blog post, attended Flock in-person or virtually, and it is before 8 July 2026, stop everything you are doing. Go and complete the Flock 2026 post-event survey right now. This is only because it is the most important part of the entire future Flock planning process. As one of the people with access to the data and also involved with the planning for future Flock editions, nothing else matters more than this. While I am always listening to what people have to say in the hallway or making my own observations at the conference, the survey gives us real data to understand what people think and feel about Flock to Fedora. I always read every single comment and response in the survey. It matters to the entire Flock organizing team that we build an event that reflects the desires and wishes of our community.

The survey is open to both in-person and virtual attendees. We know that the Fedora community is global and spread out all over the world. We also know that travel is not necessarily an equitable act; not everyone can afford to travel, or even is physically able to travel. Therefore, we invite everyone who considers themselves a part of the Fedora community and participating with Flock to share their opinions.

After all, if we only sent our survey to our in-person European conference attendees, it seems quite likely that we will keep hearing about how Europe is the best location for Flock. So, even our virtual attendees and people who could not travel in-person to Flock 2026 can share their feedback and voice to help us make a better and more inclusive Flock in the next editions.

A DNS Record That Existed Everywhere Except CI

Posted by Miroslav Vadkerti ( Fedora Account System Username

mvadkert ) on 2026-06-30 00:00:00 UTC

A flaky CI failure where a freshly-created DNS record was unresolvable from inside the cluster, but resolved fine from my laptop a few minutes later. The culprit was negative DNS caching, driven by the zone’s SOA, poisoning lookups for our ephemeral per-job records.

My Halfway Journey as an AI/ML Engineering Outreachy intern at the Fedora Project: building toward…

Posted by Francois Gonothi Toure ( Fedora Account System Username

gtfrans2re ) on 2026-06-29 20:08:29 UTC

My Halfway Journey as an AI/ML Engineering Outreachy intern at the Fedora Project: building toward a tool for 30 years of RPM Packaging guidelines

Image promptly created with Google Gemini’s Nano Banana

From May 18, 2026, to the present, I have been deep-diving into the Fedora Project as an Outreachy and Software Freedom Conservancy intern, working on an AI/ML project that will ultimately help Fedora’s RPM packagers navigate the 30-year history of RPM packaging guidelines.

Fedora is now a community that I call family, and every Fedoran I have encountered has been incredibly helpful and supportive in ways I can hardly put into words. From my esteemed mentors, Carol Chen, Dominik Kawka, and Justin Wheeler (one of the Fedora Project maintainers), to the members of the AI/ML Special Interest Group and the Fedora Infrastructure Team, and everyone else I have had the chance to learn from since the beginning of my internship, I have loved every moment of it and intend to be a lifelong contributor to the Fedora Project.

So what have I done and contributed so far?

Even before the internship officially began, I had the chance to interact with and get support from my mentors as part of my preparation. During this time, I continued deepening my knowledge of RamaLama and RamaLama RAG that I had started building during the contribution phase. In doing so, I explored and documented the document-processing and retrieval-pipeline architecture, converting both single PDF files and entire directories of PDF files, and tested custom GPU and graphics accelerators to get everything running.

I also explored running OpenAI’s GPT-OSS with RamaLama. In parallel, I got started with RPM packaging by familiarizing myself with the RPM package management system and even simulating my own implementation of RPM-based systems. With my mentors’ support, I successfully ran and tested the RamaLama Sandbox-Goose, tinkering with several examples and building and deploying agentic AI systems with it for my own projects. If you would like to learn more about this preparatory work, you can find it here: https://github.com/gtfrans2re/fedora-summer-ml-prep-2026

As for my contributions since the internship began, I really cannot take the credit alone; this work is made possible by mentors who pour a great deal of effort and time into creating and following up on the issues I work on.

Here are the issues I have been working on as part of my contributions so far:

[Gonothi] Identify and scope a RAG mini-project candidate (#145): Together with my mentors, we proposed and scoped a small-scale RAG mini-project using RamaLama to test retrieval workflows before tackling the full Fedora RPM Packaging Guidelines. The outcome was a selected, well-scoped mini-project candidate that let me begin RAG pipeline testing with RamaLama in Sprint 6.
[Gonothi]: RAG Mini-Project — enhance a model with Fedora Magazine Blog Article Guidelines (#146): This issue involved enhancing a model using RamaLama RAG on the Fedora Magazine and Community Blog writing guidelines and past published articles, to help reviewers evaluate draft submissions. The result is a working RAG prototype that validates the pipeline before tackling the full RPM documentation.
[Gonothi]: Welcome and onboarding (#148): I completed onboarding tasks and connected with key people across Fedora, which helped me get to know the project and community and strengthened the foundation for my Outreachy work.
[Gonothi]: RAG Mini-Project — explore deploying on Quay.io (#149): For the OCI images created via the RamaLama RAG pipeline in #146, I made them publicly available on Quay.io (https://quay.io/user/gtfrans2re/) for distribution, ensuring the RAG images are accessible to other users.
[Gonothi] Familiarize more with AI/ML SIG, and Packaging process (#150): This ongoing issue (due July 6, 2026) is helping me get better acquainted with the teams and processes that will support the main internship project.
[Gonothi] Identify 3–5 relevant A-level scientific conferences or journals (#151): Under my mentors’ guidance, I scouted potential conferences and journals where the final work from this internship could be published or presented. The outcome was a shortlist of suitable venues.
[Gonothi] Evaluating RAG systems and other tools (#154): This issue had me explore tools that help with RAG evaluation, model selection, CPU/GPU usage profiling, and scaling ML workloads, to understand each tool’s value and integrate those that can benefit my project.
[Gonothi] Request to join the fi-apprentice group (#13393): On my mentors’ recommendation, I requested membership in the fi-apprentice group to gain read-only access to Fedora infrastructure machines, so I can learn the setup and find areas to contribute. Joining as an apprentice is an interim step to familiarize myself with the infrastructure (including bastion access) while dedicated GPU/server resources are being provisioned for the project.

Highlights of what I have learned from other interns, my mentors, and my community:

So far, I have connected with several other interns over the Outreachy Zulip chat platform and with some of them on LinkedIn. It is always great to read about their experiences during the monthly Outreachy chats, and over the past two chats, I have been genuinely inspired by their journeys and portfolios.

As for my mentors, from day one, they made me feel as though we had known each other for years. They are kind, open-minded, and incredibly generous in sharing learning resources to help me prepare for the work ahead. I have learned to use Replicate API tokens to run AI models from Google Colab and from Python. Carol Chen even generously shared an API token with me so I could test this out. My mentors also pointed me to resources for exploring and testing open-source LLMs for building and deploying AI and agentic AI systems locally and showed me how to use RamaLama Sandbox-Goose to ship an AI agent locally before deployment. They introduced me to tools like llmfit for fitting models on a local machine with efficient CPU and GPU memory management. And, as they suggested, I worked through several RPM packaging examples to understand the overall process and how AI and ML might help speed it up.

One thing my mentors did that meant a great deal to me was helping me find the resources to join the Linux meetup community in Montréal and Québec, a network of Linux and open-source users in my region, so I could attend meetups and keep learning alongside like-minded people. This also led me to the Red Hatters in Canada group, through which I was invited to Red Hat Tech Day in Montréal on June 11, where I got to learn about and use Red Hat AI and Red Hat OpenShift AI to build and secure AI and agentic AI systems in Red Hat Enterprise Linux cloud environments.

As for the wider community, I have joined and am getting acquainted with the Fedora AI/ML Special Interest Group (SIG), where I interact with group members, as well as the Fedora Infrastructure Team through the fi-apprentice program. I will also be attending Flock to Fedora, Fedora’s annual contributor conference, held this year, June 14–16, in Prague, virtually, to meet more Fedorans and learn about the technology we all build on. Beyond that, I have connected with many Fedorans to learn more about what they do, including Aoife Moloney from the Fedora Operations Architect team, Jona Azizaj from the Fedora EDIA team, and Madeline Peck from the Fedora Design Team.

What I am most proud of building so far:

The contribution I am most proud of is the mini-project at the heart of my work so far: an AI-powered editorial assistant for the Fedora Community Blog and Fedora Magazine, built with RamaLama RAG. It is a deliberately smaller, well-scoped problem chosen as the foundation for the larger RPM Packaging Guidelines project to come, a way to prove out the entire RAG pipeline end-to-end on a manageable corpus before tackling 30 years of packaging documentation.

The tool helps new authors and reviewers check whether a draft article meets Fedora’s editorial standards before submission. It flags missing required elements, such as a featured image or the “Read More” tag, and checks tone, structure, technical accuracy, and topic scope against the publications’ own writing guidelines and past published articles.

Building it taught me how the whole pipeline fits together in practice:

Preparing the data: I fetch articles from both publications via the WordPress REST API and let RamaLama RAG ingest the HTML directly. A key lesson from my mentors here was that RamaLama already uses Docling internally to convert documents into a structure-aware representation optimized for retrieval, so feeding it the original HTML preserves more meaning than pre-flattening everything to plain text or Markdown.
Building the vector stores: Using the ramalama rag command, I build OCI images for the Community Blog, the Magazine, and a combined corpus, and publish them on Quay.io so others can pull and run the tool without rebuilding anything from scratch.
Choosing and testing models: I benchmarked several open-weight models and, with my mentors’ input, narrowed the local lineup to the newer, more efficient Gemma 4 and Granite 4, a reminder that on constrained hardware, model generation and efficiency matter as much as raw size.
Making it usable: I built a Streamlit interface where an author can paste a draft and get instant editorial feedback, and I documented a full local development guide plus a quickstart so anyone can run the tool on their own machine.

What I am proudest of is not any single component but the fact that it works as a complete, reproducible, fully open-source pipeline (Apache 2.0) running entirely on local, open-weight tooling, no proprietary services required. You can find the project here:https://forge.fedoraproject.org/ai-ml/editorial-guide-ramalama

I presented this tool to Michal Konečný from the Community Blog editorial team and pitched it to the Fedora Magazine editors, and the encouraging early feedback has been one of the most rewarding parts of the internship so far.

Adjustments to scope, timeline, and tasks:

The overall arc of the internship remains the same: the mini-project is the proving ground for the main project on the Fedora RPM Packaging Guidelines. A few refinements have happened along the way, all of them improvements rather than changes of direction.

On scope, we expanded the mini-project from the Community Blog alone to include Fedora Magazine, since the pipeline generalized well to both. On the technical side, guided by my mentors, I removed a redundant manual ingestion step once we confirmed that RamaLama already handles document conversion and chunking internally, and I narrowed the model lineup to Gemma 4 and Granite 4 for efficiency on local hardware. The one external constraint has been computed: running the heavier models locally pushes my current machine to its limits, and dedicated GPU/server resources are being provisioned to unblock that, which is also why I am getting acquainted with Fedora’s infrastructure through the apprentice program in the meantime.

As I move into the second half of the internship, the focus shifts toward applying everything I have learned from this mini-project to the much larger and more ambitious main project: building a RAG-powered tool for three decades of Fedora RPM packaging guidelines. I could not be more excited for what is ahead.

Regards,
Gonothi

Loadouts For Genshin Impact v0.1.17 Released

Posted by Akashdeep Dhar ( Fedora Account System Username

t0xic0der ) on 2026-06-29 18:30:00 UTC

Loadouts For Genshin Impact v0.1.17 Released

Hello travelers!

Loadouts for Genshin Impact v0.1.17 is OUT NOW with the addition of support for recently released artifacts like Celestial Gift and Disenchantment in Deep Shadow, recently released characters like Nicole, Lohen and Prune and for recently released weapons like Angelos' Heptades and Disaster and Remorse from Genshin Impact Luna VII or v6.6 Phase 2. Take this FREE and OPEN SOURCE application for a spin using the links below to manage the custom equipment of artifacts and weapons for the playable characters.

Resources

Installation

Besides its availability as a repository package on PyPI and as an archived binary on PyInstaller, Loadouts for Genshin Impact is now available as an installable package on Fedora Linux. Travelers using Fedora Linux 42 and above can install the package on their operating system by executing the following command.

$ sudo dnf install gi-loadouts --assumeyes --setopt=install_weak_deps=False

Installation command for Fedora Linux

Changelog

Replace native compilation with integrated building by @gridhead in #544
Automated dependency updates for GI Loadouts by @renovate[bot] in #545
Automated dependency updates for GI Loadouts by @renovate[bot] in #547
Remove unused class variable by @sdglitched in #550
Fix incorrect type hint for refi_stat by @sdglitched in #551
Update dependency nuitka to >=2.0.0,<5.0.0 by @renovate[bot] in #552
Trigger test workflow on pull_request by @sdglitched in #559
Add the recently added artifact set Celestial Gift to the GI Loadouts roster by @sdglitched in #557
Add the recently added character Prune to the GI Loadouts roster by @sdglitched in #556
Automated dependency updates for GI Loadouts by @renovate[bot] in #553
Introduce the recently added weapon Angelos' Heptades by @gridhead in #560
Automated dependency updates for GI Loadouts by @renovate[bot] in #563
Introduce the recently added character Nicole to the roster by @Ank-22 in #565
Introduce the recently added artifacts Disenchantment in Deep Shadow by @gridhead in #561
Introduce the recently added character Lohen to the roster by @gridhead in #562
Introduce the recently added weapon Disaster and Remorse by @Ank-22 in #568
Update actions/checkout action to v7 by @renovate[bot] in #567
Stage the release v0.1.17 for Genshin Impact Luna VII (v6.6 Phase 2) by @sdglitched in #574

Artifacts

Two artifacts have debuted in this version release.

Celestial Gift

Bonus for Two Piece Equipment
Energy Recharge + 20%.
Bonus for Four Piece Equipment
If the equipping character has completed Witch's Homework, after they use an Elemental Skill, they also gain "Light's Guidance" for 20s: All nearby party members gain a 20% Elemental DMG Bonus corresponding to the equipping character's Elemental Type. The equipping character can trigger this effect while off-field. DMG Bonuses provided by Artifact Sets with the same name do not stack.
When your party has the Hexerei: Secret Rite effect, Light's Guidance is upgraded to "Mortal Hymn": All nearby party members gain a 40% Elemental DMG Bonus corresponding to both the equipping character and the current active party member's Elemental Type instead. If both characters have the same Elemental Type, these bonuses will not stack.

Disenchantment in Deep Shadow

Bonus for Two Piece Equipment
ATK +18%.
Bonus for Four Piece Equipment
Increases Superconduct Reaction DMG by 80%. When the wielder attacks opponents affected by Superconduct, this attack's CRIT Rate is increased by 16%. An all-new blessing may be obtained as you make your way toward Snezhnaya...

Characters

Three characters have debuted in this version release.

Nicole

Nicole is a catalyst-wielding Pyro character of five-star quality.

Lohen

Lohen is a polearm-wielding Cryo character of five-star quality.

Prune

Prune is a catalyst-wielding Anemo character of five-star quality.

Weapons added

Two weapons have debuted in this version release.

Angelos' Heptades

Crown of the Final Scion - Scales on ATK %.

Disaster and Remorse

Dolorous Stroke - Scales on Crit Rate.

Appeal

While allowing you to experiment with various builds and share them for later, Loadouts for Genshin Impact lets you take calculated risks by showing you the potential of your characters with certain artifacts and weapons equipped that you might not even own. Loadouts for Genshin Impact has been and always will be a free and open source software project, and we are committed to delivering a quality experience with every release we make.

Disclaimer

With an extensive suite of over 1580 diverse functionality tests and impeccable 100% source code coverage, we proudly invite auditors and analysts from MiHoYo and other organizations to review our free and open source codebase. This thorough transparency underscores our unwavering commitment to maintaining the fairness and integrity of the game.

The users of this ecosystem application can have complete confidence that their accounts are safe from warnings, suspensions or terminations when using this project. The ecosystem application ensures complete compliance with the terms of services and the regulations regarding third-party software established by MiHoYo for Genshin Impact.

All rights to Genshin Impact assets used in this project are reserved by miHoYo Ltd. and Cognosphere Pte., Ltd. Other properties belong to their respective owners.

Your _get_type() function is not G_GNUC_CONST: Part Two

Posted by Michael Catanzaro ( Fedora Account System Username

catanzaro ) on 2026-06-29 15:32:49 UTC

This blog post is a sequel to Your _get_type() function is not G_GNUC_CONST.

GNOME developers have long used G_GNUC_CONST, which expands to __attribute__((const)), to annotate GObject _get_type() functions, despite knowing that it is incorrect to do so. const functions by definition have no side effects, but _get_type() functions actually have a side effect the first time the function is called: they initialize the type. Why apply an incorrect annotation to these functions? Because it makes the code faster.

Although this was long known to be incorrect, it worked fine in practice… until now. Regrettably, Sam James has discovered that GCC 16 may optimize away the type initialization, resulting in crashes. This is our fault for providing the compiler with wrong information about our code, so it’s time to audit your use of const attributes to remove them from _get_type() functions. Most GNOME programs use these attributes only for _get_type() functions, but if you use it in more places, then check to make sure those functions are actually const, as defined by the GCC documentation.

Sadly, there is no suitable replacement attribute for _get_type() functions. Two decades ago, Behdad requested a new idempotent attribute for expressing the desired semantics, but nobody has implemented it.

From June 22 to June 28

Posted by Aurélien Bompard ( Fedora Account System Username

abompard ) on 2026-06-28 23:14:00 UTC

Across the Fedora project, teams are heavily focused on preparing for the upcoming Fedora 45 release, with groups including Quality, Workstation, Server, Cloud, and CoreOS actively coordinating system-wide changes, mass rebuilds, and issuing calls for F45 Test Day proposals. Simultaneously, a massive infrastructure transition is underway as Infrastructure, Release Engineering, Mindshare, and IoT urgently migrate repositories, issue trackers, and automated workflows from the sunsetting Pagure platform to the new Fedora Forge (Forgejo). Security and policy enforcement also dominate current efforts, highlighted by the newly enacted Two-Factor Authentication (2FA) mandate for provenpackager members, ongoing discussions around cryptographic library management, and extensive CVE patching within EPEL. Finally, improving the contributor experience remains a central priority, with the Docs and Design teams actively modernizing onboarding materials, while groups like Mindshare and Ambassadors recruit volunteers to support community engagement and upcoming global events.

Announcements

For Fedora contributors, there are several important infrastructure and policy updates to be aware of this week. FESCo now requires two-factor authentication for all provenpackager members, with a grace period extending to September 24, 2026, before non-compliant accounts are temporarily downgraded. Additionally, history has been rewritten for 71 package git repositories to fix long-standing git fsck issues; contributors with existing checkouts of these specific repos will need to perform fresh clones. A planned one-hour outage occurred on June 25th, temporarily affecting download-ib01, torrent, and fedorapeople services. In ecosystem news, discussions are ongoing regarding the future of Pagure.io and the transition to Forgejo, while Fedora Documentation translations are once again available following their successful migration to the new Fedora Forge. Finally, the F44 Election Results have been announced, officially seating new members for the Council, FESCo, Mindshare, and the EPEL Steering Committee.

In news relevant to the broader Linux community, Fedora has addressed the upcoming expiration of Microsoft's UEFI Secure Boot keys. Existing machines will continue to boot normally without panic, and Fedora Rawhide (f45) already includes a first-stage boot loader signed with multiple keys to ensure maximum compatibility moving forward. On the community front, Fedora was heavily represented at the XV P.I.W.O. Poznań Free Software Fest in Poland, which saw record attendance and hosted the historical signing of the SPOIWO declaration—a new coalition advocating for digital sovereignty and open-source software in public institutions.

Council

The Council discussed the Draft Council Proposal for the Fedora Innovation Lifecycle, a framework designed to handle experimental, large-scale projects that are too complex for the standard ChangeProposal process. The proposed lifecycle introduces Sandbox, Curation, and Integration stages to help solve the "innovator's dilemma" by nurturing big ideas within the project boundary. While some participants questioned if existing tools like Copr and the current Changes Process could simply be improved, proponents argued that a dedicated Sandbox is necessary for massive, interlocking changes to prove their viability without being hindered by strict technical policies early on. This structured pathway aims to foster innovation and sustainable contributor engagement for strategic initiatives, such as the ongoing RISC-V architecture bring-up, which currently has to operate outside the project as a remix.

Learn more about the Council team.

FESCo

FESCo welcomed new members following the F44 elections and opened nominations for the Fedora Council Engineering Representative. A major security policy update was announced, requiring all provenpackager group members to enable Two-Factor Authentication (2FA) by September 24, 2026, with discussions underway to potentially expand this requirement to all packagers. Additionally, FESCo approved several system-wide changes for Fedora 45, including updates to RPM 6.1, Golang 1.27, Erlang 27, and the adoption of PURL Metadata. New F45 Change Proposals were also introduced for community feedback, such as a minimal GRUB EFI build for Confidential Computing and offering the Lazarus IDE with multiple widgetsets.

The committee is actively seeking input on managing binary executable content in node_modules and whether to drop the signoff requirement from the defunct Fedora crypto team for new cryptography libraries. Contributors are also invited to discuss the upcoming Forgejo distgit migration and a proposal to allow draft builds for ELN rebuild batches. To streamline issue tracking, FESCo is migrating its public issues to the new forge, archiving private issues, and temporarily opening its mailing list to non-subscribers for sensitive reports.

Decisions

Two-factor authentication is now required for the provenpackager group, with a 3-month grace period before enforcement.
FESCo public issues will be migrated to the new forge, while private issues will be archived in a separate repo. The FESCo mailing list will temporarily accept emails from non-subscribers for private reports.
The Fedora Operations Architect was added as a sponsor for the "fesco" FAS group and as a mailing list admin.
Approved F45 System-Wide Changes: Adopt PURL Metadata, Erlang 27, RPM 6.1, Golang 1.27, and Versioned libgit2 packages.
Added containerd, moby-engine, rootlesskit, and docker-distribution to the Update Policy Exception List.

Learn more about the FESCo team.

Packaging Committee

During the Packaging Committee meeting, members addressed several guideline updates and packaging challenges. The committee reviewed FPC#1551 regarding versioned packages and agreed to remove the strict guideline stating they "MUST NOT conflict with all other versions," noting that general conflict guidelines are sufficient and development subpackages often unavoidably conflict. The group also discussed the ongoing issue of NodeJS packages shipping pre-built JavaScript blobs instead of building from source. While no immediate enforcement was enacted, the committee highlighted a strong need for improved NodeJS packaging tooling—presenting an excellent opportunity for contributor engagement—and suggested a potential future flag date to enforce compliance.

Additionally, the committee discussed FPC#1546 concerning the use of non-Fedora distribution conditionals (such as SUSE or Azure Linux macros) in spec files. Rather than strictly banning or allowlisting specific macros, it was agreed that new, comprehensive multi-distro guidance will be drafted. This upcoming proposal will aim to support cross-distribution compatibility for ecosystems sharing Fedora's packaging roots without cluttering spec files or burdening Fedora maintainers.

Learn more about the Packaging Committee team.

Mindshare

During the June 23 CommOps meeting, the team prepared for the impending mid-July sunset of Pagure.io by coordinating the migration of Fedora Magazine and Community Blog repositories to Forgejo. To improve news accessibility for newcomers and the broader Linux community, the team explored alternatives to dense LLM-generated summaries and approved a proof-of-concept for a human-curated "This Week in Fedora" Matrix news bot, inspired by similar tools used by GNOME and Ansible (hebbot).

Planning has officially kicked off for the Virtual F45 Release Party, tentatively scheduled for October 30, 2026. The team is actively seeking volunteers to lead various work streams, including a lead "Wrangler," speaker coordination, and video production. Furthermore, there is a high-profile engagement opportunity open: CommOps is searching for a new representative to serve on the Fedora Mindshare Committee to help guide global outreach and event operations.

Learn more about the Mindshare team.

Ambassadors

The Ambassadors group is beginning preparations for All Things Open 2026 in Raleigh-Durham, North Carolina. A call for participation has been issued for Fedora Ambassadors planning to attend, offering an excellent engagement opportunity to help shape the project's official event presence. Contributors interested in collaborating, representing the project, or helping staff a potential joint Fedora and CentOS nonprofit booth are encouraged to reply to the forum thread as soon as possible so resources can be mobilized. Further coordination regarding the official booth plan is expected to take place after July 5th.

Learn more about the Ambassadors team.

Workstation / GNOME

A new EXT4 mount option called rralloc (round-robin allocator) was proposed and discussed this week. Designed as an optional, mount-time allocation policy that leaves the on-disk format unchanged, it aims to reduce allocator contention and improve tail latencies for high-concurrency workloads on modern SSD and NVMe storage. The developer is currently seeking feedback and identifying potential use cases to gauge community interest and justify its broader adoption.

In preparation for the upcoming release, the Quality team has issued a call for Fedora 45 Test Days. Contributors are encouraged to review the accepted Fedora 45 changes and propose focused testing events for specific features by filing a ticket on Fedora Forge.

Learn more about the Workstation / GNOME team.

KDE

In recent discussions, it was noted that KDE Gear 26.04 was initially blocked on Fedora 43 due to a gpgme dependency update (requiring version 2.0+) that conflicted with Fedora's soname bump policy. Thanks to upstream commits lowering the requirement to version 1.24.2, this hurdle was cleared. KDE Gear 26.04 will now be pushed to Fedora 43 alongside Plasma 6.7.1, and the update is currently available in Bodhi for community testing.

Looking ahead to the next release cycle, the Fedora QA team has announced a Call for Fedora 45 Test Days. Contributors are highly encouraged to review the accepted F45 ChangeSet and propose specific testing events by filing a ticket on Fedora Forge. This is a prime opportunity for community members to help organize and lead focused testing for new features or critical distribution areas.

Learn more about the KDE team.

Server

The Server Working Group discussed several updates to the distribution and its documentation during their weekly meeting (also summarized on the mailing list). To better support users in regions with fragile or slow internet connections, the group agreed to re-include PPP and xDSL connection support packages in the base distribution media. Additionally, a call for Fedora 45 Test Days was announced across the forum and mailing list, inviting contributors to propose and host testing events for upcoming features.

On the documentation front, the team approved plans to create comprehensive OpenSSH guides and assigned action items to clean up existing NFS installation instructions. To improve security practices and consistency, all Server documentation will be updated to align with the Fedora Docs Style Guide, specifically transitioning command-line examples to use sudo [command] rather than root shells. Contributors interested in helping with these documentation updates or ongoing PXE boot and Kickstart configurations are encouraged to engage with the team.

Learn more about the Server team.

Infrastructure

The Infrastructure team managed several significant server moves and reinstalls this week, including relocating 11 OpenQA, Copr, and OpenShift worker nodes to optimize datacenter power usage, and reinstalling the download-ib01 host with RHEL 10. A major topic of discussion across meetings and the forum was the ongoing migration from the sunsetting Pagure platform to Fedora Forge. The team is actively exploring solutions for handling private security tickets on Forgejo, considering alternative workflows like private Discourse categories, while also assisting teams in archiving their old Pagure repositories. Additionally, a recent RabbitMQ certificate refresh surfaced a bug in the fedora-messaging library where it only read the first CA certificate in a combined file, which was promptly fixed and released.

In community-facing services, a forum discussion highlighted a growing need for shared, open LLM inference hosting within Fedora infrastructure to support tools like Log Detective and meeting summarization bots. The team also addressed a backlog of s390x builds by provisioning an additional builder, resolved Rawhide mirror 404 errors, and granted a storage quota increase on fedorapeople.org to host Flock 2026 video recordings. Ongoing operational work for contributors includes a major cleanup of legacy Nagios and collectd monitoring in favor of Zabbix, and migrating OpenShift applications to standardized Ansible roles.

Decisions

To mitigate staging connection failures, the team decided to temporarily restore the old RabbitMQ server certificates until the patched fedora-messaging library is widely adopted.
The team decided to provision an additional s390x builder to alleviate a severe backlog of long-running package builds.

Learn more about the Infrastructure team.

Release Engineering

During the Release Engineering meeting, the team prioritized the scm-requests migration ahead of the upcoming Pagure decommission. This involves updating fedpkg to file tickets in Forgejo and determining the safest backend method for processing those requests. The team also prepared for the upcoming mass rebuild cycle, the rollout of F47 keys, and finalizing the Fedora 42 End of Life process. Over on the forum, a community member shared their configuration and a brief guide on building a customized Fedora 44 XFCE live ISO using kiwi-ng.

Ticket activity this week centered heavily on package unretirements (kdevelop-python, rust-git-absorb, wavemon, pcl) and implementing a related fix for Koji owner synchronization to ensure unretired packages are properly assigned. The team also addressed Rawhide gating issues by untagging a problematic haveged build that was breaking FreeIPA upgrade tests, and reviewed upcoming Fedora 45 system-wide changes regarding Stratis storage in Anaconda and disabling DNF5 vendor changes by default.

Decisions

For the scm-requests migration, the team decided to update the existing toddlers code to process Forgejo tickets rather than switching to Forgejo Actions. This was chosen to avoid the security risks of storing highly privileged distgit admin tokens in Action secrets.
Patrik will take the lead responsibility for managing the upcoming mass rebuild cycle.

Learn more about the Release Engineering team.

Quality

During their weekly meeting, the Quality team reviewed their recent Flock and DevConf attendance, highlighting productive discussions on openQA failure analysis, Fedora CI improvements, and the ongoing effort to move testing to dist-git PRs. On the technical front, the massive OpenSSL 4 update landed in Rawhide; while it initially broke FreeIPA replication tests and gated all updates, these failures were temporarily bypassed to allow the merge. Additionally, Adam Williamson shared early work on a new system for tracking critical path packages to improve dependency gating, and the team noted that a Kernel 7.1 test week will be scheduled soon.

A Call for Fedora 45 Test Days has been officially issued, inviting the community to review the accepted ChangeSet and propose focused testing events via Fedora Forge. In other community news, volunteers have stepped up to help maintain the Packager Dashboard and Oraculum, though more contributors are always welcome to join the effort. Finally, nightly release validation testing is ongoing, with new composes nominated for Fedora 45 Rawhide and Fedora-IoT 45 RC.

Decisions

Temporarily bypass FreeIPA replication test failures on Rawhide to allow the OpenSSL 4 update to merge.
Disable the use of haveged in FreeIPA tests to resolve recent Rawhide update blocking issues.

Learn more about the Quality team.

Design

The Fedora Design team made significant progress on release artwork this week, officially completing and uploading the Fedora 45 Beta wallpaper. While the final wallpaper is expected in early July, the team is currently troubleshooting Inkscape export crashes related to high-resolution gradients. In event design, the Flock 2026 livestream splash screens were completed and closed, and a new ticket was opened to automate the creation of YouTube thumbnails for individual Flock talks.

There are excellent opportunities for contributor engagement, including a fun new request to design an avatar for the Fedora Matrix Moderation bot. Ongoing community projects also saw major updates: the team is finalizing a community onboarding flyer after implementing accessibility and design feedback, and the Contributor Onboarding Video Series is nearing completion after receiving official voiceovers from the Fedora Project podcast and undergoing final visual and audio tweaks.

Decisions

The Fedora 45 Beta wallpaper will be used to internally test JXL packaging while the final version is completed.
Based on viewer feedback, future Flock livestream templates will prioritize maximizing the screen size allocated for presented content (slides and workshops) to improve readability.
The community onboarding flyer will drop the "technical vs. non-technical" grouping requirement to better accommodate the current design layout.

Learn more about the Design team.

Docs

This week, the Docs team focused heavily on modernizing the documentation ecosystem and improving the onboarding experience. Several mentored issues are open for newcomers to help update contribution guides, including shifting the focus to local authoring workflows, updating the Quick Docs contribution guide, and creating a beginner-friendly "Git for Writers" article. Broader restructuring efforts are also underway, such as planning a modern design for the Docs homepage, exploring UI/UX enhancements for knowledgebase-style pages, and piloting a new "Fedora Docs Captain" role to decentralize documentation leadership across various Fedora Working Groups and SIGs. In the forums, a community member shared a detailed guide on creating a custom Fedora 44 XFCE live ISO using KIWI-ng.

Behind the scenes, the team is actively cleaning up legacy infrastructure by deleting outdated docs pages from the Fedora Wiki and unprotecting specific wiki categories to facilitate change proposal management. Ongoing policy discussions include whether to enforce opening PRs exclusively from forks and the potential creation of a formal code style guide to ensure syntax consistency across repositories.

Decisions

To address security vulnerabilities in the outdated docsbuilder.sh container image, the team decided to request a testing-farm runner on the Fedora Forge staging instance to test building new container images, with a long-term plan to transition to Konflux.

Learn more about the Docs team.

Internationalization

During the Internationalization meeting, the team reviewed the tracker for Fedora 45 changes, noting that the LibreOffice dictionaries change is planned for this week, while the fontconfig change is still in progress. Members were reminded to assist with Fedora 43 bug triaging and were briefed on upcoming proposal submission deadlines for Fedora 45 system-wide and infrastructure changes.

On the mailing list, a new contributor volunteered to assist with Norwegian Bokmål translations for core projects like systemd, Anaconda, and dnf. The team welcomed the contributor, confirmed that their manual review of AI-drafted translations complies with the Fedora AI-Assisted Contributions Policy, and requested a re-upload of recent systemd translations that were lost due to a Weblate merge conflict.

Learn more about the Internationalization team.

COPR

Following the end-of-life of Fedora 42 on May 27, 2026, the COPR team announced the disabling of all Fedora 42 chroots. Consequently, contributors can no longer submit new builds for fedora-42 architectures, including x86_64, i386, ppc64le, aarch64, and s390x.

To avoid disruptive surprises, project owners should note that existing Fedora 42 build results will be preserved for 180 days. After this grace period, they will be automatically removed unless contributors take explicit action to prolong the chroots' lifespan within their specific projects.

Learn more about the COPR team.

EPEL

During the EPEL meeting on 2026-06-24, the steering committee discussed several upcoming package transitions and security updates. Contributors are encouraged to review issue #368 regarding a proposed incompatible update or retirement for syncthing (v1.30 to v2) ahead of next week's vote. Additionally, significant work is underway to address CVEs in EPEL packages. The caddy package will be fast-forwarded in EPEL 10, may require an incompatible update in EPEL 9, and is facing potential retirement in EPEL 8 due to build complexities without go-vendor-tools. Furthermore, the KDE SIG has stepped in to help update qt6-qtwebengine in EPEL 9 to resolve a large number of outstanding CVEs, ensuring the package remains available for its active user base rather than being dropped.

Decisions

Issue #367: The committee approved proceeding with the incompatible update of p7zip to 7zip for EPEL 9, provided appropriate announcements are made. Approval for EPEL 8 will be handled asynchronously once COPR build tests for EPEL 8-specific dependencies (conky-manager and retrace-server) are completed.

Learn more about the EPEL team.

ELN

During the ELN meeting, the team provided status updates on ELNBuildSync (EBS) and bootc integration. The migration of EBS to Fedora Infrastructure is 95% complete, with the Ansible playbook functioning in staging and the team currently awaiting OIDC secrets from Fedora Infra to finalize the deployment. To improve crash recovery, the team proposed a new approach to run EBS batches as Draft Builds right up until submission to Bodhi. This change is pending approval in FESCo issue #3621, and the corresponding pull request is already prepared.

Additionally, progress on bootc compose images is nearing completion. The work is ready to merge but is temporarily blocked waiting for preceding merge requests to land and for Konflux team members to return from PTO, though the bootc team is actively looking into unblocking the process.

Learn more about the ELN team.

Atomic

This week, discussions continued regarding the proposal to create a systemd-sysexts SIG. This proposed Special Interest Group aims to build and distribute systemd system-extensions based on Fedora content, providing a way to add extensibility to atomic systems for software that does not run well in containers or Flatpaks. The initiative continues to gather interested contributors to help design the distribution, discoverability, and official building processes.

In contributor engagement opportunities, the QA team has issued a call for Fedora 45 Test Days. With the Fedora 45 schedule progressing, community members are encouraged to review the accepted ChangeSet and propose features or distribution areas that would benefit from focused community testing. Contributors can propose and organize a test day by filing a ticket on the Fedora Forge.

Learn more about the Atomic team.

CoreOS

During the CoreOS meeting, the team focused heavily on upcoming Fedora 45 changes ahead of the proposal deadlines. Preparations are underway for the F45 pivot change request, the relocation of RPM repository configs to /usr, and upcoming proposals to introduce an oom-kill service and default zram for CoreOS. In the forums, a community member proposed a new EXT4 mount option called rralloc (round-robin allocator) designed to reduce allocation hotspotting and improve tail latencies for high-concurrency workloads. Additionally, interest continues to grow around the proposal to create a systemd-sysexts SIG.

There are several immediate opportunities for contributor engagement this week. The team is actively seeking code reviews and local testing for a major Ignition pivot PR and an Afterburn configuration logic PR. Furthermore, the QA team has issued a call for Fedora 45 Test Days, inviting community members to propose and organize testing events for upcoming features via Fedora Forge. Finally, the team welcomed apiaseck back to the FCOS release rotation.

Decisions

The team agreed to file a formal change request for an Ignition RPM update to boost its visibility and promote the feature to potential users, even though a formal request is not strictly required by the release process.

Learn more about the CoreOS team.

IoT

During the Fedora IoT Working Group Meeting, the team reviewed OpenQA test results for current and upcoming releases. For Fedora IoT 44 (Stable), a new test failure surfaced for rpmostree-rebase on x86_64 and aarch64, alongside a known iot_clevis failure. Meanwhile, Fedora IoT 45 (Rawhide) tests improved after a recent x86 failure and are currently looking stable enough for Rawhide.

In broader community news, the migration of Fedora IoT repositories from Pagure to Forge is expected to happen very soon, potentially within the week. The team is currently waiting on the necessary group creation before moving things over, which contributors should keep in mind for upcoming engagement and issue tracking.

Learn more about the IoT team.

Cloud

This week, the Cloud group received a call for Fedora 45 Test Days proposals. Contributors and community members are encouraged to review the accepted Fedora 45 ChangeSet to identify features or areas of the distribution that would benefit from focused testing. Anyone interested in organizing or hosting an online test event can propose one by filing a ticket on Fedora Forge, making this an excellent engagement opportunity to help ensure the quality and stability of the upcoming Fedora 45 release.

Learn more about the Cloud team.

AI & ML

The Fedora AI initiative has relocated the repositories for the AI Developer Desktop Remix. Contributors and interested community members can now find and engage with the project at its new organization home on Codeberg. This migration is an important update for existing developers to ensure their local environments are synced with the new upstream location, and it provides a centralized hub for the broader Linux community to explore the remix.

Learn more about the AI & ML team.

RISC-V

During the June 23 meeting, the RISC-V group confirmed that Fedora 44 is being kept up to date with major package bumps, including GCC. The Fedora 45 rebuild has officially started with an initial focus on language toolchains, and the team is preparing for a Python 3.14 to 3.15 rebuild utilizing bootstrap sidetag strategies discussed in a recent Flock lightning talk. To avoid workflow disruptions, existing contributors should note that the dist-git overlay has been officially migrated from the old fedora.riscv.rocks infrastructure to forge.fedoraproject.org/riscv/.

Hardware capacity for the architecture continues to grow, with two SpacemiT K3 systems recently added to the Fedora Koji builders to maintain build momentum, and two more on the way. Finally, the group shared their Flock presentation slides and highlighted an open planning ticket for contributors interested in joining the discussion on the long-term roadmap for promoting riscv64 to a primary Koji architecture.

Learn more about the RISC-V team.

Security

The Security SIG met to discuss improving meeting structures, predictability, and ticket prioritization to prevent contributor burnout and maximize meeting value. To help contributors better prioritize their time and know when specific issues will be discussed, the team agreed to start publishing meeting agendas in advance rather than relying solely on ticket labels or ad-hoc discussions.

Additionally, Fedora's CRI-O packager put out a call for SELinux experts to help investigate a potential CRI-O, composefs, and SELinux bug affecting Fedora CoreOS. This presents a highly focused opportunity for contributors with SELinux knowledge to engage and assist with a critical container runtime issue that impacts the broader Linux container ecosystem.

Learn more about the Security team.

Gaming

This week, a community member proposed packaging nbsdgames for Fedora. This project is a lightweight collection of 21 terminal-based games that depends solely on ncurses. Because the author is unfamiliar with Fedora's specific packaging guidelines, this serves as an excellent, low-barrier engagement opportunity for an existing or new contributor looking to help expand the Fedora Games repository. To assist potential packagers, the author noted that using make nb or make nbinstall during the build process will easily prevent any naming conflicts with other existing game packages.

Learn more about the Gaming team.

Perl

This week, the Perl group's activity was centered around routine package maintenance. Specifically, Jitka Plesnikova opened and successfully merged a pull request to bump the perl-App-cpm package to version 1.1.2, addressing bug report rhbz#2492221.

Learn more about the Perl team.

Other Discussions

A guide was shared on how to properly set a Fedora profile picture using Libravatar, including troubleshooting login loops and avatar update delays.
Meeting notes for the Hummingbird project clarified its relationship with Fedora and defined "Agentic OS" simply as Linux with Kubernetes and standard GitOps workflows, rather than autonomous AI magic.
A recap of the Fedora Mentor Summit at Flock 2026 highlighted successful Lunch & Learn sessions and community-building activities like sticker matching.
The 2026 Fedora Contributor Recognition Program Winners were announced, celebrating Ankur Sinha, Fabio Valentini, and Justin Forbes for their outstanding community contributions.
A thread initially about an AI bot making unauthorized Bugzilla changes evolved into a deep discussion about Two-Factor Authentication (2FA), exploring recovery token strategies and Kerberos ticket renewals via sssd-kcm and GNOME Online Accounts.
Following FESCo's decision, the 2FA policy for provenpackagers is now active, prompting discussions on using kinit with Yubikey OTPs and obtaining 7-day renewable Kerberos tickets.
A Change Proposal for a minimal GRUB bootloader tailored for Confidential Computing and Unified Kernel Images (UKIs) sparked debate over whether to include filesystem drivers (like Btrfs) or rely solely on FAT and the EFI System Partition.
A discussion addressed the policy violation of shipping pre-built WASM and ELF binaries inside node_modules source archives, leading to proposals for new tools like npm2rpm to automatically strip them.
A request to package AWS s2n-tls and aws-lc raised concerns about the responsiveness of the Fedora Crypto Team and whether the strict gatekeeping process for new cryptographic libraries needs reform.
A proposal to explicitly permit macros like %rhel, %centos, and %hummingbird in spec files was met with pushback from some developers who consider %rhel an antipattern that causes packaging divergence.
Other discussions this week included a call for Packager Dashboard maintainers, feedback on Node.js metapackages, help with git authentication for package releases, new helper scripts for upstream releases, an issue with redhat.com emails failing DMARC, handling Sphinx autodoc in RPM builds, optimizing compose disk space, addressing unmerged CMake 4 PRs, GCC plugin version dependencies, ideas to improve the Changes Process, centralizing GNOME SRPM macros, a planned infrastructure outage, the migration of the FESCo ticket tracker, a call for F45 Test Days, the disabling of F42 chroots in Copr, identifying package metadata in side-tag testing, and the resolution of git fsck issues in 71 package repos.

New contributor introductions

Joshua Thomas introduced himself on the fedora-join list, expressing interest in contributing to QA and leveraging his homelab environment for Rawhide testing.

Orphaning packages

Non-responsive maintainer checks were initiated for the fastnetmon, pyserial (where the maintainer subsequently replied), and ledger packages.
The showtime, python-poetry-plugin-export, and libgsasl packages were officially orphaned or announced to be orphaned soon.
Developers expressed interest in claiming and unorphaning the fx and python-persist-queue packages.

Package updates

A mass rebuild was coordinated for the fmt and spdlog upgrades, overcoming temporary Koji builder stalls.
A Change Proposal was announced to update libxml2 to version 2.15.3, requiring a system-wide mass rebuild and deprecating its Python bindings.
Rebuilds were announced for the libcamel soname bump in evolution-data-server 3.61.1 and the Openbabel-3.2.0 upgrade.
License changes were noted for the powdertoy and perl-Graphics-Toolkit-Color packages following upstream updates.

misc fedora bits: end of june 2026

Posted by Kevin Fenzi ( Fedora Account System Username

kevin ) on 2026-06-27 18:22:49 UTC

Time for a recap of the last week in my #fedora infra space (here in longer form).

Overall this week was a bunch of catch up from being away at flock, along with recovering from Jetlag.

RHEL10 migrations

I scheduled an outage on thursday for the last of the external colo virthosts to get a RHEL10 reinstall. I had tried to do it in the last outage, but I wasn't able to do it in the normal way that preserved all the guests data. This time I managed to get it done, but it took longer than I would have liked and I hit a number of fun issues:

Using a remote console I can't hold down shift to get a grub menu, so I had to hit escape at the right time.
rdp for Fedora is not great still. gnome-connections is still the winner, but even it has quirks.
The /boot/efi partition still did not want to let me reformat it as part of the install. I thought it was because there was a spare in the raid1 for it, but I grew it to use that spare and it still didn't help. So, I ended up just deleting it and recreating it.

Finally all reinstalled, reprovisioned and all the guests brought back up.

There's still a number of hosts to move, and we are down to trickier ones, but we will look at another outage probibly week after next to do more.

2fa in Fedora

Fesco decided to require all provenpackagers to enroll a 2fa token. There's a lot of talk about expanding that to packagers, or even everyone.

I thought I would share some info around this for interested folks who may not have seen it in all the various threads or tickets:

The Fedora account system frontend (noggin) supports enrolling TOTP tokens. Once you enroll one you must use it to login to the account system, to get a kerberos ticket, and to login to any web application with your fedora account.

You can (and should!) enroll more than one token. As far as I know, there's no limit to number you can add. You can also disable or delete tokens, so long as you still have one token enrolled. ie, you can never delete the last one. Any enrolled, non deactivated token will work to authenticate you. So, it's good to have at least one saved off to a safe place in case you loose access to your primary token.

If you somehow loose access to all your tokens, the recovery process is to mail admin@fedoraproject.org and you will be asked to prove you are you. This may be a gpg signed email (with the key associated with your account), using your ssh key associated with the account, or other means.

So, please make sure you have a backup token to avoid that. :)

TOTP is pretty common and has been around a long time. Lots of software is capable of storing your secret and displaying tokens.

s390x builds backup and koji session bug

On friday morning our koji s390x builders were getting swamped. It was the same story with a lot of large builds taking up builders so other things couldn't get in. Or so I thought at first, but on digging there was another problem. It was caused by a koji bug (already fixed upstream, but not released yet). This caused tasks to get freed and just sit there and not progress.

I have applied the patch and updated our hubs, and then went through and reassigned all the tasks I could see that were still having problems. Let me know if you see any I missed.

I also pulled in 2 more builders to the general build pool

One I had set to only do kernel builds a while back when we were trying to get security updates out fast.
One was a compose host, but I think we can be fine with one less compose host.

So adding those two helped process the backlog too.

I've also filed another request for more resources, but so far it hasn't really gone anywhere. ;(

Some PTO next week

Next week, I am going to be taking thursday off and friday is a holiday in the US, and I am taking off the following monday too.

Of course I'll still be around, but possibly doing other things. :)

As always, comment on the fediverse: https://fosstodon.org/@nirik/116823567269032135

onak 0.6.5 released

Posted by Jonathan McDowell ( Fedora Account System Username

u1f35c ) on 2026-06-27 15:44:00 UTC

I had intended that the next release of onak, my OpenPGP keyserver, would be 0.7.0, and include OpenPGP v6 support (RFC9580). However events conspired to make a 0.6.5 release a really good idea.

Firstly, I threw an LLM at the code base and asked it to review it. This isn’t intended to be a post about LLMs, but there’s a considerable amount of pressure at work to be “AI native”. I’m very much an “AI” sceptic, so I figured throwing it at a code base I know well might be an interesting exercise. It did find a bunch of embarrassing mistakes, but I don’t think there was anything earth shattering that a human reviewer wouldn’t have pulled me on. The problem is with a hobby project with a single user there’s no actual review of my work.

I also enabled GitHub’s security scanning. It mostly complained about format strings, and those were easy enough to fix up.

Next I threw AFLplusplus at the code. I’d previously tried American Fuzzy Lop, but not in some time. AFL++ found a whole bunch of places I should really have checked available buffer lengths and wasn’t doing so. It really is an incredibly easy tool to get up and running.

valgrind is also a tool I’ve used before, and rate highly. Thankfully it didn’t find anything in my testing this time.

Finally I threw a few more automated tests into the mix and discovered something has changed around dynamic linking such that the libonak symbols in the dynamic key database backends were using private copies, rather than the main binary. This caused problems with seeing the correct configuration settings in some instances.

All in all this release is not my proudest moment; a bunch of the issues fixed should never have made it to a release.

(Also, just to explicitly state it, all the actual code in this release was artisanly crafted by me, in vim. The only involvement of an LLM was for a review pass.)

Available locally or via GitHub.

0.6.5 - 27th June 2026

Lots of fixes/improvements around length checking

Added extra basic tests for maxpaths/sixdegrees/CGI

Correctly end transactions in the stacked backend

Ensure the file backend avoids stale key data on updates

Fix decoding of v2/3 signature creation times

Fix EdDSA signature parsing when r < 249 bits long

Fix migration of bools from old to new config style

Fix parsing of new config details for DB parameters

Fix problems with linking + dynamic backends

Fix RSA-SHA2-384 signature checking

Fix sixdegrees parsing of keyids with high bit set

Handle failures in maxpath more gracefully

Make new style config path match old path

Migrate Fedora OS via partition cloning efficiently over network

Posted by Kamil Páral ( Fedora Account System Username

kparal ) on 2026-06-26 17:01:08 UTC

How to migrate Fedora OS from one system to another, across network or (better) a Thunderbolt connection, without cloning the whole disk contents, saving SSD life.

Background

When migrating a Linux installation from a source drive to a target drive of a different size, traditional block-by-block tools like dd don’t allow to migrate to a smaller drive, and also waste SSD life by writing unused blocks. This guide describes a simple approach in which different disk sizes can be used, and the process is performed over network (or Thunderbolt), so that it’s not necessary to place two physical disks in the same device. The target system is exactly the same as the original, with all partition and filesystem UUIDs staying the same, which means no post-migration OS configuration is necessary. The time and SSD wear is minimized by pre-shrinking partitions and skipping unallocated disk space entirely. The default Fedora Workstation disk layout is supported, including LUKS encryption of the system partition.

This guide expects the following disk layout:

			
/dev/nvme0n1p1 -- ESP (most often FAT)
/dev/nvme0n1p2 -- Boot partition (most often Ext4)
/dev/nvme0n1p3 -- System partition (most often Btrfs, optionally encrypted using LUKS)

For simplicity, this will not try to skip copying all unused blocks, just most of them. The first two partitions will be cloned in raw mode. The third partition will be shrunk first (thus saving lots of blocks from being copied, and also supporting smaller target drives), and then cloned in raw mode.

Migration steps

Shrink the system partition on the source system

On the source system:

Delete all necessary data, prune cash dirs, empty the trash, etc.
Boot to a Fedora Workstation Live system from a USB drive.
Install necessary tools: sudo dnf install gparted pv
Run Gparted. In it, unlock the system partition, if encrypted. Then shrink the partition to a reasonable degree. For example, if the partition has 950 GB (from a 1 TB disk), but only 300 GB is used, you can shrink it e.g. to 350 GB. That still leaves enough free space for regular usage if you had to boot it for any reason, and saves 600 GB from being copied needlessly. This operation might take some time, because any data blocks currently present after the new size limit will need to be moved (therefore don’t be too aggressive in setting the limit). If your partition was encrypted, make sure that both the LUKS encryption container and the filesystem inside it correctly show up as resized.
Unmount all partitions (if any), lock the encrypted partition (if applicable) and close GParted.

Erase the target system

On the target system:

Ensure that this is really the system you want to completely erase (and replace with the OS from the source system).
Ensure that the disk size is sufficient to fit all partitions from the source system (now that the system partition on the source system has been shrunk).
Boot to a Fedora Workstation Live system from a USB drive.
Install necessary tools: sudo dnf install sfdisk sgdisk
Unmount all partitions (if any). You can use e.g. GNOME Disks for this.
Erase the whole drive (make sure you’re using the correct system): sudo wipefs -a /dev/nvme0n1
Discard all blocks on your drive (better for your SSD longevity): sudo blkdiscard -v /dev/nvme0n1

Establish an Ethernet/Thunderbolt network link

If you have both systems connected to the network and intend to use it, skip the Thunderbolt setup section below. Instead figure out the IP addresses of both systems (using the ip address command) and go to the Connectivity test.

Thunderbolt setup

If you want something faster than a regular network, have Thunderbolt ports on both systems and a fast USB-C cable ready, you can use that instead. With Thunderbolt, you can transfer data with 10 Gb/s speeds or more, compared to the common 1 Gb/s of a standard Ethernet.

On both laptops, after connecting them through a Thunderbolt cable, locate the network interface name: ip link
Look for an interface like thunderbolt0.
Assign static IP addresses to them:

Source system:
bash sudo ip addr add 192.168.5.1/24 dev <interface_name>
sudo ip link set <interface_name> up
Target system:
bash sudo ip addr add 192.168.5.2/24 dev <interface_name>
sudo ip link set <interface_name> up

Connectivity test

Let’s use a well-named variable for both numbers, so that we don’t mix them up later. On both systems, run:

   export SOURCE_IP=192.168.5.1
   export TARGET_IP=192.168.5.2

Test connectivity between your systems.

From the source system: ping $TARGET_IP
From the target system: ping $SOURCE_IP

You should see both systems pinging the other system correctly.

Replicate partition table from source to target

This will make an exact copy of the source system partition table (including partition UUIDs) on the target system. Then we will adjust it to the different disk size.

On target system, start listening for data and save it:

   nc -l -p 2000 > table.txt

On source system, dump the partition table and send it over:

   sudo sfdisk --dump /dev/nvme0n1 | nc $TARGET_IP 2000

On target system, apply the partition layout to the disk:

   sudo sfdisk /dev/nvme0n1 < table.txt

And then fix the GPT backup header location (because it’s unlikely that you have both disks of exactly the same size):

   sudo sgdisk --move-second-header /dev/nvme0n1

Copy all partitions

Everything should be ready now to transfer all partitions data.

Clone the ESP partition (p1):

On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p1 bs=4M

On source system, send the data:

   sudo dd if=/dev/nvme0n1p1 bs=4M | pv | nc $TARGET_IP 2000

Clone the Boot partition (p2):

On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p2 bs=4M

On source system, send the data:

   sudo dd if=/dev/nvme0n1p2 bs=4M | pv | nc $TARGET_IP 2000

Clone the System partition (p3):

On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p3 bs=4M

On source system, send the data:

   sudo dd if=/dev/nvme0n1p3 bs=4M | pv | nc $TARGET_IP 2000

Expand the System partition on the target system

Now that the target system is a complete clone of the source system, you can expand the System partition to fully utilize the remaining disk space:

Install GParted on the target system: sudo dnf install gparted
In Gparted, unlock the system partition, if encrypted. Then enlarge it according to your preferences. If your partition was encrypted, make sure that both the LUKS encryption container and the filesystem inside it correctly show up as resized.

Reboot the target system

You can now reboot the target system, and you should see your OS and data exactly the same as on your source system. The process is now complete.

Boot problems

In case the target system has a very different hardware from the source system (e.g. a different brand of a graphics card), the drivers might be missing from the current kernel initramfs and you can see a black screen or kernel errors. In that case, reboot the system again, press F8 repeatedly during boot to get into the GRUB bootloader menu, and boot the rescue Fedora option, instead of the default one. That should hopefully boot using the generic image (which should contain all known drivers), and then you can regenerate all the kernel images using your current hardware setup with: sudo dracut --regenerate-all --force

Mentions of other cloning approaches

Using dd
This works fine when cloning to a larger disk (if you fix the partition table afterwards), but unused blocks are written needlessly (wearing down SSD), and migrating to a smaller drive is problematic.
Native Btrfs streams using btrfs send and btrfs receive
This perfectly copies only used blocks of the main partition, but it only submits a single subvolume. Which means there’s some extra work needed to make sure exactly the same subvolumes are replicated from source to target. Also, this works above the LUKS encryption, which also needs to be created manually on the target (while keeping IDs, etc).
Using Clonezilla
Clonezilla will copy LUKS partitions as raw data, because it can’t see inside. Furthermore, it doesn’t support cloning to a smaller drive by default (there are some tweaks in Expert Mode, but you need to repair the GPT backup table manually anyway).

The end of the AArch64 desktop experiment

Posted by Marcin Juszkiewicz ( Fedora Account System Username

hrw ) on 2026-06-26 11:18:00 UTC

After about eleven months of using an AArch64 desktop, I decided to end that experiment.

Hardware used

About a year ago, I bought myself an Ampere Altra system. After moving some hardware around and making a few extra orders, the final setup was:


CPU	Ampere Altra Q80-30 processor (80 cores at 3.0GHz)
RAM	128 GB (8x 16GB HMA82GR7CJR8N-XN)
GPU	AMD Radeon RX6700XT
NVME	Lexar LM970 2TB ADATA SX8200 Pro 1TB
Motherboard	ASRock Rack ALTRAD8UD-1L2T
PSU	MSI MPG A850G (850W)
Case	Endorfy 700 Air
USB3	no-name USB 3.2/10Gbps controller (PCIe x4)

To be fair, I should mention that this is a server motherboard, not a desktop one, and Altra systems were never meant to be desktops (despite companies selling them as such). Naturally, the list of tested/approved devices (Qualified Vendor List (QVL for TLA fans)) is quite short and for Ampere Altra systems, it does not contain AMD Radeon GPU cards. They can be made to work, but this often requires additional effort.

The extra USB 3.2 controller allowed me to have more USB devices than the motherboard alone supported, and gave me some 10Gbps ports for connecting external NVMe drives.

The whole system was running just fine^* under Fedora 42–44.

The first issue

Have you noticed the small “*” at the end of the previous paragraph? The system I used was not quite Fedora — I had to use my own, self-built kernel.

You see, the PCI Express controller in the Ampere Altra has some issues. Let me quote the description of the Ampere Altra erratum 82288 patches:

Per Altra family erratum, PCIE_65 may cause invalid addresses to be generated on PCIe mmio writes, impacting certain device types, notably AMD GPUs, and thus the Altra family is not generally compatible with those device types.

And longer description from patch itself:

PCIe device drivers may map MMIO space as Normal, non-cacheable memory attribute (e.g. Linux kernel drivers mapping MMIO using ioremap_wc). This may be for the purpose of enabling write combining or unaligned accesses. This can result in data corruption on the PCIe interface’s outbound MMIO writes due to issues with the write-combining operation.

The workaround modifies software that maps PCIe MMIO space as Normal, non-cacheable memory (e.g. ioremap_wc) to instead Device, non-gathering memory (e.g. ioremap). And all memory operations on PCIe MMIO space must be strictly aligned.

So, to have a working Linux system, I had to rebuild the kernel on every package update. Which usually meant “weekly”. Each Monday or Tuesday, I would update the local copy of the Fedora kernel package repository and build it using my own versioning scheme, like “7.0.2-200.fc44.pcie65.6”. The “pcie65” part reminded me which patches I had applied, and the “6” was a counter for the patch rebases.

I cloned the repository from GitHub and then rebased patches, adapting them whenever they needed work. The side effect was that I often used a newer kernel than the official Fedora release — there is a “stabilisation” branch in the Fedora kernel package repo where the soon-to-be-pushed version is present. So, when Fedora had 6.19.y kernel, I had 7.0.z one.

So many cores, not enough speed

As I wrote in my previous post, having eighty CPU cores does not mean that the system is a good, fast desktop machine.

AMD GPU started failing

As I mentioned above, to get my AMD Radeon RX6700XT running properly I had to alter kernel with the out-of-tree patches. It worked, I could play some games, watch videos with hardware-assisted video decode acceleration.

Until one day, around the Linux 7.0 release, when it started to fail. Running a game ended with:

kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0

Over and over again. Watching YouTube videos became impossible due to 720 out of 750 frames being dropped, etc.

Normally I would start to bisect the kernel to find out where the problem is. But I was running a tainted kernel due to PCIE65 patches so who knew where the problem actually was…

Let’s get Nvidia

I bought an Nvidia RTX 2060 graphics card and put it in place of the AMD Radeon. It turned out that if I wanted to use it with the nouveau kernel driver I still needed PCIE65 patches applied…

So I tried default Fedora kernel with Nvidia binary driver. And it worked fine. Video decoding was accelerated, some games under Wine worked as well.

But then I started FreeCAD. And OrcaSlicer. And in both cases I got crash and exit…

It turned out that there was no org.freedesktop.Platform.GL.nvidia in Flatpak repositories for AArch64. And I used both of those tools quite often.

Powering up the old x86-64…

At that point, I gave up. And booted my x86-64 system, which had been powered off all that time. There were a lot of cables to move, some new ones to arrange, and now I have both “wooster” (Ampere Altra) and “puchatek” (Ryzen 5 3600) systems running under my desk.

Moving from 80 cores to 6 cores (12 threads) was a weird experience. A much smaller number, yet things work fine. I can load all threads and the music still plays. All games from my Steam library are playable. A working FreeCAD allows me to finish designing cases for my home projects and I can 3D print prototypes straight from OrcaSlicer.

The “wooster” system stays powered on, churning through RISC-V package builds. It may be weak in single-thread, but it flies when it comes to multi-core load.

Conclusion

As for the Ampere Altra, I am not planning to repeat this experiment. Another AArch64 desktop attempt would require a completely new hardware platform. And I have no plans to spend over twenty thousand PLN to buy an Nvidia DGX Spark system.

Community Update – Week 26 2026

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-26 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: 22 – 26 June 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

CentOS Infra including CentOS CI

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 Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

Attended/interacted with some Folks contributors (remotely attending and chat in matrix rooms)
Rebuilt quite some dependencies for calligrabot/robosignatory for centos stream 10 infra change (https://redhat.atlassian.net/browse/CS-3402)
Continue to work on all needed package rebuild phase for stream signing infra change (https://redhat.atlassian.net/browse/CS-3402)
Rebuilt already 48 rpm pkgs for infra10s for centos stream signing upgrade (https://redhat.atlassian.net/browse/CS-3402) but unfortunately more to come
Sprint planning meeting
Claude helped me writing sms (standup-matrix-summarizer) which can be used to retrieve your “Done” section from each daily standup report, combine that into weekly view so that you can just then copy/paste into manager google doc. See https://gitlab.com/CentOS/infra/containers/standup-matrix-summarizer (and https://quay.io/repository/centos-infra/sms?tab=info)
Rebuilt more pkgs for centos stream infra but also had to find workaround for orphaned pkg (https://redhat.atlassian.net/browse/CS-3402)
Rotate some api keys for SIGs (https://gitlab.com/CentOS/infra/tracker/-/work_items/1940)
Started to work on ansible boot-server role to convert for el10 and isc dhcpd replaced by kea (https://gitlab.com/CentOS/infra/tracker/-/work_items/1936) – WIP
PoC for kea dhcp replacement for isc dhcpd gone from el10 (https://gitlab.com/CentOS/infra/tracker/-/work_items/1936)
Created other tickets for .stg. stream el10 staging signing service (network ports for fedora-messaging stg rabbitmq hosts and two new service principals) – https://redhat.atlassian.net/browse/CS-3414
Closed ticket (review) about all dependencies built and available for el10 robosignatory/calligrabot (https://redhat.atlassian.net/browse/CS-3413)
Prepared staging host for centos-stream signing (https://redhat.atlassian.net/browse/CS-3414) but now blocked with a fedora infra staging issue (rabbitmq) so tried the whole day to debug but need someone from Fedora infra side to solve the issue there
Riscv64 discussion about a new p550 hardware firmware upgrade
Tested and validated that RH network team opened needed port for rabbitmq.stg.fedoraproject.org

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

F45 rebuild started — we’re trying to first focus on language toolchains — need to refer to Miro’s lightning talk from Flock on how they handled Python bootstrap
F44 is being kept up2date (there were some big updates, including GCC)
Kevin did the legwork to move away from old dist-git on fedora.riscv.rocks to forge.fp.o
Another K3 builder in Fedora Koji — another member added. (This might sound like a tame update, but all compute power is helpful / important to keep the build momentum :-))
Discussed some details of riscv64 in primary Koji ticket
Slides for Flock RISC-V update

AI

This is the summary of the work done regarding AI in Fedora.

The AI Developer Desktop Remix repos have moved to an org on codeberg (https://codeberg.org/project-resistor)

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

Flock & DevConf attendance, lruzicka gave a talk on openQA test investigation, adamwill gave a lightning talk with cle about Fedora CI improvements, several of us were involved in a workshop/roundtable about the viability/desirability of moving all testing to dist-git PRs, lots of productive side conversations etc., many about AI – trip reports / blog posts coming
On-demand openQA test of dist-git PRs in progress
Looks like we maybe found some new maintainers for packager-dashboard
Lots of work to enable testing of the huge OpenSSL 4 update for Rawhide, investigate a significant bug that showed up, and eventually bypass the test failures for that bug as it’s proving not to be possible to resolve in a reasonable time (the update needed to get merged)
Continued tech debt / enhancement work on blockerbugs, testdays-web and issuebot

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

PTOs & travel
On Zabbix staging, now have a working template to monitor the Forgejo runnerhost VM and the runners themselves
Continued work on Private Issues (private comments refactoring)

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

Beta Wallpaper ticket closed

List of new releases of apps maintained by I&R Team

Patch update of Fedora Messaging from 3.9.0 to 3.9.1 on 2026-06-23: https://github.com/fedora-infra/fedora-messaging/releases/tag/v3.9.1

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 26 2026 appeared first on Fedora Community Blog.

Fedora Documentation translations again available

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-26 09:19:27 UTC

Updates to translations of Fedora Documentation are again available. As announced on March 3rd, the unavailability of translation updates was due to the migration of the translation repositories and necessary tools from Pagure to the Fedora Forge. It took longer than expected but we are pleased to report this undertaking came finally to the end.

The post Fedora Documentation translations again available appeared first on Fedora Community Blog.

Flock 2026 and Devconf.cz 2026 trip report

Posted by Adam Williamson ( Fedora Account System Username

adamwill ) on 2026-06-26 08:45:01 UTC

Long time no blog, once again - as always, I'm mostly posting on Mastodon now, so follow there if you're missing the Content. This is a bit big, though, so it goes here!

I was in Prague for Flock 2026 and Brno for Devconf.cz 2026 recently. Didn't have any issues with travel, fortunately. I was in Prague a day early for a Red Hat "face-to-face", which went fine. Had a fairly quiet/jetlagged dinner with Kevin and Tomas on the first night, and a nice dinner with Lenka Segura, Kashyap Chamarthy, Cristian Le, Frantisek Lehman and Laura Barcziova on the second night; most of them I was meeting for the first time in person, which is always good.

Flock 2026

Flock started for real the next day with workshops. I started with "The Future of Fedora Atomic", about how we can reach the goal of all the Atomic images being based on a shared bootc base container, then went to "Forging Fedora Project’s Future With Forgejo". In the afternoon I went to "PR-based Gating for Fedora: Can We Make It Work?", which was about the idea of moving all automated testing/gating to run against dist-git pull requests (instead of mainly against updates, as is the current case).

These were all more "talking shops" than "workshops", really, but they at least mostly produced interesting conversations and concrete ideas. In particular, Cristian and I were able to determine a set of priorities for Fedora CI from the "PR-based gating" session - there was a lot of discussion of potential issues and concerns further down the road of the potential migration, but in the end we found it pretty clear that we need to improve the reliability of the existing tests and pipelines, and the ease of interpreting the results, and that's uncontroversial work that can be done first.

There was also a request from Petr Khartskhaev that we make it possible to run the openQA tests on dist-git pull requests. This had already been requested by Mo Duffy before. I've resisted doing this for all dist-git pull requests because I know at least some would fail when changes to multiple packages need to be grouped and tested together. The update system allows us to group builds into updates, but dist-git does not yet have any way to mark multiple PRs as a logical group for testing/promotion. However, someone suggested a better idea: do it by request, not for all PRs automatically. So I decided to go ahead and do it. Instead of doing another workshop, I hid in the corner of the "Languages in Floss" session and bodged up a working prototype, which is deployed to staging openQA. If you comment /openqa test on a dist-git pull request, tests on it will run in staging openQA. I'm currently working on getting the results reliably reported back to the pull request.

We had a team dinner that evening, again good to meet people and a good mix of work and social chat. At some point in there I met our relatively new RH team member Jaroslav Groman in-person for the first time, which was great - he's been doing excellent work on digging out from under our tooling tech debt and it's great to have him aboard. Peter Sklenar unfortunately wasn't able to come this time.

Day two was session heavy. There was an opening keynote track with Jef's "State of Fedora" address, live Fedora Council and FESCo meetings (effectively), and a Hummingbird talk from Stef Walter. The State of Fedora produced a couple of very talked-about sets of statistics, one showing Fedora (and friends) usage climbing solidly and one showing Fedora contributor numbers declining worryingly. The usage numbers are great, of course - especially the rapidly-growing numbers for KDE and our awesome downstream distro friends (the uBlue-verse, Asahi, Bazzite et. al.) We definitely need to dig into the contributor numbers some more, see what's going on, and whether and what we need to do to reverse the trend. There are a lot of interesting questions about whether it's Red Hatters, community maintainers, or both who are declining, and how this relates to other trends like the CVE tsunami, mushrooming language ecosystems, the rise of Flatpaks / Snaps / AppImages and so on.

The Council and FESCo sessions touched on those topics and several others, though interestingly not the AI Desktop proposal which I was kinda expecting to hear a lot about. I kinda tuned out and hacked through some of them to be honest. Stef's talk gave a good clear overview of Hummingbird - I kinda knew it going in, but it's always good to have it summarized quickly and clearly (at least I thought so).

I unfortunately didn't know about the Lunch and Learns (somehow missed them on the schedule), or else I would have gone to some! But still had plenty of fun/productive lunches with various folks. In particular I met Vít Smolík (smoliicek) in person, which was great. He's been helping out with the data team and infrastructure team and is doing some great work.

In the afternoon I went to the "Packit and Fedora: The CI Story Continues" talk, which was a good summary of the work to rationalize the mess of different systems we have/had testing pull requests. It's much better than it was before. Then I went to "Fedora Server – What you can expect from the next two releases", which was great because it clearly explained the idea of the "Home Server" spinoff which I hadn't really been clear on. And of course it was good to see Peter Boy and Emmanuel Seyman again. Alexander Bokovoy also explained his latest authentication stuff, which as always I didn't entirely understand but filed under "sounds like Alexander has it under control"...

I skipped another session to do some hacking, then went to "The Engineer’s Guide to Design", which was really interesting - I like going to slightly off-the-beaten-path talks. I don't really work on front-end UX stuff a lot, but it was still interesting to hear a perspective from someone who's been both an engineer and a designer on the impedance mismatches that can happen and the basic concepts it's useful for both sides to know about the other. Then I saw "Artifact Signing in Fedora", where Jeremy Cline gave some background and an overview of his ongoing project to rewrite the Fedora signing server, which is badly-needed work that we're really grateful for.

In the evening we had the official party, at a really nice outdoor food court with a reserved space for the conference. The organizers brought over so many appetizers I barely needed to use the meal ticket, but managed to force down some tacos nevertheless. Had a great time chatting with various folks, then later headed to a Belgian beer bar for more drinks with Justin Forbes and several others.

On the final day I started with "The Packager's Guide to openQA Failures" of course - Lukas Ruzicka (my openQA henchman) did a great job covering openQA failure analysis from the perspective of a packager, and I contributed a few notes here and there. We had a good crowd who seemed really interested, which is always great news. After that I saw Kevin Fenzi's "scrapers gotta scrape scrape scrape" talk on all the fun we've been having with scraper networks flooding our infrastructure. I know some but not all of it beforehand, and of course Kevin explained it well and the audience was very engaged. Plus I got to tell my story about the time I thought a dastardly new scraper network had figured out how to evade Anubis, but it turned out that the call was coming from inside the house (i.e. I had done a slightly silly thing in openQA which made it effectively DoS Koji...)

After the coffee break I saw "Fedora Test Days - a11y", which was actually a somewhat wider talk from a couple of RH folks working on accessibility testing about their current testing and future plans. It was really interesting and it was good to be able to speak with them briefly about the possibilities of using openQA for this. I stayed in the same room for "Two Years In: Accelerating Microsoft Contribution to Fedora", where Jeremy Cline, Brian Exelbierd and Reuben Olinsky covered some Microsoft's (much-welcomed) contributions to Fedora and also some stuff about Azure Linux.

After that was "Upgrading Fedora Infrastructure from Nagios to Zabbix" - this migration has been ongoing for a while but was much-needed as a modernization and also a better architecture. I found it very useful as I do have plans to add more detailed monitoring of openQA and the talk was very helpful in letting me know how to get started with that.

After lunch came lightning talks. I had proposed one about "new stuff we did in Fedora CI lately", which kinda overlapped with some of the full-length talks in the end, but it still got a lot of votes, so Cristian Le and I went up second and did a rapid redux of the Packit consolidation work, improved result displays, optimizations and improvements to the generic tests, addition of rmdepcheck and so on. My voice was giving out by this point but we just about got through it. There were a lot of other great talks and everyone managed to come in under time, which was impressive.

After that was a Fedora Mindshare session which I half-followed and half-hacked/dozed through (was starting to get tired at this point!), then the "Fedora’s Contributor Recognition Program" session where much-deserved awards were handed out to Ankur Sinha, Fabio Valentini and Justin Forbes. I was on the voting panel for this so it was great to see the culmination, and the trophies contributed by the Nairobi GNU/Linux Users Group were awesome.

I almost forgot to mention the whole time I was struggling with some sort of wifi driver bug - it seems there was a troublesome AP or something at the hotel which caused my laptop to crash constantly. And the hotel wifi was terrible, and I only had 5GB of data on my phone, so I couldn't really rebase to F44 to avoid it. Lots of fun.

Devconf.cz 2026

That was the end of Flock; things wound down and I had dinner with...some people...somewhere (possibly the third Vietnamese of the trip? Things are getting fuzzy). The next day was a welcome quiet day traveling from Prague to Brno - train and bus, no problem except waiting for the bus was very hot. I stayed at the Hotel Vaka, which I've never been at before, but it's quite nice. The whole event was a bit weird because Moto GP (the motorbike equivalent of Formula 1) moved their Brno race to the same weekend Devconf.cz would usually be on, and took all the hotels, so devconf was hastily moved to Thursday/Friday. Hotels were still hard to get and I only just managed to grab this one at a decent rate. I was able to rebase my laptop finally and stop worrying about wifi crashes, and had a nice quiet pizza dinner at Doe Boy.

So a shortened devconf started with the opening session, then another Hummingbird keynote, this time with Valentin Rothberg as well as Stef Walter. It added a bit of detail compared to Stef's Flock talk, and there wasn't anything else on. Then I saw "OpenShift CI: What if we stopped retesting everything all the time?", which was an interesting talk about the tradeoffs involved in doing automatic retests of complex merge chains in a big project with lots of PRs trying to be merged all the time (OpenShift). It wasn't directly applicable to anything I do, exactly - Fedora updates don't quite map to PRs in a git repo - but in a more general sense it was useful in suggesting methods for thinking about this kind of complex tradeoff and how to measure the impact and efficiency of testing processes.

Next I saw David Duncan's "From Laptop Chaos to Fedora Cloud: Quadlets and Containers", mainly because it was David, but it turned out to be a good talk about a way to make a relatively complex multi-container side project buildable and deployable the same way on your laptop and in The Cloud, using systemd quadlets. I've dealt with this general area before a few times. David made a solid case that quadlets are a good approach, in his usual fun and personable style.

After that I saw Zbigniew's "New security features in systemd" - honestly I missed some of this one, but got the gist of why systemd is trying to modernize various mechanisms here. Then I went to "Beyond the Screen: A Deep Dive into Linux Accessibility for Developers" by Vojtech Polasek, which was one of my highlights of the week - a really good explanation of how computer interaction really works for blind people, and what properties applications should have (and avoid) to make them usable. This is obviously very important for testing purposes.

Next I went to "Stop Looking for the Perfect Prompt: The Design-First Workflow for Coding Agents" to get my corporate mandatory minimum AI Content(tm) - it was actually a pretty good and accessible talk on different approaches to LLM-based feature development. I still don't really use LLM code generation heavily (for a start, I spend so little time actually sitting at a blank screen typing significant amounts of code that it's not really worth worrying about), but it's good to keep up with the latest ideas about how to do this kinda thing. Continuing with the AI theme I took in Tomas Tomecek and Laura Barcziova's "How AI helped us ship updates in a Linux distro", which was a practical talk on the system behind Hummingbird and the actual approach it takes to (sort-of) AI-driven package builds.

After that I think I did some Fedora booth cover for a while. Lukas Ruzicka and Vojtech Trefny were holding the booth down for most of the weekend, but I stopped by and did an hour here and there to give them some relief. It's always a lot of fun chatting to people about Fedora, other distributions or stuff that has nothing to do with Linux at all. Lukas had set up a Framework laptop with a MIDI keyboard attached to show off that it's pretty practical to do audio creation on stock Fedora kernel and audio stack these days; Vojtech and I had absolutely no idea how to use it, so we had lots of fun trying to talk about it to people and eventually telling them to come back when Lukas would be there...

In the evening we had the conference party, which was at the same outdoor swimming pool it's been at for a couple of years(?) now. It's a great venue - you can grab some food and a drink and then relax in the shade under some trees. I wound up sitting round with a really interesting mixed group of folks (Red Hat and non-Red Hat, some big cheeses, some medium-size cheeses and some fresh faced...cheese curds? Help, my metaphor is falling apart) most of the night, it was a great evening. Walked back most of the way to the hotel with Stef Walter, setting the world to rights as is the tradition after a few drinks at conference parties...

On the second day I started with "From Podman to Production: Building Trusted Container Images with Konflux on OpenShift" by Vladimir Sokolenko, which was probably the most understandable and useful Konflux talk I've seen so far. I think I then maybe did a bit more booth cover(?) and some hacking, then wrapped up with a nice three-talk track in the same room - "Identical Testing Environments from Laptop to CI with tmt and Testing Farm" by Cristian and Petr Šplíchal (covering their work to make tests more reproducible from Testing Farm to your local system), "systemd-sysext in Production: What We Learned Extending /usr Without a Package Manager" by Brian Exelbierd and Daniel Zaťovič (a really good retrospective on their experience using sysext in the real world to ship additional / alternative software on Flatcar), and "Local package layering on bootc systems with DNF5" by Evan Goode (explaining his design and plans for providing a convenient, dnf-ish interface to "overlaying" packages on bootc-based installs). I met Evan in person for the first time at the party, and it was great talking to him. I hope his work on this goes well - we really need it for the glorious bootc-based future.

After that was the traditional wrap-up session with the trivia quiz (I won a t-shirt!) and then I said bye to a lot of people and melted off (it was extremely hot) to the train station...to find that my train to Vienna was delayed by nearly an hour. Ah, well. Eventually made it to my hotel in Vienna (which was incredibly nice, just wish I'd stayed there longer...) and had an excellent dinner at Iki (highly recommended if you're in the area). Got in a couple of swims in the nice-but-small hotel pool before and after sleeping, then had a Vienna take on avocado toast (interesting!) for breakfast and headed off to the airport, and that was another trip in the books.

Friday Links 26-21

Posted by Christof Damian ( Fedora Account System Username

cdamian ) on 2026-06-25 22:00:00 UTC

Shaggy sheepdog sculpture on a plinth in a gallery

This week I enjoyed the last episode in the Industry Special from Escape Collective about Chinese brands. The Overnight Success podcast is worth subscribing to, even if you are not into bicycles. It’s about founders and their businesses.

Quote of the Week

The technologies we use to try to “get on top of everything” always fail us, in the end, because they increase the size of the “everything” of which we’re trying to get on top.

Four Thousand Weeks

Oliver Burkeman

Leadership

Struggle Creates Value - “We are going to, and we need, to struggle together.”

Planned Outage - download-ib01, torrent, people outage

Posted by Fedora Infrastructure Status ( Fedora Account System Username

admin ) on 2026-06-25 20:00:00 UTC

We will be reinstalling the virthost that runs download-ib01, torrent.fedoraproject.org and fedorapeople.org. During the outage these sites will be down.

Not all policy enforcement needs to be automated

Posted by Ben Cotton ( Fedora Account System Username

bcotton ) on 2026-06-25 12:00:00 UTC

I am a big proponent of the “don’t make rules you can’t (or won’t) enforce” maxim. The careful reader will notice that the word “automatically” does not appear anywhere in that advice. Automated policy enforcement is good. It reduces maintainer burden, gives the community a consistent experience, and…you know…makes sure the project’s policies are enforced.

Sometimes automated policy enforcement is easy. There are plenty of tools out there to require a certain degree of password length/complexity, ensure commits have a DCO signoff, and so on. Sometimes the technical implementation is harder. That doesn’t mean the policy can’t go forward.

The Fedora Engineering Steering Committee just decided to require two-factor authentication for members of the provenpackager group (people who have essentially project-wide privileges for package maintenance). In the discussion about whether to adopt such a policy, folks pointed out a few legitimate concerns. The account system can’t require two-factor authentication for only a specific group. Some entry points to the packaging systems are accessible with an SSH key, which limits the protection of a two-factor authentication policy.

These are both good arguments. The counter argument is that such a policy improves the security of the project, even when unevenly followed. Manual audits can check for ongoing compliance.

In general, you can rely on good-faith actors to follow policies that are:

well reasoned with meaningful benefit to the project or the person
clearly and obviously communicated
well documented with a reasonably smooth user experience.

If all of those are true, and you have some way to manually check compliance, then it’s okay if the enforcement can’t be automated. This is especially true when partial compliance is a meaningful improvement over a default of zero compliance.

This post’s featured photo by Dim Hou on Unsplash.

The post Not all policy enforcement needs to be automated appeared first on Duck Alignment Academy.

Fedora at XV P.I.W.O. Poznań Free Software Fest

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-25 10:18:38 UTC

On Saturday May 30th 2026, the XV edition of P.I.W.O. Poznań Free Software Fest was held in Poznań, Poland.

P.I.W.O. is an event with a long history. Between 2004 and 2018, it was organized by various student associations at the Poznań University of Technology. After 2018’s XIII edition (superstition much?), it entered a long hiatus that lasted until 2025, when members of the newly-formed Knyfyrtel Poznań Hackerspace decided to bring it back. The reactivated event proved a huge success, with the XIV edition bringing in 197 attendees. As such, ambitions for 2026 were rather big.

Teamwork makes the dream work

This year’s edition was the result of combined efforts of three Poznań-based organizations:

Knyfyrtel Hackerspace Poznań
“Webrains” Students’ Scientific Association at the Adam Mickiewicz University
“Linux Academic Group” Students’ Scientific Association at the Poznań University of Technology

Photo of the organizing team, with 26 people visible in the picture. That's not the whole team!

Thanks to Webrains, for the first time in its history, the event was held at the Adam Mickiewicz University in Poznań – namely, the uni’s Faculty of Mathematics and Computer Science. Also a historical first, the XV edition was granted honorary patronage by the President of Poznań City Council.

Busy, busy day

The event spanned almost the entire Saturday, opening at 9:30 am and closing at 7:35 pm. The agenda was tightly packed, featuring 3 lecture tracks with 24 talks, 2 workshop tracks with 8 activities, plus a LAN Party track with 3 tournaments, as well as “free play” sessions. There was also a quiet corner where, thanks to the “Honte” group, attendees could relax and learn to play Go.

Throughout the years, one of P.I.W.O.’s hallmarks was the lunch break, with the attendees being provided free pizza. This year couldn’t be any different, with some 66m² (or 710 ft²) of pizza being delivered to the venue. (It disappeared frighteningly quick.)

Photo of the event hall, with the organizers setting up tables with pizza.

Focus photo of one of the organizers bringing in 5 boxes of pizza.

The Fedora Community was represented by:

Zbyszek Jędrzejewski-Szmek, who gave 2 (!) talks
Mat Holmes, who volunteered as a photographer
Kacper Skrzyński, who handled various urgent tasks
Artur Frenszek-Iwicki, who gave a talk and held a workshop session

Historical moment: creation of SPOIWO

This year’s P.I.W.O. served as an opportunity to announce the creation of SPOIWO – Sojusz Przyjaciół Otwartego i Wolnego Oprogramowania (Alliance of Friends of Open and Free Software). This diverse coalition of social and technology organisations, cooperatives and open source businesses signed a declaration in support of digital sovereignty. The alliance was formed in response to the ever-deepening of public institutions’ dependency on closed platforms and their loss of control over data and communication.

Group photo taken after the signing ceremony of the SPOIWO declaration. The printed declaration is visible in the back, propped up above the heads of the people in front.

The signing ceremony also featured speeches by representatives of SUSE Poland, Polish Linux User Group, “Internet. Czas działać!” Foundation and PLZ Spółdzielnia.

Exceeding all expectations

The event wrapped with 452 attendee badges issued, which exceeded even the most daring of expectations. (The number also explains why the pizza disappeared so quick.) The bar for the next edition is set high, but so are the organizing team’s ambitions.

Photo of the people gathering at the freebie table, taken from the upper balcony.

Photo of the event hall, showing the mass of people present during the lunch break. Taken from the upper balcony.

If you’d like to learn more about the event, watch the live stream recordings, or subscribe to news so you won’t miss the announcement for the XVI edition – you can do all of that on the event’s website, at piwo.sh.

The post Fedora at XV P.I.W.O. Poznań Free Software Fest appeared first on Fedora Community Blog.

Partial Outage - 2 of 5 Openshift workers down

Posted by Fedora Infrastructure Status ( Fedora Account System Username

admin ) on 2026-06-25 09:30:00 UTC

Some hosts are being relocated and have been taken down for that purpose. OCP workers 04 and 05 are on the list.

While this should have been transparent to end users, it has caused unforseen consequences with the Apache LoadBalancer setup for Openshift Apps, when requests mistakenly get sent to …

De CentOS Stream 9 a 10 con leapp

Posted by Rénich Bon Ćirić ( Fedora Account System Username

renich ) on 2026-06-24 12:50:00 UTC

Ahora te voy a contar una de esas aventuras de SysAdmin que te ponen a sudar frío, pero que al final te dejan con una sonrisa de oreja a oreja.

Acabo de migrar mi servidor físico de CentOS Stream 9 a CentOS Stream 10 usando Leapp. La neta, aunque el proceso es noble, me topé con varias broncas en el camino (desde falta de espacio en boot hasta conflictos de red) y aquí te dejo el mapa completo para que usted, ¡pare de sufrir!

El Parote de Dracut Hostonly

Antes de que pudiera siquiera pensar en correr el preupgrade, me di cuenta de que mi partición /boot (de apenas 1 GB) estaba al 65% de capacidad. Como DNF necesita instalar el nuevo kernel y Leapp requiere mínimo 100 MB libres para maniobrar, no se iba a armar la cosa.

Como tengo XFS sobre LVM en la raíz (y esa chingadera no se puede encoger online ni offline), no podía simplemente reparticionar el disco. Por fortuna, hace un ratito te conté cómo apliqué el paro definitivo para tu boot con dracut hostonly.

Siguiendo esos pasos, reduje el peso de cada RAM disk de ~235 MB a ~69 MB. Eso me devolvió ~330 MB libres de inmediato, dejando mi boot al 32% de uso y abriendo la puerta para continuar con el upgrade sin tener que andarme metiendo en desmadres de reparticionar discos en vivo.

Note

La neta es que, mi servidor físico (local), no está en producción. Nomás que... me da weva conectarle un monitor y un teclado para moverle...

Preparando Leapp y el Preupgrade

Con el espacio libre resuelto, instalé las herramientas necesarias para la migración. En CentOS Stream, esto se hace a través de los paquetes de ELevate:

dnf install leapp-upgrade-el9toel10

Una vez instalado, corrí la herramienta de diagnóstico para buscar inhibidores (bloqueos del sistema):

leapp preupgrade

El Desmadre de ifcfg y los Inhibidores

El reporte inicial me arrojó un inhibidor de alto riesgo: Legacy network configuration found.

Resulta que en CentOS Stream 10 se eliminó por completo el soporte para los viejos archivos ifcfg-* en /etc/sysconfig/network-scripts/. Si no migras esto, tu tarjeta de red no va a levantar al reiniciar y tu servidor va a quedar incomunicado en la calle.

Migrar la conexión a formato `keyfile` (nativo de `NetworkManager`): Utilicé la herramienta nativa de NetworkManager para convertir el perfil.
```
nmcli connection migrate enp6s0
```
NetworkManager automáticamente borró el archivo ifcfg-enp6s0-1 y creó el nuevo perfil estructurado en /etc/NetworkManager/system-connections/enp6s0.nmconnection.
Limpieza de systemd: Leapp también detectó symlinks rotos de servicios viejos (como vdo.service y zabbix-server-mysql.service) que andaban estorbando. Los borré de volada:
```
rm -f /etc/systemd/system/multi-user.target.wants/zabbix-server-mysql.service /etc/systemd/system/multi-user.target.wants/vdo.service
```

Corrí de nuevo leapp preupgrade y esta vez arrojó exit code 0 (¡libre de inhibidores!). Aunque advirtió que mi procesador (AMD Family 15h) ya no tiene soporte oficial por Red Hat, verifiqué con el linker que soporta la microarquitectura x86-64-v3 sin bronca.

La Gran Migración

Con el semáforo en verde y mis respaldos al día, arranqué la descarga de paquetes. (mentiras... ni respaldé nada...)

Warning

¡Mucho ojo con la sesión SSH! La descarga e instalación del entorno temporal pesa más de 2 GB. Si tu SSH se desconecta por timeout a la mitad del jale, el proceso padre va a morir por un error de "Broken pipe" y va a tronar el instalador gacho. Para evitar desmadres, lo ideal es correr todo dentro de una sesión de tmux (o screen) para que puedas desconectarte y reconectarte sin perder la ejecución:

# Iniciar una sesión de tmux
tmux new -s upgrade

# Correr el upgrade
leapp upgrade

Si por alguna razón la red parpadea o se te cierra la sesión, sólo tienes que volver a conectarte y restaurar el cotorreo con tmux a -t upgrade.

Cuando el comando terminó con éxito y me indicó que todo estaba listo, ejecuté el reinicio:

reboot

El sistema se apagó, cargó el kernel especial de actualización (ELevate-Upgrade-Initramfs), ejecutó la transacción de paquetes y se volvió a reiniciar de manera automática.

Verificación y Limpieza Final

Al volver a entrar por SSH, verifiqué que ya estaba del otro lado:

cat /etc/os-release

Ya chingamos: CentOS Stream 10 (Coughlan)` con kernel 6.12.0.

Sin embargo, el comando systemctl is-system-running me devolvió el estado degraded. El culpable era el servicio systemd-networkd-wait-online, el cual estaba habilitado por una instalación vieja pero no tenía perfiles activos (ya que NetworkManager controla todo el desmadre).

Lo desactivé para dejar el sistema limpiecito:

systemctl disable --now systemd-networkd systemd-networkd-wait-online systemd-networkd.socket
systemctl reset-failed

Volví a checar el estado y finalmente quedó en running. ¡Chulada de sistema!

Conclusiones

La neta es que migrar con Leapp es bastante fácil si sabes leer los reportes y previenes los bloqueos antes de reiniciar. La clave de esta historia fue optimizar dracut y no dejar ningún perfil ifcfg de red vivo.

¿Qué te parece? ¡¿Te avientas la actualización de tus servidores a CentOS Stream 10?! Si no te animas, échame un grito. :)

Referencias

Dracut hostonly: El paro definitivo para tu /boot de 1 GB

Posted by Rénich Bon Ćirić ( Fedora Account System Username

renich ) on 2026-06-24 11:45:00 UTC

Hoy me topé con un dolor de cabeza clásico de los que administramos servidores: la partición /boot de uno de mis servidores físicos (dev1.casa.g02.org) andaba agonizando. Apenas medía 1 GB y ya estaba al 65% de su capacidad. Con el upgrade que andaba haciendo, meter otro kernel iba a hacer que todo valiera madres por falta de espacio.

La primera ocurrencia lógica es: "pues le quito espacio a la raíz (/) y se lo paso a /boot". Pero, ¡oh sorpresa! Mi partición raíz está formateada con XFS y vive dentro de un volumen lógico (LVM). Para los que no sepan, XFS no se puede encoger (shrink). Así que esa idea valió madre de volada.

Investigando las entrañas del sistema, me di cuenta de que cada imagen de initramfs generada por dracut pesaba la grosería de ~235 MB. ¿Por qué tanto desmadre? Resulta que por defecto, el sistema las compila en modo "genérico", empacando todos los drivers habidos y por haber por si decides mudar el disco a otra compu.

Pero como mi servidor es una máquina física bien establecida, ¿para qué quiero drivers de Hyper-V, VMware o NVMe si mi disco es un SATA común y corriente? Ahí es donde entra la magia del modo hostonly en dracut.

Configuración de Volada

Para no andar batallando en el futuro, creé una regla persistente para que todas las futuras imágenes de boot se compilen optimizadas:

Crear el archivo de configuración: Creé un archivo drop-in para dracut con la opción mágica.
```
# /etc/dracut.conf.d/hostonly.conf
hostonly="yes"
```
Regenerar las imágenes: Reconstruí los RAM disks para todos los kernels instalados para aplicar el cambio inmediatamente.
```
dracut -f --regenerate-all
```
Verificar el espacio: Chequé cuánto espacio gané con este parote.

Resultados del Parote

El resultado de esta optimización fue inmediato y super chido:

initramfs-5.14.0-691.el9.x86_64.img: Bajó de 234 MB a 69 MB.
initramfs-5.14.0-710.el9.x86_64.img: Bajó de 235 MB a 69 MB.
initramfs-5.14.0-710.el9.x86_64kdump.img: Bajó a 43 MB.

¡Me ahorré más de 330 MB en total! El uso de la partición /boot bajó del 65% al 32%, dándome espacio de sobra para varios kernels más sin tener que andarnos preocupando por fallos de espacio en la siguiente actualización de DNF.

Warning

¡Ojo con la portabilidad! Si decides mudar tu disco físico a otra máquina con hardware totalmente diferente, el sistema podría no arrancar porque el initramfs optimizado no tendrá esos drivers. La ventaja es que la imagen de rescate (rescue) siempre se genera en modo genérico, así que puedes bootear con ella y volver a compilar el initramfs para el nuevo hardware.

Conclusiones

La neta es que es mejor optimizar lo que ya tienes antes de meterte en desmadres de reparticionar discos en caliente, sobre todo cuando tienes XFS en el camino. Con una sola línea de configuración le di un respiro enorme a la máquina y me ahorré un dolor de cabeza enorme.

¿Cómo la ves? Si andas sufriendo por espacio en tu partición de boot, ya te la sabes: ¡dale una oportunidad a hostonly, no?!

Referencias

Global Roaming on Google Fi and Linux

Posted by Dennis Gilmore ( Fedora Account System Username

ausil ) on 2026-06-24 03:45:50 UTC

I have a 5G modem in my Lenovo x13s and t14s. I run Fedora on them, currently Fedora 44. I have had issues in the past when traveling. The 5G modem works fine when in the US but will not connect to any provider when roaming. It has worked after some time in the UK and Australia, but not in other countries. I use Google Fi for phone service, which allows roaming with the same data allowance as in the US.

After some digging during my current trip, when it wasn’t connecting, I think I have found the issue and a workaround to ensure I can connect. Google Fi uses two networks, T-Mobile in the US and Three UK when roaming. It also uses T-Mobile for roaming. The issue seemed to be that the towers were rejecting the SIM card, attempting to register using T-Mobile’s default APN that seems to be baked into the SIM card as a default profile. The ModemManager logs looked like the following

ModemManager[1603]: <msg> [modem0] 3GPP packet service state changed (unknown -> detached)
ModemManager[1603]: <msg> [modem0] 3GPP packet service state changed (detached -> unknown)
ModemManager[1603]: <msg> [modem0] 3GPP packet service state changed (unknown -> detached)
ModemManager[1603]: <msg> [modem0] 3GPP packet service state changed (detached -> unknown)

The trick that got it to connect was to make a change to the default profile used to connect to the phone tower was to run an mmcli command: “mmcli -m 0 –3gpp-set-initial-eps-bearer-settings=”apn=h2g2,ip-type=ipv4v6” Which forces the sim to use the Google Fi APN and not the T-Mobile one

Community Update – Week 25, 2026

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-23 10:12:46 UTC

Week: 15 – 19 June 2026 (Flock Week!!)

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

Helped getting elnbuildsync moved into stg openshift (ongoing).
A couple more services had OS upgrades to Fedora 44.
Some more MirrorManager problems.
Scrappers found another ostree repo. on kojipkgs, limited dir. indexing to stop the attack and then searched for any other ostree repos. Hopefully the last time it happens.

CentOS Infra including CentOS CI

Finish rebuilding/bumping some pkgs for ppc64le libvirt/qemu-kvm stack on el10 (https://gitlab.com/CentOS/infra/tracker/-/work_items/1928)
Start to work on debuginfo origin servers refresh with el10 instances (https://gitlab.com/CentOS/infra/tracker/-/work_items/1892)
More coordination work with Stream team about secureboot issues (https://redhat.atlassian.net/browse/CS-3400)
Finishing last debuginfo pool members reinstall (https://gitlab.com/CentOS/infra/tracker/-/work_items/1892)
Decommission old openstack env for stream (https://redhat.atlassian.net/browse/CS-3404)
Cloud SIG doc url change (migration to gitlab, from pagure) – https://gitlab.com/CentOS/infra/tracker/-/work_items/1934
internal requests (FRCL and audit compliance)
Move another SIG doc url (away from pagure.io) – https://gitlab.com/CentOS/infra/tracker/-/work_items/1938
Modified the aws load-balancer settings for one ocp tenant (https://gitlab.com/CentOS/infra/tracker/-/work_items/1932)
Migrate haproxy load-balancers to el10 for stream dc-move prep (https://redhat.atlassian.net/browse/CS-3353)

Release Engineering

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

Migration at 95%, the only thing left to migrate is majorly fedora-scm-requests, bug fixes, and continued releng operations.
Migration: archive-repo-manager from pagure
Fix: Missing permissions on releng/fedora-comps
Bug Fix: Mass tagging script for verification bits
F45 Change Sets reviews are in check and f45-python side tags are merged.
Regular releng operations.

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

We’ve started searching for new owners/maintainers of Packager Dashboard and Oraculum

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

Completed the Flock To Fedora 2026 presentation on Fedora → Forgejo migration efforts #588, packaged and deployed Forgejo 15.0.3 #620.
successfully ran the PR fix doctor across all migrated repositories #601 to address merge issues with Pagure imports.
Enhanced runner infrastructure with the addition of a Testing Farm runner option #619 and docker-slim type runner #568, and improved security by deploying oauth-proxy to secure the Forge metrics endpoint #571.

EPEL

This team is working on keeping Epel running and helping package things.

Updated caddy in rawhide, resolving 14 CVEs
Ongoing onboarding of Pedro

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

With Flock this week, got to see how all the final designs turned out it in person!
Emma delivered her talk on ‘Why You Should Use Open Source Design in Open Source’ at Flock
Great progress on the F45 wallpaper in the final stretch!

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 25, 2026 appeared first on Fedora Community Blog.

Community Update – Week 24, 2026

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-23 10:07:47 UTC

Week: 08 – 12 June 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

Request for CentOS Alternative Images SIG URL Update
Wiki upgrade problems/patch with FedoraMessaging when editing a page
Staging wiki down due to PluggableAuth extension issue
Move all remaining Fedora 42 instances to 44
Deploy DRM Panic Frontend
Switch from session-based OIDC to Authentication Bearer
Move the Fedora Badges static assets from Pagure to Forgejo
badges: fix image trigger annote order on deploy metadata
List authorization in CORS headers for API routes

CentOS Infra including CentOS CI

Release Engineering

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

Change Set Review for F45
Script improvement and feature addition (in-progress):
- fix(orphans): handle alternative providers to eliminate false positives
- Fixes #9841 – adds a release_type field to .composeinfo so we can tell Beta and Final releases apart.
Regular Releng Operations
Fedora 42 EOL Preps

AI

This is the summary of the work done regarding AI in Fedora.

Testdays (the webapp we use for running…Test Days) has an MCP server now (not sure if it’s deployed in prod yet though) – work by Jaroslav Groma

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

Executive summary: Python 3.15 and kmscon Changes landing caused some fallout, tool tech debt payoff / enhancement continues, most team members used Day of Learning for AI experimentation
Two major Changes landed: Python 3.15 and kmscon consoles, various fallout from that:
- CoreOS and IoT both broken by the kmscon change
- Got on-the-fly keyboard layout changes added (important for openQA)
- Kickstart installs broken by Python 3.15 change (sent a fix)
- Various openQA test updates required for kmscon fixes
openQA serial bug worked around, new packages now deployed to prod
Tech debt repayment and new feature work continue on testdays, issuebot and blockerbugs
Kparal continues to find bugs in Lenovo laptop support
Work on ELN kernel gating got blocked by an unfortunate pre-existing design problem
Worked with Cristian Le to get rpmdeplint pipeline updated so fixes from last ~year are in prod, it now runs in ~2 minutes instead of ~20
Team did some AI agent / skills experimentation during Day of Learning

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

`testing-farm` optimized runner option provided to `ci` and `atomic-desktops` organizations
Regular runners capacity increased from 1 to 4 concurrent jobs
Private Issues work is ongoing.

EPEL

This team is working on keeping Epel running and helping package things.

Executive summary:
Completed archiving of EPEL 10.1
Package maintenance across multiple Fedora and EPEL packages
Quality work via bug reports and bodhi karma

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

Final stretch prepping Flock materials – Fedora badge, livestream template, sponsor splash
Progress being made on the F45 Wallpaper
Emma gave a talk about the Fedora Design team at the Waterford office’s Fedora 44 Release Party last Wednesday

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 24, 2026 appeared first on Fedora Community Blog.

From June 15 to June 21

Posted by Aurélien Bompard ( Fedora Account System Username

abompard ) on 2026-06-22 06:27:00 UTC

A primary focus across many groups was the upcoming Fedora 45 release cycle, which drove the submission and discussion of several key Change Proposals, including system-wide updates to LLVM 23 and a multi-widgetset Lazarus IDE. This release preparation was accompanied by significant package maintenance, highlighted by the major OpenSSL 4.0 update and its mass rebuild, compatibility work for Python 3.15, and security-driven package replacements in EPEL. Another common thread was the evolution of core infrastructure, with teams managing the migration from Pagure.io to Forgejo and the transition from Nagios to Zabbix for system monitoring. Community testing was also a crucial activity, with efforts centered on the new KDE Plasma 6.7 release and the restoration of Google Drive integration in GNOME. Finally, improving community processes was a recurring theme, with discussions on creating a new SIG for systemd-sysexts and enhancing security by mandating 2FA for packagers.

Announcements
FESCo
Workstation / GNOME
KDE
Infrastructure
Release Engineering
Quality
Docs
Internationalization
EPEL
Atomic
CoreOS
AI & ML
Security
Perl
PHP
Other Discussions

Announcements

This week's announcements focus on the upcoming Fedora 45 release cycle and evolving infrastructure. A reminder was sent out for the upcoming deadlines for F45 Changes, with two new proposals already submitted: a system-wide update to LLVM 23 and a plan to offer the Lazarus IDE with multiple widgetsets. On the infrastructure front, a post discusses the final steps for migrating from Pagure.io to the new Forgejo-based forge, while another provides a technical guide for onboarding Forgejo-hosted projects to Fedora Konflux. The Anaconda team is also seeking community input on a new web-based remote installation feature being built for headless systems.

In community news, a new Outreachy intern shared their experience working on the Fedora Release Schedule Planner API, highlighting a valuable contributor program. For the broader Linux community, a Fedora Magazine article details a practical method for how to sandbox AI coding agents with microVMs on Fedora Linux, addressing a modern security concern for developers.

FESCo

This week, discussions focused on several Change Proposals for the upcoming Fedora 45 release. New proposals were introduced to update the system-wide LLVM toolchain to version 23 and to offer the Lazarus IDE with multiple widgetset options (including GTK3 and various Qt versions), giving developers more choice beyond the current GTK2-only package. These proposals are now open for community feedback.

Discussions continued on previously submitted proposals. Regarding the Golang 1.27 update, it was noted that a fix for DWARF5 debugging issues is unlikely to be included in this release; developers needing this functionality are directed to a dedicated COPR repository. The libxml2 2.15 update, which will require a mass rebuild and deprecates the Python bindings, is awaiting consideration of feedback from the developer mailing list. A significant debate is ongoing around the proposal for a minimal GRUB EFI for Confidential Computing. While the proposal aims to create a smaller, more stable bootloader for Unified Kernel Images (UKIs), the discussion questions the rationale for not using systemd-boot, with conflicting information about the systemd maintainers' willingness to add necessary features.

Learn more about the FESCo team.

Workstation / GNOME

The main activity for the Workstation / GNOME group this week centered on the ongoing effort to restore Google Drive integration in GNOME. In the forum discussion "[Call for Testers] Restoring Google Drive integration in GNOME", a user inquired about installing the test packages on Fedora Silverblue. In response, instructions were provided on how to use rpm-ostree to replace the necessary system components from the testing COPR repository. This provides an opportunity for Silverblue users to contribute to testing this important feature.

Learn more about the Workstation / GNOME team.

KDE

This week's focus was the release and testing of KDE Plasma 6.7.0. The new version was made available for testing on Fedora 43 and Fedora 44, and the community was encouraged to help test and report bugs. In preparation for the final release, the COPR repository for the Plasma 6.7 beta was retired.

Discussions following the release highlighted several user-reported issues. Users on Kinoite noted that the network manager repeatedly asked for Wi-Fi passwords after rebooting; a workaround was discovered which involves entering the password in the main system settings instead of the connection pop-up. Other reported issues include a login loop for some users and desktop instability after clearing the Mesa shader cache. A dependency issue affecting kdevelop on Fedora 43 was also brought up, with the team noting it is a known problem related to a gpgme issue and is expected to be fixed after the Plasma update is pushed to stable.

Learn more about the KDE team.

Infrastructure

This week's activity was light as team members recovered from the Flock 2026 conference. The primary focus was on the monitoring system transition discussed in the main Infrastructure meeting. Nagios has now been officially decommissioned, and work is underway to remove its remaining components from all hosts. The team reviewed the current alerts in the new Zabbix monitoring system, identifying several noisy checks related to mail queues, file ages, and backups that will be tuned or investigated. The Daily Standup was a brief check-in, mostly acknowledging the post-conference recovery period.

Decisions

During the Infrastructure meeting, several actions were agreed upon to refine the new Zabbix monitoring setup:

The alert threshold for the mail queue on smtp-mm will be increased to reduce noise caused by spam bounces.
An alert for an out-of-date MySQL backup will be investigated.
The threshold for countme file age checks will be raised to prevent intermittent alerts.
The cause of unusually large log files on the dl03 mirror will be investigated.

Learn more about the Infrastructure team.

Release Engineering

This week, the Release Engineering group's activity centered on a community forum discussion. A user shared their detailed experience of successfully creating a customized Fedora 44 XFCE live ISO using the kiwi-ng tool. They described a multi-hour process of trial and error, highlighting solutions for common issues like user login configuration and providing practical advice, such as avoiding the /tmp directory for build outputs to prevent space-related failures. The user also sought help from the community on how to properly format and share their working config.xml file, presenting an opportunity for others to engage and assist.

Learn more about the Release Engineering team.

Quality

This week, the Quality team discussed several technical issues affecting development releases. A significant disruption occurred when a failing test, upgrade_server_domain_controller, blocked all Rawhide updates over the weekend. Other reported problems include broken Adwaita themes in XFCE on Rawhide due to the removal of gnome-themes-extra, a libvirtd service failure on Fedora 44 related to a ZFS module, and a temporary dependency issue preventing Thunderbird installation which was already being tracked. The team also welcomed a new contributor and announced the next QA meeting for June 22.

There are several opportunities for community involvement. Testers are needed for a new Synaptic-style GTK4 frontend for DNF5, which has received positive initial feedback. Additionally, the effort to restore Google Drive integration in GNOME continues, with instructions now available for testing on Fedora Silverblue. As always, volunteers are welcome to help with the validation of Fedora 45 Rawhide nightly composes.

Learn more about the Quality team.

Docs

This week, discussion continued on the long-running topic of a design proposal for Fedora's documentation. The conversation focused on the proposal's use of a tag-based system for organizing user documentation. Contributors expressed concerns about the reliability and consistency of manual tagging, suggesting it can indicate poor search functionality and structure. A preference was noted for traditional navigation methods like Tables of Contents for better topic discovery. As a modern alternative to manual tagging, it was suggested that Large Language Models (LLMs) could be employed for automated classification, which might prove more effective and less costly over a large set of documents.

Learn more about the Docs team.

Internationalization

This week, the Internationalization team announced a significant new collaboration: the MATE Desktop project has migrated its translation work to the Fedora Weblate platform. This move invites all translators to contribute to MATE applications and documentation directly within the Fedora infrastructure, strengthening the ties between the communities.

In other news, the community welcomed a new and proactive Norwegian translator, Arvind Frøiland, who introduced himself on the mailing list. Having already completed the Norwegian Bokmål translation for systemd, Arvind expressed a keen interest in contributing to other core components and requested reviewer permissions to help maintain and improve Norwegian translations more effectively.

Learn more about the Internationalization team.

EPEL

This week in EPEL was quiet, with a sparsely attended meeting due to the Flock conference. The main focus was on several significant package changes proposed on the mailing list. A key discussion is underway to replace the end-of-life p7zip package with the modern 7zip in EPEL 8 and 9 due to numerous unfixable security vulnerabilities in the older package. This is considered a slightly incompatible update, and an issue has been filed for community feedback and future discussion.

Other proposals seeking community input include the retirement of qt6-qtwebengine from EPEL 9 due to maintenance difficulties and a high number of CVEs, and a plan to update syncthing to v2 in EPEL 10 while retiring it from EPEL 8 and 9 because older dependencies prevent necessary security updates. Contributors, especially maintainers of packages that depend on these, are encouraged to participate in the discussions.

Learn more about the EPEL team.

Atomic

This week, discussion centered on a proposal to create a new Special Interest Group (SIG) focused on systemd system extensions (sysexts). The proposal, initiated by Jean-Baptiste Trystram, follows discussions at FLOCK 2026 and aims to formalize the building, documentation, and distribution of sysexts based on Fedora content. These extensions are seen as a key method for adding functionality to atomic systems, especially for software not well-suited for containers or Flatpaks. The primary goals for the proposed SIG would be to establish an official build process, potentially using Konflux, and to solve the open questions of distribution and discoverability. The idea has received positive engagement, with several contributors expressing interest in joining the effort.

Learn more about the Atomic team.

CoreOS

During the weekly meeting, the team reviewed upcoming system-wide changes for Fedora 45. A critical issue was discovered with the proposal to relocate RPM repository configurations to /usr. Because rpm-ostree relies on DNF4, this change is expected to break client-side package layering, a significant feature for users. This will be tracked closely. The team is also seeking a volunteer to investigate a bug related to another F45 change in fedora-coreos-tracker/issues/2160.

In the forums, a proposal was made to create a new Special Interest Group (SIG) for systemd-sysexts. The goal is to establish an official process for building and distributing system extensions, which offer a way to add functionality to atomic systems for software that isn't well-suited for containers. The proposal has received positive feedback and interest from several community members, presenting a new opportunity for contribution.

Learn more about the CoreOS team.

AI & ML

The AI & ML SIG met this week to discuss preparations for the upcoming Fedora 45 release, which is scheduled to branch on August 11, 2026. A key topic was the ongoing effort to update packages for the Python 3.15 release, which is causing the usual compatibility issues with torch and triton. The group plans for F45 to ship with ROCm 7.2, and work is underway on a compatibility package set to support this version on F46 when the next major ROCm release arrives. There is a strong interest in packaging local AI tools for F45, and contributors are needed to help review packages for the pi-coding-agent (Bugzilla #2464801) and the olla local AI proxy.

The idea of creating a dnf package group for AI/ML tools was briefly discussed but was ultimately deferred. The group felt it was too early to add this, given the complexity of handling different hardware backends (like ROCm) and the desire to avoid adding process overhead for the small number of active packagers. The meeting also touched on the status of OpenVINO, confirming that no one in the SIG is actively working on it at the moment.

Learn more about the AI & ML team.

Security

The Security SIG held its weekly meeting to discuss recent events and plan future work. Following the Flock conference, the group noted a new connection with Red Hat Product Security (RH ProdSec) and discussed concerns about documentation with security implications, which will be addressed soon. A major topic was the FESCo proposal to mandate two-factor authentication (2FA) for provenpackagers, prompted by recent security incidents in the wider open-source community. The SIG offered to support this initiative by helping with documentation and communications.

The team also triaged several issues, focusing on providing better support for package maintainers dealing with CVEs. This led to a decision to create a formal process for maintainers to request assistance. The group also briefly touched on tickets related to security-optimized sysctl settings and a protocol for skipping meetings. Contributors are encouraged to review and comment on the open tickets in the Security Forge and the Security Docs Forge.

Decisions

The SIG approved the proposal in ticket #9 to create a formal support channel for package maintainers needing help with CVEs. The plan is to add a ticket template to the security/tickets repository and announce the new process on the devel mailing list.

Learn more about the Security team.

Perl

This week's activity for the Perl group focused on routine package maintenance and an enhancement to packaging tools. The perl-PPIx-Regexp package was updated to version 0.092 via several pull requests. The perl-Net-DNS package was also updated to version 1.55, which included an update to the upstream GPG signing key. A notable improvement was merged for perl-rpm-build-perl, which now supports the package NAME VERSION; syntax to improve automated dependency generation.

PHP

A discussion was initiated by Remi Collet regarding a build issue for PHP extensions on EPEL-10.2. It was noted that extensions were incorrectly being built against the newer PHP 8.4 stack instead of the default PHP 8.3. This occurred because the build system selected php8.4-devel as the best provider for the php-devel dependency. A workaround has been implemented to ensure packages are built against the correct version.

Decisions

To resolve a build dependency conflict on EPEL-10.2, the BuildRequires for PHP extensions will be constrained to a specific version range (php-devel >= 8.3 with php-devel < 8.4). This ensures they build against the intended default PHP 8.3 stack. All affected extensions have already been rebuilt with this fix.

Learn more about the PHP team.

Other Discussions

A discussion was initiated by FranciscoD about improving the packaging workflow by creating a separate git repository for up-to-date .spec file templates. This would allow rpmdev-newspec to use current templates and could be integrated into a new fedpkg new command. Following the discussion, a spec-templates repository was created, and a pull request for a fedpkg new-package command was opened to implement this functionality.
Adam Williamson posted a heads-up that all Rawhide updates were being blocked by a failure in the upgrade_server_domain_controller test. He noted the bad timing post-Flock and devconf.cz and mentioned he was actively investigating to resolve the issue as soon as possible.
Brad Smith announced upcoming changes for the containerd package. A FESCo exception now allows all Fedora releases to have the same containerd version, constrained only by the Go version. Additionally, starting with v2.3.x, the containerd-shim-runc-v2 will be provided as a static binary, matching upstream, which should be a transparent change for users.
A change proposal for Fedora 45 was announced to update all LLVM sub-projects to version 23. This update will involve a soname version change for LLVM libraries and the addition of an llvm22 compatibility package. The plan is to push version 23.1.0 into F45 during the Beta Freeze, with release candidates being tested in COPR beforehand.
A change proposal for Fedora 45 was announced to offer the Lazarus IDE built with multiple widgetsets (GTK2, GTK3, Qt5, Qt6) instead of just GTK2. The lazarus-ide package will be renamed to lazarus-ide-base, and new sub-packages for each widgetset will be introduced. This will allow users to choose their preferred interface and will facilitate the eventual retirement of gtk2.
Aoife Moloney sent a reminder about the upcoming deadlines for Fedora 45 changes. The deadline for submitting System-Wide changes is June 30, 2026, and for Self-Contained changes is July 21, 2026. All changes must be in a testable state by August 11 and complete by August 25.
Gordon Messmer initiated a discussion on both the nodejs and devel lists about the presence of pre-built binaries in the node_modules directories of bundled Node.JS packages in Fedora. The consensus was that this is an oversight and not permitted by packaging guidelines. The conversation highlighted the fundamental difficulty of adhering to Fedora's policies with the NPM ecosystem, where dependencies often include pre-compiled or minified assets, making review and maintenance impractical. It was suggested that bugs should be filed for affected packages and a FESCo ticket opened to address the systemic issue.
Emanuele Petriglia inquired about the fx package, which was orphaned years ago due to issues with NodeJS packaging guidelines. Ben Beasley, the former maintainer, confirmed this was the reason and noted that since the tool has been rewritten in Go, the original packaging problems are no longer relevant, and it would be welcome back in Fedora.
Kamil Paral called for new maintainers for the Packager Dashboard and Oraculum.
C. S. Sushi proposed the creation of a Software Engineering SIG.
Other topics discussed this week include a request for help with a List.remove() issue inside a for-loop in Java, comments on a spam email promoting a code editor that was also sent to openSUSE lists, and the continuation of a long discussion on AI-driven contributions which pivoted to requiring 2FA for packagers. Technical discussions covered packaging guidelines for distribution conditionals, how to handle autogenerated documentation in RPMs, and the implications of swapping fedora-release on COPR compatibility for Remixes. Announcements were made regarding the sunset of pagure.io, a change proposal for libxml2 2.15, and another for a minimal GRUB EFI for Confidential Computing. Users sought help with a mockbuild failure in rawhide and a Bodhi update issue. Finally, there was a check on a non-responsive maintainer and a question about the OpenSSL 4.0 mass rebuild.

New contributor introductions

Benson Muite introduced himself to the 3dprinting SIG, expressing interest in using FOSS for making things and mentioning his work on reviewing FreeCAD to bring it back to Fedora.
Kenny Glowner introduced himself, seeking sponsorship to become a Fedora packager. He aims to adopt and maintain the orphaned ccze and sslh packages, with a long-term goal of rewriting them in Rust.

Package Updates

Ankur Sinha announced that highfive 3.3.0 is being prepared for Rawhide and listed the dependent packages that will be rebuilt.
The upgrade to openbabel 3.2.0 was announced for Rawhide, which will require several dependent packages like IQmol and avogadro2 to be rebuilt or updated.
Gwyn Ciesla announced an upcoming libupnp 2.0.2 build which includes a soname bump, and that all dependencies except the already-FTBFS eiskaltdcpp will be rebuilt.
František Zatloukal announced upcoming upgrades to fmt 12.1.0 and spdlog 1.17.0 in Rawhide, which will involve a soname bump and a mass rebuild of dependent packages in a side tag.
Gwyn Ciesla announced an update to QXlsx 1.5.1, which includes a soname bump. The dependent package LabPlot builds fine, while stellarium is already failing for other reasons.
Ben Beasley gave a heads-up about the upcoming update of abseil-cpp to version 20260526.0 in F45/Rawhide, which breaks ABI compatibility and will require a rebuild of all dependent packages in a side tag.
Mattia Verga announced an upgrade of libbox2d from version 2.x to 3.x in Rawhide, which includes a soname bump. The main consumer, libreoffice, will be upgraded at the same time.
Mamoru TASAKA announced an update for libetpan to 1.10.1, which involves a soname bump. The dependent packages cairo-dock-plug-ins and claws-mail will be rebuilt, but this will be postponed until after the OpenSSL 4.0 changes are merged.
Fabio Valentini announced that the libgit2 package has been retired in Rawhide as part of the Changes/Versioned_libgit2_packages implementation, and requested reviews for pending pull requests on packages that still need to be updated.
Milan Crha announced an upcoming evolution-data-server 3.61.1 release which includes a soname bump for libcamel. He plans to rebuild all affected packages in a side tag.
The OpenSSL 4.0.1 update has officially landed in Rawhide, along with 734 rebuilt packages. An openssl3 compatibility package is available for packages that have not yet been updated. Maintainers are urged to make their packages compatible before the F45 mass rebuild.
José Expósito announced plans to update mesa to v26.1.x in Fedora 44, coordinating with RPM Fusion maintainers. A discussion also started about the possibility of updating Mesa in Fedora 43 as well.

Orphaning packages

The weekly report of orphaned packages was sent out, listing numerous packages that are available for adoption and will be retired in six weeks if no new maintainer is found.
Fabio Valentini announced the intent to retire the rust-handlebars5 compat package in Rawhide, as the CLI tool it provides (handlebars-cli) is no longer part of the main handlebars crate in version 6.

Introducing dbranch 🍥→🤝

Posted by Michel Lind ( Fedora Account System Username

salimma ) on 2026-06-22 00:00:00 UTC

Caveat lector

This post discusses tools reluctantly written with AI assistance. If you don’t entertain using them under any circumstance, and think even reading about them legally compromise your ability to reimplement them yourselves, stop reading now

Today’s post introduces dbranch, a tool to update a Debian package in unstable, and rebuild downstream branches (currently supports Ubuntu PPAs and stable proposed-updates; backports support could be easily added once I have a package that needs it). Eagle-eyed readers might notice the naming similarity with my previous tool ebranch; and the credit for the name and inspiration eventually came from Jens Petersen’s fbrnch.

Flock and Devconf - Field Report

Posted by Miroslav Suchý ( Fedora Account System Username

msuchy ) on 2026-06-21 15:43:05 UTC

Flock

I was looking forward to this year’s Flock - Fedora Project Conference. I had to cut my vacation short and return from my river trip a day early.

I arrived in Prague at noon on Sunday, just in time to attend František Lachman’s workshop “PR-based Gating for Fedora: Can We Make It Work?”. We all agreed that we want all contributions to happen through pull requests and only after all tests pass. However, we also realized it is not easy: gating for multi-package PRs will be difficult (unless we have a monorepo). Proven packagers will need special handling (can we work on this later?), and first, we need the new Forgejo—everyone is looking forward to it. Coincidentally, later at Devconf, I spoke to Marcela, who mentioned that SUSE already has Forgejo for all packages and that it does not scale as they expected.
But the important message from Miro was: “we should not force maintainers to use a new workflow; we should make it pleasant and easy to use so they want to use it on their own.”

After this workshop, I checked into my hotel and later returned to the venue. We had a passionate conversation with Aleksandra, Miro, and Karolina during a card game. We then moved with several other people to a nearby pub that served Belgian beer. I had only one glass, but I felt very dizzy and tired, so I returned to the hotel sooner than the rest of the gang.

On Monday, I joined Collin for breakfast, and we discussed the dark corners of RPM building.
Then I moved to the venue and listened to Jef Spaleta’s “State of Fedora” talk. Fedora’s usage is growing, and KDE is working enormously well, but the decline in Fedora’s contributors is accelerating. We have to figure out why and take action, rather than just setting up plans without execution.

The “Fedora Council Strategic Proposals” session was great. Two highlights stood out:
“It’s not the new generation that is different. It’s you who is different,” said Aleksandra. “They talk about changing a wallpaper; we are talking about burnout.”

Aleksandra

“I would not join Fedora if it were stable. I want to improve it.” Jef Spaleta

Jef Spaleta

The subsequent “FESCo Q&A” was less vibrant but provided a great opportunity to learn about members' views. For newcomers, Kevin’s remark that FESCo’s role is sometimes to say “No” and stop things was likely interesting. However, FESCo cannot drive new initiatives; individual contributors must do that.

Then I watched Stef’s talk about Hummingbird; this was not new to me as we closely cooperate on agentic packaging.

Stef

I also observed the talk “Packit and Fedora: The CI Story Continues”, as it summarized what my team accomplished with Fedora CI. There were many examples, and the feedback was positive. I appreciated that Matej managed to substitute for Nikola, who got sick at the last minute.
Several ideas in the Q&A highlighted that PRs are not mandatory and that maintainers do not always follow upstream in a timely manner.

I attended “The EU CRA vs. Community: Why You’re Safe, and How Stewards Help”. The CRA was new to me, and the session was packed with concrete information. You may check the most interesting slides in my Mastodon post. The biggest takeaway is that open-source maintainers do not need to worry, but they should be prepared that companies using their software will start email-bombing them in August. There was a nice guide on how to politely reject them.

I took a break and talked to people in the hallway, sharing remarks with my team members. I talked with Kashyap about bootstrapping RISC-V; he was thankful for our support in Copr. We drafted next steps, only to find that Kashyap’s colleague already did that while I was on vacation.

I then observed “What’s Cooking in Copr, Testing Farm, tmt, Packit and Log Detective”, where Franta and people from my team shared our current work and future plans. It was great that Franta brought the team members on stage.

After this, I was quite tired, so I headed to the hotel for a quick nap and shower to get ready for the Official Party, which took place at Manifesto—a local market with various street foods. I met many familiar faces as well as new people.

On Tuesday I listened to Adam’s “RHEL 11 is branching from Fedora 46: What this means for you” talk and appreciated his honesty in answering “I do not know” to several questions. Later in the hallway, we discussed whether branching RHEL during the Fedora branching phase is ideal, and why we don’t branch during the beta phase instead.

I then moved to Kevin’s talk, “Scrapers Gotta Scrape Scrape Scrape”. This topic was familiar, as we are also fighting scrapers, and Jiri from my team helped package Anubis and its dependencies for Fedora. However, I learned several new things, and the follow-up Q&A was fun. If you think people ranting about scrapers only wrote inefficient web applications, you should definitely see a recording of this talk.

I attended Frederick’s talk, “Machine-readable package lifecycle information in repository metadata”. He spoke about their DNF plugin that can set various End-of-Life dates for different packages. This was extremely helpful, and since we wanted to do something similar in RHEL, I immediately emailed the DNF team to introduce them to Frederick.
After the talk, I bowed to Frederick, as he is reportedly the person behind the migration of AWS Linux to Fedora.

I listened to Microsoft’s talk, “Two Years In: Accelerating Microsoft Contribution to Fedora”. It was interesting to see how much Microsoft uses Fedora. The highlight was that the presenters were from different teams within Microsoft and were largely unaware of each other’s work.

I then talked to people in the corridor, including Bex, who introduced me to two students from Jihlava interested in a high school internship.

The highlight was definitely the lightning talks. They were strictly 5 minutes long (including notebook setup). I learned about current Lenovo support for Linux, how Miro sped up the last Python mass rebuild, and I reported on the current status of the SPDX migration, noting that the next steps will proceed without me. Fortunately, Max started a SIG that wants to take over the work. I shared some information with him that didn’t fit into the lightning talk. Jiri presented his achievement of packaging Goose for Fedora and even provided a live demo!

By this point, I was quite tired, so I passively watched the presentation of the Contributor Recognition Awards. Then, I went into the city to meet a friend, and we attended the theater performance Tahle země je naše.

Tip: If you want to see any mentioned talk, you can find it in the schedule and then rewind to the specific time in the Streams. The edited and cut talks are usually available weeks later on Fedora’s channel.

DevConf

DevConf CZ is huge even. With over one thousand participants and eleven tracks - it is huge. As this is a conference in my hometown I volunteered to help organizers: I chaired one of the rooms and acted as a fire marshall. That includes overseeing A/V tech. Help speakers to connect to video and mic. Make sure they do not run with that. Remind them the time.
This year, I chose a room with Lightning talks. There was 15 minutes for each talk and 5 minutes for a break. And it was a blast!
I chaired the Thursday morning and Friday afternoon. One of the best delivered talks was from new junior who was speaking for the first time - yet she overperformed more senior people.

“AI accelerated learning. Mentorship directed it. Real systems grounded it.” Kaja Prokopova @ “From Sysadmin to Software Engineer: A Non-Traditional Path into Tech”

Petr Kaška spoke about detecting malicious prompts. You can attack your model using https://github.com/Security-FIT/PromptAttacker

Anežka Müller speaks about how she organizes a small one-day, one-track conference, Python Pizza. You can use her recipe for free https://docs.python.pizza/

Simplified dopamine circle with James Freeman with his theory about technology dopamine culture.

Jan Jurca spoke about tests on the filesystem that produce different results if you use the filesystem for some time. You can artificially simulate the usage of filesystem and then run the benchmarks using Filestorm https://github.com/janjurca/Filestorm
See the interesting slides.

I did a small cameo at lightning talk by my student Peter Stefunko in his talk “From SBOM to Dependency Stacks: Making Software Structure Visible“ where he tries to visualize the state of the operating system using famous XKCD comics “Dependency”. You can check his work at github.com/peter-stefunko/rpm2xkcd2347.

I did not attend Thursday’s party as we had an anniversary with my wife and preferred my wife over all of you. 🙂

I met many old faces, former colleagues. And the biggest surprise was the booth of Free Software EU where I found the Czech edition of the book Ada & Zangemann that I helped to translate. I did not know it was already printed - that was because the print was finished that morning. I then called Tomas Stary who took the work from me and who I never met - only to find that he is standing beside me in the queue for ice cream 🙂
Mathias post about the new print https://mastodon.social/@kirschner/116770321504331386
Look into the van with a load of 500 books. Half of the batch. Fresh from print.
Later we discussed with Tomas, his publisher and Lucie from RH additional steps to advertise the book.

Skill issue

Posted by Tomasz Torcz ( Fedora Account System Username

ttorcz ) on 2026-06-20 23:11:36 UTC

Last week I had to extend complicated, unfamiliar Helm chart. While I've discussed approach with my carbon-based coworker, actual editing and extending was done by Claude Code.

Refactors and renamings were tedious, but Claudius did them in no time. During the review we decided to significantly change the way chart is organised. Claude executed the changes perfectly.

If I had to fully understand the working of the chart, it would have taken me a good part of the week. Making the changes – another day or two. Significant rework midway – I'd probably be too demotivated to do it.

With AI assistant, I have finished work in two days. Tested, simplified, cleaned up.

But I have no more skills than I had before. I do not understand this Helm chart much better. I've spotted a thing or two during the review, but in no way I have a fuller comprehension. AI let me borrow expertise without acquiring it.

Next time when I'll have to work on this chart, I will use Claude again. I've got softly locked-in in using AI assistant to work. And I'm not happy with that.

Now, my employer sees this as an acceptable tradeoff. Paid for some tokens, unlocked couple of my pricy senior-level hours to do other stuff. It balances. Subsidising Scam Altman and his ilk is a money well spent from this perspective.

We are at the point where we offload more work to so-called AI. Those are just tools. You know what more primitive tools we had before? Assemblers. Then compilers. No one writes machine code by hand anymore. Maybe someone despairs because of it, but people commonly writing binaries are more likely to be dead by now.

No one treats high level compilers as fad and stuff kids these days do. It's just a tool, expected to work and dissappering into the background.

There's one important difference. We do not have to pay for the compilers, thanks to work of the GNU Project last century (gcc) and Apple more recently (llvm/clang). But at this point we are paying for tokens. I expect that as we cannot fathom working with any codebase without a compiler now, a LLM-driven assistant will be required to tackle bigger projects in near future.

To be free, we need to be able to run assistants at reasonable cost. Free is reasonable. Not paying through the nose for electricity is reasonable. We can hope for good quality chinese models to be available for free. We need a free toolkit revolution again. It was GNU Compiler Collection for the previous generation. Would it be Kimi now?

And we need the proprietary AI bubble to pop and rationality to return.

066/100 of #100DaysToOffload

Fedora signing: draw the rest of the owl

Posted by Jeremy Cline ( Fedora Account System Username

jcline ) on 2026-06-20 19:17:00 UTC

Way back in September I apologized for the gap since my last update. I am, once again, sorry it’s been so long since I posted an update. I recently presented at talk at Flock 2026 - if you prefer consuming updates via video where live demos fail, you can find that on YouTube.

This post is something of a summary of that talk, but the short version is Siguldry has all the features Sigul has, plus some. That means we can start deploying it in the coming weeks.

PKCS#11

In the last post, I noted I had implemented server-side support for PGP signing. That’s gone now, I’m pleased to say, because I came across a much neater approach. I implemented a small PKCS#11 module inventively called siguldry-pkcs11.

I can’t take credit for any of the ideas I’m about to describe, since I stole them from multiple other projects. Our friends over in Flatcar have to sign things as well, and they use a key stored in Azure Key Vault. The way they use it is that they implemented a minimal PKCS#11 module. That was my primary inspiration, but I also recently spent some time building a drop-in replacement for pesign-daemon and the idea of exposing the signing interface over a Unix socket that can be mounted into isolated build environments was another concept I borrowed.

For those who aren’t familiar, PKCS#11 is a standard that is made up of a C interface. To implement it, you create a shared object file with a few well-known C functions used to discover your implementations of the interface. Users load your shared library, call a well-known function to get a table of functions where you provide your implementations for the various features. What’s nice about this is that common libraries like OpenSSL can speak to PKCS#11 modules, so you can make any tool that uses those common cryptography libraries use your implementations.

PKCS#11 is a fairly broad specification that covers not just signing, but also encryption/decryption, digest calculation, random number generation, and key management (creating, modifying, deleting, etc). What I realized while poking around Flatcar’s implementation is that you actually don’t need to implement everything. You can, instead, stub out all the functions you don’t want to implement and have them return the handy “function not supported” error code. The list of functions I opted to not support is extensive.

In fact, all I implemented was the functions to authenticate, list keys, and sign. However, that’s enough to make it possible to use the Siguldry server with tools including (but definitely not limited to): rpmsign, ostree gpg-sign, cosign (if built with PKCS#11 support), gpg2 (with the gnupg-pkcs11-scd service), sq (once it merges its PKCS#11 support), systemd-measure, systemd-sbsign, pesign, and perhaps most humorously, ssh. All these tools know how to speak to PKCS#11 modules so they “just work” with Siguldry. Any new tool people make will also likely just work.

One thing that’s neat about this approach is that we sit between the tool requesting the signature and the signing server. This means we can hash the content client-side and requests to the server are very small: just a hash, the algorithm used for the hash, and the key name. No more sending a 4GiB ISO over the network only to have the server hash it, that all is done before the request starts.

The last thing that’s really cool about this approach is that if Fedora decides it needs a new signing server and spends some big bucks on a fancy hardware security module, it will definitely ship with a PKCS#11 module of its own so we can start using it with our existing tooling, no development required. If Siguldry stops being the right choice for Fedora, it’s really easy to swap it out.

Unix Socket API

The other thing I did was to implement a Siguldry client that binds a Unix socket and proxies requests from the local system to the remote Siguldry server. I did this because you can expose the socket into locked down environments, such as RPM build environments, install the PKCS#11 module into that environment, and sign things. Right now Fedora uses this general approach for SecureBoot, except it’s specific to the pesign utility. While I’d prefer to disconnect the signing event from the building of a package, it’s important to support the current workflows and this was a neat way to do that which is generic across signing tools.

It has another advantage. Since the Unix socket is set up using a systemd socket unit, we can sandbox the client proxy, and also configure it with the necessary credentials to connect to the Siguldry server and unlock signing keys. This lets you, if necessary, allow anyone to sign content without needing to manage secrets themselves. The secrets can be encrypted with systemd-creds and bound to hardware. All we have to do is ensure the keys that are configured that way get a special flag when queried via PKCS#11: the “protected authentication path” flag.

siguldry-fedora-autopen

The primary way Fedora uses its signing server is via an AMQP consumer that automatically signs things. Robosignatory is the current tool used, but it needs some significant changes to work with this new workflow. In particular, we don’t want to sign content serially, but the fedora-messaging Python library commonly used to interact with the AMQP broker doesn’t handle concurrency well. And, since we now call out to the particular tool used to sign content rather than sending it to the server, the consumer is primarily a mapping between message topics and those various tools.

All those reasons led me to re-implement it, and since I’ve got no imagination with names, it’s called siguldry-fedora-autopen. It uses the lapin AMQP client with Tokio to manage hundreds or thousands of RPMs/ISOs/containers/etc signing operations at the same time. This means builds should no longer languish in the signing queue for many hours.

IMA

All this probably (hopefully) sounds great, but as with all things there are a few problems. Well, really just one big problem. Back in the Fedora 37 days, we enabled IMA signing for RPMs. The short version of how that works is that each file inside an RPM gets signed. And, unfortunately, the PKCS#11 interface is synchronous. This means that rpmsign requests a signature when it creates an OpenPGP signature on the RPM header. It then requests a signature for each file, waiting for each signature request to finish before starting the next one. Now, when the RPM only has dozens or a couple hundred files that happens fairly quickly. A signature might only take a couple milliseconds and the request/response latency might be a couple dozen more milliseconds (or a lot less depending on how close the server is from the client).

Of course, not all RPMs only have a few hundred files. Some have many, many thousand. For these, a simple OpenGPG signature takes less than a second (even if the RPM is, say, 10GiB). The IMA signing can take many minutes, depending on how many files it has. I’ve been running a client locally, with a server in a nearby datacenter, and the largest time I saw for a signing operation was around 40 minutes. This is really unfortunate, but it is important to remember that we can now do thousands of signing operations at the same time, so even when these slow builds are signed, other builds can be serviced in a timely manner.

There’s a couple ways we can make this better, but the “easiest” involve a custom signing implementation that avoids using the PKCS#11 path.

What’s Next?

In the next few weeks I’m hopeful we’ll have enough time to sit down and deploy Siguldry to Fedora’s staging environment. I want to really kick the tires and ensure it’s rock solid before we move it to production, but I think it’s reasonable to hope for that in the next couple of months.

While that’s happening, I’m going to add support for ML-DSA signing. That will allow us to produce signatures that are safe in a post-quantum cryptography world. After that, I’ll investigate OpenPGP’s hybrid signature schemes, although given recent developments I wonder if we want to bother with those. I’ll defer to what the professional cryptographers have to say about that.

Sometime in the next few Fedora releases, though, you should expect to see new signature algorithms in use (pending FESCo approval etc etc).

Comments and Feedback

Thoughts, comments, or feedback greatly welcomed on Mastodon

flock 2026 recap

Posted by Kevin Fenzi ( Fedora Account System Username

kevin ) on 2026-06-20 17:22:33 UTC

Another wonderfull flock is in the books. This post is likely to be kind of long, and was written a few days after I got back home, so it's likely I forgot some things or misremembered them somehow. If so, it's not intentional.

TLDR version: Another great flock. Lots of good conversations, lots of good talks, good food, good friends. I'd like to give kudos to all the people who put things on. It's not easy planning a large event like this and at least from my perspective everything went very smoothly.

Day -3 / -2

My journey started a few days before flock on Thursday the 11th. I had actually planned to come in a day early to recover from travel, but it turns out there was a meeting scheduled then, so I got to recover in the meeting instead (more on that in a minute).

Two hour drive to portland airport (PDX) turned into about 2.5 due to traffic, but I had planned buffer so it was fine. This time I was taking icelandair via Keflavík (KEF) instead of my usual jump via Amsterdam. The transfer time was quite low (around an hour), but I read that it was easy to transfer there.

The flight was fine, the transfer was a bit fun: They deplaned us out on a tarmack and we had to take a bus to the terminal. That took a while as they wanted the bus fully loaded. Then, they said the customs area was understaffed today and would take longer than normal. So, I rushed as best I could and ended up at my gate only to hear that the next flight was waiting for crew and hadn't boarded yet. :)

The hotel in prague was the same one as last years flock. Last year I had stayed at a nearby hotel, but this year I just stayed at the conference one. I have to say the rooms were nicer there and it was pretty nice to not have to walk over and back a lot.

I got in friday afternoon and took a short nap, then met up with Tomas and Adam for dinner. We picked a nice sounding place nearby and it was a bunch of nice conversation and food.

Day -1

Saturday I had planned to recover from travel, but instead I went to a face to face meeting we had with a bunch of the Red Hatters that were coming to flock. There wasn't anything secret here, it was mostly just discussing what various groups were working on and how we could all help each other out and get things landed/working.

There was a lot of technical discussion and planning type things along with lots of things that were further discussed at flock.

I was able to chime in on some hardware questions and some cloud resources along with some policy questions.

Saturday evening was the 'sponsors dinner' with a bunch of folks from companies sponsoring flock along with leeds of various parts of the project. Amusingly, it was in the same resturant we were at the previous night! It was all good though. I sat near Jermey Cline, David Duncan and Jef Speleta and we had a bunch of conversations on tons of topics.

Day 1

The first day this year was workshops, the keynote and other regular talks would be the next day. I can understand why you might want to do things this way as it allows you to get people excited and working on something and then leverage that work for their talk in the later days. On the other hand it means that the workshops had a lot of talk/presentation before being able to get to the actual work part of the workshop.

The first slot I ended up in the 'hallway track' (as I would many times in the coming days). Talked to too many people to even list. :)

Next I went to the forgejo workshop. It was fine and there were a few questions, but either everyone had burned out their discussions on it, or the folks with those questions/discussions weren't there as it seemed to go very quietly. I think lots of contributors are getting used to forge.fedoraproject.org now and can imgaine how a migrated src.fedoraproject.org might look.

Lunch was up next. This year the mentor summit was doing a 'lunch and learn' thing each day, and I went each day. I sat at the 'operations' table on Sunday and had a great conversation with several new to fedora folks. We talked about matrix a fair bit and software we all use.

After lunch I went to the Fedora Data & Analytics Workshop with Justin and Michael. I think things were pretty interesting, but we spent a lot of time getting everyone up to speed on the background and only had a short time at the end to work on workshoppy things. Still, very interesting stuff here. We have lots of data, but we dont really analize it very much, and I am hopefull this system will allow us to do so! Right after this workshop I got pulled into a hallway track discussion and didn't get a chance to say Hi to Michael in person. :(

After that was more hallway discussions and then our team had a team dinner. Always great to see people I work with day to day over the internet in person. Some of us then rushed back from dinner for...

The flock 2026 candy swap. This year was even bigger I think that last year. We barely fit in the bar where this was happening. Tons of good stuff, lots of good stories. A few people said to me "Do you do this every year? Wow, this is great! I would have brought something if I knew". After the swap, beers in the bar and I managed to have a nice discussion on Books with MattH and Aoife along with some music discussions with many others.

Day 2

Monday started out with the keynote state of Fedora from Jef. There was even a nice bit of stats out of the data workshop that was interesting.

Then up in the same room was the Council round table, followed by the FESCo one. Interestingly, the Council didn't get any AI related questions, but FESCo did. Do watch those recordings if you are interested in any of those questions/answers.

There was a talk on hummingbird after that, which was great. I'm excited to see hummingbird and to see what it's going to grow into.

Mentor summit lunch and learn monday was the 'infrastructure' table for me. We had folks from Azure linux and Amazon linux (both now based on Fedora) asking a bunch of infrastructure questions. I also asked them a bunch about their infrastructure too. It was very encouraging this year to not only see groups like this at flock, but asking how they can be more involved and help Fedora out and thus help themselves as downstreams. I'm really hopefull we can help each other and all end up better for it. This was probibly the most encouraging thing I saw at flock this year. :)

After lunch I went to Lenkas Forgejo runners on fedora forge talk. This was largely stuff I knew about, but it was great to see all in one place. There were some nice questions. We are definitely seeing some good use from these runners and it's good to see work on them continue.

I had a bunch of hallway conversations after that, then off to...

Post-quantum cryptography for Fedora infrastructure with Alexander and Jakob. The timelines here are really scary to me. There's a lot thats just starting to land now, but the dates for moving things are coming up super fast. I hope it will all work out, but it's a lot of things and a lot of work. :(

Dinner Monday was the flock reception. It was in a nearby outdoor food court, which I had actually had lunch at last year. It was a nice setup, they blocked off a large area of tables for us and gave us vouchers to get a meal at any of the... many food places. They also brought us all a bunch of free appitizers to the point where it almost wasn't worth getting a real meal. :) Had a lot of conversations on a lot of topics here. I managed to find Michael Winters and we started to talk, but then they called the group photo and we were seperated, then after that we both got pulled into other conversations. (This was a theme)

A group of us then went to a belgian beer place and stayed talking until the wee hours.

Day 3

The last day already!

I started with the "RHEL11 and what it means for you" talk. Nice to see dates listed there and an attempt to get fedora things landed in time for RHEL11.

Next up was the state of the fedora kernel from Justin. Nothing too much that I didn't know, but was good to clarify things and hear questions from folks.

In the next slot I really wanted to go to Kashyap's riscv talk, but unfortunately that was when _my_ talk was scheduled also. ;( So, I gave my talk about scrapers. It was a pretty nice crowd, and there were lots of good questions from people. I did have AV problems however, they were unable to capture from the projector for the live stream, so they could only use the camera to capture it. I have no idea why that was happening. Somehow also, I wasn't able to read my notes while giving the talk, so I missed saying a few things I meant to mention. Things like: "robots.txt was orig called RobotsNotWanted.txt", and asking if anyone remembered the /. effect. ;) Overall I think it went well.

After a bit of hallway conversation, next up with the talk about Microsoft contributions to Fedora. It's great for this work to get highlighted. I am very happy with all the work Jeremy has been doing on our signing infrastructure, along with all the other places they contribute.

I then went to the "Upgrading Fedora Infrastructure from Nagios to Zabbix" talk. This was given by Michal, because Greg was unable to attend. He did a fine job going over things, and Greg was in the matrix room for the talk answering questions. I'm super happy about this finally getting over the finish line (at least the initial one) I think we are in a much better place.

Last day of Mentor summit lunch and learn I sat at the Release Engineering table. We had a mix of folks this time. Some Amazon linux folks, someone asking how to get involved that was just starting out, and someone who was involved in server/docs. We had a pretty wide ranging conversation.

After lunch were the lightning talks. There were a bunch of them, and I was amazed at how many folks had slides. I guess they were ready to talk about their thing at a minutes notice. Lots of interesting stuff in there. Worth a video re-watch.

Finally, the last session of the conference: The Fedora’s Contributor Recognition Program. I won this award last year, and was involved a small amount with choosing winners this year. All the proposed candidates were great! Fedora is nothing without it's contibutors and the folks awarded were all super well deserving folks. Make sure you say 'thanks' to those who help you.

With the conference officially over, I was very tired, so I went to take a nap. Michael Winters was down in the bar, and I said I would try and meet up after I got up. So, after my nap I wandered down and... I swear I saw him walking off to dinner with a group of folks. Missed again. (I'm not avoiding you Michael! Honest!)

I ended up at dinner with a small group and we actually talked non computer nerd things ( music, podcasts, and even politics ).

Day 4

The next day was the travel home. Due to timezones I would leave the Prague airport at 2pm and get into portland at like 5:30pm. (it is NOT 3.5 hours of flights).

I again had fun with the transfer in iceland. Our plane from Pague was a few minutes late, then we needed to take the bus to the terminal, then passport control was even more backed up than it was last time. I finally got to my gate and their was an attendet there who asked me my name. I then took a bus with only 3 other people on it to the plane. They held it for us, but I made it.

The rest of the trip back was uneventfull, but will take a while to recover. Luckily, there's a holiday this friday so I do have a 3 day weekend.

A few Downsides

Overall I think things went super nicely and smoothly, but:

The weird AV issues for my talk. It's likely something off about my aarch64 laptop. So, perhaps I should take a boring x86_64 one next time. Or spend some time poking at it before time for my talk.
There were a lot of folks that I usually look forward to talking with in person that were not able to make it this time. Due to various reasons, but it was sad to not see them. You all know who you are, you were missed.

Hallway conversations

There were a ton of hallway conversations, and I am sure I don't remember most of them but the few I do:

Alexander showed me a new rust based IDP setup he has been working on. Super cool looking and very on point for Fedora.
There was a number of AI conversations, but more of the 'what do you think is going to happen when the bubble bursts' than anything else. There was a foundations whiteboard where people could add things around the 4 foundations and under friends was "more people, less AI".
Lots of good talks with Amazon Linux and Azure Linux folks. I hope to see them chime in on matrix with questions/comments/contributions.
Jeremy and I had a number of talks about the new signing stuff.
Nice to see Toshio again and talk with him on lots of things.
Had some good talks about 2fa and otp and such with Gotmax23.
A conversation I had a number of times was "where should we do flock next year?". There were a lot of ideas, no telling what will win out. We might not do too badly to just do it in Prague again, IMHO.

As always, comment on the fediverse: https://fosstodon.org/@nirik/116784039502240226

Valor de uma Vaga de Emprego

Posted by Avi Alkalay ( Fedora Account System Username

aviram ) on 2026-06-20 11:25:48 UTC

RH/entrevistador: “Qual sua pretensão salarial?”
Candidato/entrevistado: “Qual é o seu orçamento/valor aprovado/budget para a vaga?”

É assim que a entrevista deve transcorrer, a partir do número da empresa. Se há uma vaga, há um orçamento aprovado para ela.

Se o candidato fala sua pretensão às cegas, sempre sai perdendo. Se a pretensão for baixa, é só isso que vai receber. Se for muito alta, será eliminado, muitas vezes sem nem saber o motivo.

É o candidato que deve optar por continuar ou não o processo após ouvir o valor aprovado da empresa para a vaga.

O candidato controlar o valor do salário na entrevista pode lhe garantir uns bons 20% a mais de valor inicial. Se o entrevistador controlar, será os mesmos 20%, só que para menos.

É claro que nem todo candidato:

tem condições de abrir mão de qualquer vaga que apareça, e isso é reflexo muito ruim do mercado de trabalho
tem estômago para negociar deste jeito, e isso é coisa que as pessoas devem tentar treinar para evitar a possível manipulação por trás da pergunta “qual sua pretensão”

Um “caçador de cabeças” (head hunter) entra na primeira entrevista de um candidato com exatos 2 objetivos: 1️⃣ checar se há bom casamento financeiro entre o candidato e o valor aprovado para a vaga e 2️⃣ captar se o candidato, de uma forma geral e difusa, tem a ver com a empresa e a função da vaga. Este último pode ser previamente sondado pelo perfil publicado da pessoa e será aprofundado mais adiante no processo. Então comprovar compatibilidade financeira é o objetivo mais importante da primeira entrevista. E, por incrível que pareça, isso pode ser resolvido nos primeiros 6 minutos de entrevista, ou no chat antes de qualquer encontro.

Pense: por que o candidato tem que ter um número e revelar, mas o recrutador não? Se há uma vaga, há um orçamento aprovado para ela. E é o candidato que deve decidir se aquilo atende suas expectativas. Não o contrário.

Reescrito a partir de comentários que deixei numa publicação do Márcio Gonçalves no LinkedIn.

🎲 PHP version 8.4.23RC1 and 8.5.8RC1

Posted by Remi Collet ( Fedora Account System Username

remi ) on 2026-06-19 03:59:00 UTC

Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.

RPMs of PHP version 8.5.8RC1 are available

as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
as SCL in remi-test repository

RPMs of PHP version 8.4.23RC1 are available

as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
as SCL in remi-test repository

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

dnf module switch-to php:remi-8.5
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.4:

dnf module switch-to php:remi-8.4
dnf --enablerepo=remi-modular-test update php\*

ℹ️ Notice:

version 8.5.8RC1 is in Fedora rawhide for QA
EL-10 packages are built using RHEL-10.2 and EPEL-10.2
EL-9 packages are built using RHEL-9.8 and EPEL-9
EL-8 packages are built using RHEL-8.10 and EPEL-8
oci8 extension uses the RPM of the Oracle Instant Client version 23.26 on x86_64 and aarch64
intl extension uses libicu 74.2
RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
versions 8.4.19 and 8.5.4 are planed for March 12th, in 2 weeks.

Software Collections (php84, php85)

Base packages (php)

How I'm Solving Local Inference

Posted by Chris Short ( Fedora Account System Username

oaf357 ) on 2026-06-19 04:00:00 UTC

How I bridged my MacBook Air and Framework 13 using LM Studio's LM Link to run powerful local models, avoid token costs, and gain portability.

Friday Links 26-20

Posted by Christof Damian ( Fedora Account System Username

cdamian ) on 2026-06-18 22:00:00 UTC

A single yellow dimpled mini-golf ball resting on a worn concrete putting lane, with a blue ramp obstacle blurred in the background in front of a green hedge

This week was weird. Something happened to my RSS reader. Anyway … still some good stuff — the interview with Kelsey Hightower, and the piece on how Meta is messing up its culture.

Quote of the Week

Remember, Peter Drucker said that if people spend more than 25 percent of their time in meetings, it is a sign of malorganization. I would put it another way: the real sign of malorganization is when people spend more than 25 percent of their time in ad hoc mission-oriented meetings.

High Output Management

Andrew S. Grove

Leadership

Why is Meta destroying its engineering organization? - sign of maturity :-)

New badge: DevConf.cz 2026 Attendee !

Posted by Fedora Badges ( Fedora Account System Username

admin ) on 2026-06-18 11:59:07 UTC

You attended the 2026 iteration of DevConf.cz, a yearly open source conference in Czechia!

From June 08 to June 14

Posted by Aurélien Bompard ( Fedora Account System Username

abompard ) on 2026-06-18 08:37:00 UTC

Across the project, the dominant focus was on preparing for the upcoming Fedora 45 release. This involved FESCo debating significant Change Proposals like a system-wide libxml2 update and a new GRUB package for Confidential Computing, while the Quality and ELN teams were busy testing and integrating major updates like Python 3.15 and preparing for OpenSSL 4. A key strategic initiative discussed by the Council and Atomic groups is the plan to use Konflux to build and ship bootc base images for the F45 cycle. Another common theme was the upcoming Flock conference, which impacted meeting attendance and served as a central point for planning, presentations, and resolving blockers. Concurrently, several groups were managing infrastructure changes, including the completed migration from Nagios to Zabbix and the ongoing move of repositories from Pagure to Fedora Forge.

Announcements

The F44 election cycle has concluded, with results announced for the Fedora Council, FESCo, Mindshare, and EPEL Steering Committee. This followed a final reminder to vote earlier in the week. In the lead-up to Flock 2026, the "#Commit History" campaign continued to highlight contributor stories, featuring interviews with speakers Jaroslav Reznik, Jona Azizaj, Justin Wheeler, and Peter Boy. The campaign also encouraged community members to share their own first commit stories, and an election-period interview with Council candidate Tomáš Hrčka was also published.

On the technical front, two change proposals for Fedora 45 were announced: a system-wide update to libxml2 that will require a mass rebuild, and the creation of a minimal GRUB EFI package for Confidential Computing. An important announcement explained the upcoming Microsoft Secure Boot certificate expiration, assuring users that Fedora is prepared and there is no need to panic. For testers and developers, non-official Fedora 44 RISC-V images are now available, and a new guide details how to onboard a Forgejo-hosted project to Fedora Konflux for CI/CD.

Council

This week, the Council's activity centered on the "Atomic This Week - 2026-06-09" update, which summarized the progress of the Atomic Initiative (formerly the bootc initiative). Key discussions focused on the plan to use Konflux for building and shipping the Fedora bootc base image, targeting the Fedora 45 release. The main blocker identified is securing approval from Fedora releng for a managed namespace, a topic to be discussed in person at Flock. The group also addressed the need for a clearer governance structure and contribution ladder to improve contributor access to Konflux. For the initiative's long-term future, the consensus is to create a new, permanent "Atomic SIG" dedicated to bootc base images, rather than merging with the Atomic Desktops SIG. Interested contributors are invited to join the #bootc:fedoraproject.org Matrix channel to participate.

Learn more about the Council team.

FESCo

Several new Change Proposals for Fedora 45 were introduced and discussed this week. A proposal to update libxml2 to version 2.15.3 was submitted, which is notable as it includes an ABI change requiring a system-wide mass rebuild and deprecates the python3-libxml2 subpackage. Maintainers of packages using the old Python bindings are encouraged to migrate to alternatives. Another new proposal aims to create a minimal GRUP EFI package specifically for Confidential Computing environments to boot Unified Kernel Images (UKIs). This proposal generated significant debate, with many contributors questioning the decision to create a new GRUB variant instead of using the existing systemd-boot, and challenging the rationale provided for its rejection.

In other news, the long-running Protobuf 5.x/6.x update was reported as complete and is now available in Rawhide. For those interested in testing upcoming changes, the NodeJS metapackage change is now available in a COPR for preliminary testing. Finally, the proposals for Erlang 27 and RPM 6.1 were formally submitted to FESCo for voting.

Learn more about the FESCo team.

Packaging Committee

During their weekly meeting, the Packaging Committee approved a change to make the Web bundling guidelines consistent with a prior FESCo decision (PR#1539), although they plan to revisit that underlying decision in a separate ticket. A significant open-floor discussion revolved around the process for packaging new cryptographic libraries, where a packager has been unable to get a required public response from the crypto team for over a year. The current plan is to escalate this to FESCo after the Flock conference if it remains unresolved. The committee also debated a proposal for using file triggers to generate shell completions but postponed a decision due to concerns about its compatibility with immutable systems (like rpm-ostree) and containers.

Learn more about the Packaging Committee team.

Mindshare

In the final Mindshare meeting of the current term, the committee focused on transitioning responsibilities and a major new proposal. Discussions covered the off-boarding process for the appointed representatives from CommOps and Marketing, highlighting an opportunity for new contributors to step into these roles. The primary topic was an experimental initiative proposed by the Fedora Council to use Open Collective for community fundraising to support event travel, starting with BalCCon. This aims to create a more agile reimbursement process outside of Red Hat's corporate systems. The committee showed broad support for the experiment, emphasizing the need for careful messaging to avoid misperceptions about Red Hat's funding commitment.

A significant forum discussion this week centered on a contributor's frustration with a non-responsive package maintainer, which sparked a broader conversation about the contributor experience. The thread highlighted the challenges volunteers face and the negative impact that a lack of feedback can have on contributor retention, a key area of concern for the Mindshare committee.

Learn more about the Mindshare team.

Workstation / GNOME

The Workstation Working Group held its bi-weekly meeting, covering several topics. Discussions included a proposal to drop Libcanberra and move sound handling into GNOME Shell, the use of AI for static analysis and duplicate bug detection, and the potential replacement of the Seahorse password manager with a more modern application like Key Rack. On the forums, a call was made for Fedora GNOME users to test a new open-source AI usage tracker called OpenUsage Community, providing an opportunity for community involvement. The ongoing conversation about a potential Fedora edition for NVIDIA's RTX Spark AI hardware also continued.

Decisions

The Workstation WG meeting scheduled for June 16, 2026, is cancelled due to the Flock conference.
Several topics from the June 9th meeting were deferred for two weeks, including discussions on status notifiers, replacing the Seahorse password manager, and integrating AI for accessibility features.

Learn more about the Workstation / GNOME team.

KDE

This week, the KDE SIG prepared for the final release of Plasma 6.7.0. The COPR repository for the Plasma 6.7 beta was decommissioned as the testing phase concluded ahead of the official release. This marks a key milestone for users and testers looking forward to the new stable version.

A discussion was also started regarding a user experience issue in KDE Discover, where the interface provides no progress indication during immediate updates, unlike the behavior for offline updates. The user was advised to report this feedback upstream to the KDE community, presenting an opportunity for contributors to engage with developers to improve the software.

Learn more about the KDE team.

Infrastructure

This week, the Infrastructure team announced two major milestones. First, the long-running migration from Nagios to Zabbix for monitoring is now complete, and Nagios has been shut down. The focus now shifts to refining the new Zabbix checks, reducing alert noise, and onboarding other teams to consume their own monitoring data. You can read the full announcement here. Second, Akashdeep Dhar and Lenka Segura were welcomed into the sysadmin-main group, granting them root access in recognition of their extensive contributions. The announcement and congratulations can be found on the discussion forum and the mailing list.

With several team members traveling for the Flock conference, availability may be reduced. During the week's meetings, the team triaged tickets related to dead mirror links and crypto spam, and discussed ongoing work to protect repositories against malicious pull requests. The monthly AWS usage report prompted a discussion about cleaning up unused QA instances to reduce costs. A new contributor was welcomed during the weekly meeting, and opportunities for community involvement include helping with open tickets and collaborating on the new Zabbix monitoring system.

Decisions

The Nagios monitoring system has been officially decommissioned and replaced by Zabbix. Nagios services on noc01 and noc02 were stopped.
Akashdeep Dhar and Lenka Segura were added to the sysadmin-main group, which has root access to the infrastructure.
A patch to fix a FedoraMessaging issue on the wiki (#13395) was merged.
The team will investigate and potentially delete unused QA instances in AWS to reduce costs.

Learn more about the Infrastructure team.

Quality

The Quality team's weekly meeting focused on the status of Fedora 45, particularly the recent landing of two major Changes: kmscon consoles and Python 3.15. These have introduced some known issues, such as broken kickstart installs and console problems on IoT and CoreOS, which require attention from testers. A call was made for a volunteer to organize Test Days for the F45 cycle, and the next kernel test week is expected in about three weeks. On the mailing list, a plan was proposed to simplify CI infrastructure by discontinuing legacy .ci. messages.

On the forums, a new version of the community-driven DNF UI tool was released, now using the official dnf5daemon for transactions. A significant discussion was sparked by a contributor asking "Is it worth contributing to the Fedora Project?" due to an unresponsive maintainer. This led to a broader conversation about the challenges of a volunteer-driven project and the processes for handling such issues. The team also welcomed a new potential contributor, Ephraim Kaov, who requested to join the QA group.

Decisions

An action item was created for a volunteer to send out the F45 call for test days.

Learn more about the Quality team.

Design

The Design team's meeting this week was centered on preparations for the upcoming Flock conference. The team discussed progress on the presentation slideshow, beta wallpaper, and livestream splash screen. They also reviewed high-quality promotional videos from a new contributor, ProducerRob. Other key topics included the design for the Flock party badge, where they considered reusing existing assets, and a discussion on the Datagrepper icon, weighing the use of pre-made SVGs against custom designs to ensure recognizability at small sizes.

Decisions

The general attendee badge for Flock will be awarded automatically through a web hook connected to the Pretix ticketing system, so a QR code poster for claiming it is no longer needed. The party badge will likely still require a manual claim process.
A new ticket regarding labels will be postponed until the next ticket refinement meeting.
Madeline Peck will host a meeting next week for team members who are not attending the Flock conference.

Learn more about the Design team.

Internationalization

The Internationalization team held its weekly meeting to discuss upcoming Fedora 45 changes. The team is considering postponing the variable fonts change for fonts-rpm-macros and is planning a new change to package upstream LibreOffice dictionaries as alternatives to the current Fedora hunspell dictionaries. On the mailing list, there was a call for Kurdish speakers to help correctly identify and tag existing translations that use the generic "ku" language code. The team also welcomed back a returning contributor, Javier Blanco, who will be assisting with Spanish translations.

Learn more about the Internationalization team.

COPR

This week, the COPR team published the release notes for the copr-backend server update that was performed during a planned outage on June 2nd. The announcement provides details and context for users and contributors about the changes implemented.

Learn more about the COPR team.

EPEL

During the weekly EPEL meeting, the main topic was repository lifecycle management. The steering committee discussed the timing of minor version retirement and decided to maintain the current policy, closing the related issue. The practical effects of this policy were highlighted in a mailing list thread concerning the recent retirement of EPEL 10.1, where users were reminded that EOL content is available from the archive mirrors. For packagers, a forum discussion clarified that requests for new branches should still be filed against pagure.io instead of the new Fedora Forge instance.

In other news, a final notice was sent to the epel-announce and epel-devel mailing lists regarding the impending retirement of python-django3 from EPEL 8 and 9. The package is end-of-life and has unpatched security vulnerabilities, and since no one has volunteered to maintain it, it and its dependents will likely be retired. The committee also agreed to find a new time for its weekly meetings to improve attendance.

Decisions

The issue regarding EPEL minor version retirement timing was closed. The current policy will remain unchanged.
The EPEL Steering Committee will find a new time for its weekly meeting. A poll will be sent to committee members to determine the best time.

Learn more about the EPEL team.

ELN

This week's ELN meeting covered several major upcoming changes and ongoing work. The Python 3.15 update has largely landed in ELN, a significant milestone as this is the version RHEL 11 will branch with. Preparations are also underway for the migration to OpenSSL 4, which is planned for next week in Rawhide and will subsequently land in ELN. Most of the ELN package set has been tested against the new version, and a compatibility package for OpenSSL 3 will be provided to ease the transition. Other discussions included resolving a packaging dependency issue for bootc images, following up on the Hyperscale kernel configuration problem with a new contact in the Red Hat kernel team, and the upcoming migration of the ELNBuildSync service to Fedora Infrastructure hosting.

Decisions

The meeting scheduled for 2026-06-16 will be skipped due to the Flock conference. The next meeting will be held on 2026-06-23.

Learn more about the ELN team.

Atomic

The Atomic group's weekly meeting focused on the proposal to use Konflux for building and shipping the bootc base image, with the goal of having this in production for the Fedora 45 release. The main challenge identified is convincing Fedora Release Engineering to support the required managed namespace for signing and pushing artifacts. This topic will be a key discussion point at the upcoming Flock conference, where a presentation is being prepared. The group also discussed improving contributor access to Konflux and the long-term governance of the initiative's work, which will likely involve creating a new SIG to maintain the base images after the initiative concludes post-F45.

In the forums, user support discussions continued. One thread saw a user ask for updates on a Konsole TTY error on F44, suspecting an issue with Flatpak integration. Another conversation clarified why a locally installed RPM for Proton VPN on Silverblue is not updated via the Software Center and must be managed manually with rpm-ostree.

Decisions

During the Atomic meeting, the group formally agreed on the following points regarding the move to Konflux:

The group confirmed its consensus that using Konflux is the desired direction for building the bootc base image.
The primary blocker is convincing Fedora Release Engineering of the need for a managed namespace and artifact signing.
A change proposal for this move needs to be drafted in parallel with these discussions.

Learn more about the Atomic team.

CoreOS

In this week's CoreOS meeting, the team reviewed the Fedora 45 release schedule and confirmed that no immediate actions are required. The open floor session included a technical discussion about the boot-time flow of base.platform.d entries and the ignition-fetch.service, prompted by an Afterburn pull request. Another key topic was the status of a proposal to integrate Butane functionality directly into Ignition, as tracked in issue #2006, with the goal of targeting it for the Fedora 45 release. The team also noted which members will be attending the upcoming Flock conference.

Decisions

spresti will investigate the operational ordering related to the Afterburn pull request.
spresti will update issue #2006 with previous feedback and follow up with dustymabe regarding the proposal to integrate Butane into Ignition for Fedora 45.

Learn more about the CoreOS team.

IoT

During the weekly IoT meeting, the main topics were the upcoming migration from Pagure to Fedora Forge and the status of release testing. The team is preparing for the repository migration, which is considered urgent as Pagure's decommissioning is imminent. Regarding release engineering, a refresh of the Fedora 44 images is planned but is currently blocked waiting for an update to image-builder. A critical issue was discussed for Fedora 45 (Rawhide), where all OpenQA tests are failing across all architectures. This bug is a key focus for the team, and contributors are encouraged to help investigate the problem.

Learn more about the IoT team.

Alternative Images

In the weekly Alternative Images meeting, discussion focused on RISC-V progress and the migration from Pagure.io to GitLab. The final recompile of CentOS Stream 10 for RISC-V is nearly complete after resolving a %dist tag conflict by changing it to .el10rv. The team hopes to begin building the RISC-V images next week, aided by configurations provided by the RHEL team. This progress is significant for the broader community interested in RISC-V on CentOS.

The migration of key repositories to GitLab is complete as Pagure.io is being decommissioned. While internal documentation has been updated, there is an opportunity for contributors to help by updating the public docs.centos.org website to reflect these changes, as tracked in this work item. This ensures that contributors are not disrupted by the platform change and can easily find the new repository locations.

Decisions

The following repositories were migrated from Pagure.io to GitLab, with the rest being archived: kiwi-descriptions, sig, spin-bugs, and anaconda-liveinst.

Learn more about the Alternative Images team.

Cloud

The Cloud SIG held its weekly meeting and discussed the recent successful migration of the cloud-sig to forge.fp.o. Thanks were given to the contributors who made this transition possible. The primary focus of the meeting was planning for the upcoming Flock conference.

A significant portion of the discussion was dedicated to organizing a Cloud-SIG meetup at Flock. This provides a key opportunity for contributors to connect in person. The group brainstormed several important topics for this meetup, including a strategy for handling image customizations, creating a formal release checklist, developing a 3-year strategic plan, and exploring the creation of a dedicated AI/ML cloud image.

Decisions

A Cloud-SIG meetup will be held at the Flock conference. The time is still to be determined, but the location will be Room 1003.

Learn more about the Cloud team.

AI & ML

This week, the AI & ML group's activity focused on the ongoing effort to figure out NPU support in Fedora for the F43 release. A significant step forward was shared by Alessandro Lattao, who posted a link to a working COPR for FastFlowLM. This project enables running Large Language Models (LLMs) on AMD Ryzen AI NPUs. This provides a concrete opportunity for contributors to get involved by testing the new packages and helping to advance NPU enablement within the distribution.

Learn more about the AI & ML team.

RISC-V

This week, the RISC-V group announced the availability of non-official Fedora 44 images for community testing. These images feature a new "Omni" kernel variant intended to support a broader range of hardware. During the weekly meeting, the team noted that while the package delta for F44 is minimal, some boot issues have been reported. Work has now begun on Fedora 45, with the immediate priority being the integration of Python 3.15. Hardware updates included the addition of a Spacemit K3 board to the Koji build system. A decision was also made to establish a new SCM structure for RISC-V specific packages.

Decisions

A new namespace for RISC-V specific package forks will be created on forge.fedoraproject.org. The repository structure will be /riscv/packagename (e.g., /riscv/gcc), forking from the main /rpms/ repositories.

Learn more about the RISC-V team.

Security

The Security SIG held a brief meeting this week, with low attendance as many contributors were traveling to the Flock conference. The group reviewed the open tickets in the main Security Forge and the Security Docs Forge, and contributors are encouraged to vote on ticket #8. A discussion arose about the meeting's weekly frequency, with suggestions to either move to a bi-weekly schedule or cancel meetings when there are no topics. This will be discussed further in a future meeting when more members are present.

Learn more about the Security team.

Go

A discussion was initiated on the mailing list regarding a packaging issue where the %{gosource} macro failed for the checkmake package. The macro generated a URL for the source tarball that resulted in a 404 error. The packager found a manual workaround by constructing the URL differently and questioned whether the problem stemmed from the upstream project's release process deviating from the norm. This thread presents an opportunity for Go packaging experts to clarify the expected behavior of the macro and best practices for handling such upstream inconsistencies.

Learn more about the Go team.

Perl

This week's activity for the Perl group focused heavily on package maintenance, including version updates and proactive compatibility fixes. Several packages were updated to be compatible with upcoming releases, such as perl-BDB for Perl 5.43.2+, perl-re-engine-RE2 for Perl 5.43.11, and perl-Net-SSLeay for OpenSSL 4.0. Additionally, several modules received version bumps, including perl-HTTP-Daemon, perl-HTTP-Message, and perl-Locale-Codes.

A key ongoing discussion revolves around the large number of orphaned Perl packages resulting from a maintainer's inactivity. A list of packages still needing adoption was circulated, presenting a significant opportunity for contributors to take ownership and help maintain the Perl ecosystem within Fedora.

Decisions

The perl-BDB package was patched to rename a function, avoiding a name collision with the upcoming Perl 5.43.2+.
The perl-re-engine-RE2 package was adapted to work with Perl 5.43.11.
A fix was applied to perl-Net-SSLeay to ensure it builds with OpenSSL 4.0.
The perl-WWW-RobotRules package was updated to fix its build and a dependency on DB_File.
perl-HTTP-Daemon was updated to version 6.17, perl-HTTP-Message was updated to version 7.02, and perl-Locale-Codes was updated to version 3.90.

Learn more about the Perl team.

Other Discussions

Aoife Moloney announced the results of the F44 Elections Cycle for the Fedora Council, Fedora Mindshare Committee, FESCo, and EPEL.
In a discussion about the Fedora Mentor Summit at Flock 2026, Jona Azizaj announced the planned activities. These include daily "Lunch & Learn" sessions for informal networking, a sticker matching icebreaker to connect attendees, and a session to highlight the Fedora Contributor Recognition Program and its winners.
A new topic was created to discuss including upstream branch information in Fedora packages. The main use case is to help developers easily find the correct branch for submitting bug reports and fixes. The conversation weighed the benefits of a dedicated field for this information against concerns that a branch name is mutable and less reliable than a commit hash.
Yann Collette provided an extensive update on the Audinux repository for May 2026, detailing the addition of 32 new packages and 88 package updates for audio production software. In response to the detailed post, it was suggested that a Fedora Magazine article would be a great way to increase visibility, an idea which was well-received.
In the "If you're on the kernel mailing list (LKML), aren't you concerned about AI?" discussion, the conversation continued about plagiarism and AI-generated code. Participants suggested using plagiarism detection tools similar to those in academic publishing. Frustration was also expressed regarding the high volume of automated commits on the LKML, which makes it difficult to follow human discussions.
The discussion on how to include upstream URLs in Fedora packages continued, with a note that a previous proposal for a RepoURL tag in RPM was rejected in favor of using the existing VCS tag. An example was shared from the Hummingbird project, where for packages without a traditional upstream, the VCS field points to the package's location in Fedora's infrastructure.
Adam Williamson proposed a plan to stop sending .ci. messages on the Fedora message bus. This change aims to simplify the CI infrastructure, as the system is considered legacy and its few consumers can be adapted to use other message sources like resultsdb directly.
Gordon Messmer is seeking a reviewer for a new security analysis tool in Fedora CI. The proposed generic test uses "got-audit" to attach to running systemd services and check for unusual symbol resolutions, which could help detect issues like the XZ backdoor.
Zbigniew Jędrzejewski-Szmek announced a change in Rawhide's systemd package regarding the autogeneration of library dependencies. The new method improves handling of soft dependencies for libraries loaded with dlopen(), allowing binaries to adapt their functionality based on which libraries are installed.
Fabio Valentini announced that he is beginning to implement the Changes/Versioned_libgit2_packages proposal. The first step involves retiring the unused libgit2_1.8 package in Rawhide, with further changes and rebuilds planned for after Flock.
Other discussions this week included a heads-up about fixes for dracut DHCP issues, a conversation about the civetweb package being retired in Rawhide, a clarification that repository composes use efficient hardlinks instead of copying RPMs, a new F45 Change Proposal to update libxml2, a discussion on a UTF-8 parsing issue in Java manifests, testing and feedback for the new Node.js Metapackages, continued discussion on the F45 Change Proposal for RPM 6.1, a query about using sidetags in Pull Requests, and a note on a similar security incident in Arch Linux in the context of the compromised Fedora account.

New Contributor Introductions

Kevin Thomas (kevtt) introduced himself as a newcomer looking to get involved with the Join SIG, testing, and documentation to learn more about Linux and the community.
Henry (henrymmey), a teenager from Germany, introduced himself with an interest in infrastructure, systems management, and Linux development, and is seeking guidance on where to contribute.

Package Updates

Benson Muite announced an upcoming update for ThorVg in F44 and F43 to address a CVE.
Frantisek Zatloukal confirmed that the mass rebuild for the icu 78.3 update is now complete.
Sandro Mani announced plans to update gdal to version 3.13.1, which includes a soname bump, but was asked to hold off until the ongoing OpenSSL 4.0 rebuild is finished.
In the thread about the fmt library soversion bump, Frantisek Zatloukal offered to handle the required mass rebuilds for both fmt and the dependent spdlog package in about two weeks.

Orphaning packages

Jerry James orphaned spec-version-maven-plugin and jakarta-json as they are no longer required by antlr4-project. He noted that spec-version-maven-plugin is still a dependency for other packages and will need a new maintainer.
Adam Williamson briefly orphaned xterm-console before quickly re-adopting it after realizing it was still needed.
Viktor Erdelyi provided an updated build for the orphaned package wavemon. After encouragement to become the maintainer, Iñaki Ucar stepped in to formally adopt the package and start the un-retirement process, as Viktor was not yet a packager.

Ten + 1 Reasons to Avoid the Immutable Desktop

Posted by Rénich Bon Ćirić ( Fedora Account System Username

renich ) on 2026-06-18 07:00:00 UTC

Lately, it seems the industry is aggressively pushing immutable, image-based operating systems for the desktop. Shipping a cryptographically sealed, read-only root filesystem sounds super fancy and elegant on paper, but in reality, it's a solution looking for a problem, unless you're running a smart fridge or a corporate kiosk.

Let me be perfectly clear: immutable systems are the correct choice for single-purpose appliances, point-of-sale terminals, and sealed server nodes. If your hardware only needs to run a fixed set of remote directives without any user intervention, then yes, a mutable root filesystem is just begging for trouble.

But trying to force this architecture onto a general-purpose desktop? That is a spectacular regression. It wraps the user in a straitjacket, offloads system complexity onto you, and strips away ownership, performance, and actual security in the process.

Here is the engineering reality of why the immutable desktop fails the general user.

The Decentralized Trust Fallacy

In a traditional mutable distribution (like Fedora or Debian), the supply chain is centralized. A dedicated, paranoid security team audits and patches the core repositories. Immutable desktops, however, force you to rely on containerized app stores (Flatpak or Snap). This shifts your trust from a central team to thousands of random, unvetted package maintainers. If a developer gets tired of maintaining a popular app and a malicious actor takes over the namespace, they can silently push a credential stealer directly to your machine. It gets delivered instantly via background updates, completely bypassing distribution-level QA.

Furthermore, standardizing the exact same OS image across millions of installations creates a beautiful, uniform monoculture. If a zero-day is found in that specific image, every single user on Earth gets compromised by the exact same payload. Congratulations! On a mutable system, your messy "state drift" (different library versions, weird compiler flags, custom packages) acts as a natural defense system, frequently causing exploit payloads to crash and burn. Diversity is security, compa! ;)

Weaponized Negligence (Zombie Dependencies)

A security disaster doesn't require active malice; simple developer laziness works just as well. If a developer using Flatpak to distribute an app bundles an outdated version of libwebp or openssl in their container and forgets about it, that vulnerability is now permanently camped out on your system. Because your host OS is read-only, your central package manager is completely powerless to patch it.

While common base libraries might get updated in shared runtimes, modern desktop software is dominated by Electron, Node, Python, and Rust. These apps bundle their own massive piles of NPM packages, Cargo crates, and entire copies of Chromium inside their container. When a critical vulnerability drops in one of these nested dependencies, your shared runtime does absolutely nothing to save you. You are completely at the mercy of the upstream developer rebuilding their app. Until they do, you are left running a collection of isolated zero-day vulnerabilities while basking in a false sense of security. Sweet dreams!

The Sandbox Illusion

Advocates love to claim containerized apps protect you via sandboxing. This is, plain and simple, an architectural lie. To make complex applications actually work, maintainers routinely ship containers with massive filesystem overrides (like --filesystem=home). The moment a compromised application updates, it has immediate access to your SSH keys, browser session cookies, and cloud tokens. Securing /usr/bin while leaving /home wide open to unvetted third-party containers is a spectacular failure in threat modeling.

Besides, malware doesn't even need write access to /usr to stick around. It can easily drop a systemd user service (systemd --user) or a simple autostart entry in your home directory. Bam! Permanent persistence achieved without ever needing to touch root. The read-only system partition didn't even notice.

Note

Sure, you can install Flatseal to manually restrict these overrides. But honestly: who has the time to audit permissions for dozens of apps every time they update? Nobody.

Memory Exhaustion on Modest Hardware

Immutability decouples applications from the base system, which completely kills the memory-saving benefits of dynamic linking (shared libraries). Forcing a machine with 4GB or 8GB of RAM to load multiple massive runtimes (like GNOME 45, GNOME 46, and the Freedesktop SDK) into memory simultaneously is a crime against efficiency. The immutable model assumes your RAM and storage are infinite, actively punishing users who aren't running high-end rigs.

The Bandwidth and Storage Tax

Atomic updates sound cool until you realize they require downloading massive OS image deltas alongside gigabytes of duplicated container runtimes. If you are on a metered internet connection, an unstable power grid, or a mechanical hard drive, a simple security patch turns into a multi-gigabyte download and a system-crippling I/O bottleneck. This architecture was clearly designed by developers with gigabit fiber, completely ignoring real-world infrastructure.

The Hardware Enablement Nightmare

When you hit a hardware edge case, like needing a proprietary Wi-Fi driver, compiling a custom DKMS module, or setting up a legacy printer, a mutable root lets you fix it in five minutes. An immutable system tells you to get lost. The root is read-only! Trying to layer kernel modules with tools like rpm-ostree adds massive fragility to the boot process and frequently leaves you rebooting into a broken state.

Warning

STAY AWAY! If your hardware needs out-of-tree drivers, immutable desktops can cause silent failures during kernel updates. Always verify your hardware compatibility unless you like playing Russian roulette with your boot loader.

The Destruction of POSIX Debugging Workflows

If you're a developer or sysadmin, get ready for a headache. Running a containerized user space on an immutable host completely breaks standard POSIX troubleshooting. Classic CLI tools like strace, perf, or gdb fail to work cleanly when processes are wrapped in read-only ostree layers and container namespaces. You are forced to jump through hoops; entering specific debug shells or bypassing namespaces, just to do basic system profiling. Talk about unnecessary friction!

The False Premise of Fragility

The loudest argument for desktop immutability is that traditional package managers break during updates, especially if your power cuts out. But in reality, this is a tiny edge case. Modern mutable package managers handle transactions with incredible reliability. Over-engineering your entire operating system just because someone might forget to plug in their laptop battery is solving a non-existent problem while ruining usability for everyone else.

More importantly, you do not need a read-only root to get atomic updates and boot rollbacks. Distributions like openSUSE (with Btrfs and Snapper) and SerpentOS prove that you can have a fully writable, standard mutable filesystem while enjoying transactional upgrades and snapshot recovery. Immutability is a massive, unnecessary straitjacket that over-engineers a problem already solved by smart snapshotting.

The Container Vulnerability Matrix

Don't forget that sandboxing frameworks add their own complex code—and therefore, their own security bugs. When the container manager itself gets hit with a CVE (like sandbox escapes allowing arbitrary code execution), your supposedly "secure" environment is instantly compromised. Adding endless layers of abstraction doesn't magically eliminate bugs; it just moves them to a place that's much harder to debug and, guess what? There are potentially millions of systems with your exact same configuration now. The attacker's wet dream!

Loss of Technological Sovereignty

An operating system should empower you to own your hardware, not treat you like a guest. Immutability demotes the system administrator to a mere consumer of upstream images, stripping away granular, read-write control of the filesystem. For any engineer or developer, this feels like a straightjacket, fundamentally contradicting the core ethos of Free Software and technological sovereignty.

Oh, but my favorite is, by far, "Now ma Grand ma' cannot destroy the installation"... I mean, who gives root to their grandma? Sheesh!

Unnecessary Indirection

Sure, some immutable desktop defenders will tell you that I'm wrong; that you can easily get around these limitations by spinning up a container, tweaking config files, and rebooting. But do you see the catch? Indirection! You are introducing a Matryoshka doll effect. Now, you have to dig through logs inside the container, correlate them with logs outside the container, and pray nothing breaks when the container is rebuilt. You've just tripled the effort required to debug a simple issue. No thanks!

And honestly: you don't need a locked-down host to run containers. You can run Flatpaks, Podman, and Distrobox on Arch Linux or Debian today, keeping your application lifecycle decoupled from the host OS without surrendering control of your own system binaries.

Conclusion

Look, immutable systems have won the server room and the appliance market, and they deserved to. But until the desktop ecosystem can solve the supply chain, memory bloat, and hardware enablement crises inherent to containerized delivery, forcing a read-only root onto the general public is just academic arrogance over practical engineering. Keep the desktop mutable, keep it open, and keep owning your hardware!

Cómo convertir AlmaLinux 10 a CentOS Stream 10

Posted by Rénich Bon Ćirić ( Fedora Account System Username

renich ) on 2026-06-17 22:10:00 UTC

La neta, a veces el internet te da sorpresas chidas. Hace unos días, un compa en la red me ofreció donar dos servidores virtuales para mi proyecto de MxOS. ¡Un parote, la verdad! Pero como en todo, siempre hay un "pero": las únicas opciones de sistema operativo que me ofrecía eran Rocky Linux o AlmaLinux.

Y ahí estuvo el detalle. Para MxOS, tener CentOS Stream 10 es un requerimiento a huevo. Así que, en lugar de ponerle peros a la donación, me puse a investigar cómo cambiar el alma de esos servidores. Al final, encontré el caminito para convertir AlmaLinux 10 a CentOS Stream 10 de volada.

El Script Salvador

Para no andar haciendo todo a mano y arriesgarme a que algo valiera madres, me armé un script de Bash bien perro. Aquí te comparto el cotorreo de cómo quedó:

Note

¡Mucho ojo con las versiones! Las URLs de los paquetes en el script apuntan a la versión 10.0-23.el10. Como CentOS Stream 10 se actualiza de manera continua, es muy probable que esas versiones ya hayan cambiado en el mirror. Antes de correr el script, échale un ojo a mirror.stream.centos.org para verificar los nombres exactos de los archivos RPM más recientes de centos-gpg-keys, centos-stream-repos y centos-stream-release.

#!/usr/bin/bash

# download almalinux release, repos and gpg-keys rpms
# just in case
dnf download almalinux-{release,repos,gpg-keys}

# install cs10's repos and gpg keys
dnf -y install \
     https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/Packages/centos-gpg-keys-10.0-23.el10.noarch.rpm \
     https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/Packages/centos-stream-repos-10.0-23.el10.noarch.rpm

# remove the almalinux files
rpm -e --nodeps almalinux-release almalinux-repos almalinux-gpg-keys

# install the cs10 release
dnf -y install \
     https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/Packages/centos-stream-release-10.0-23.el10.noarch.rpm

# sync
dnf -y distrosync --allowerasing

# fix SELinux labels
fixfiles onboot

# reboot
reboot

Explicación del Jale

A primera vista parece magia, pero la neta es pura lógica de administración de paquetes de Red Hat. Deja te explico paso a paso qué hace cada comando de esta rola:

Respaldar por si las dudas: El comando dnf download baja los paquetes de release, repos y llaves GPG de AlmaLinux al directorio actual. Si todo sale mal, tener estos archivos a la mano es un salvavidas por si tenemos que dar reversa.
Inyectar los repositorios de CentOS Stream 10: Instalamos directamente las llaves GPG y la configuración de los repositorios oficiales de CentOS Stream 10 apuntando a los mirrors de CentOS. En este punto, el sistema conoce los repos de ambos mundos.
Desinstalar AlmaLinux sin romper dependencias (La Táctica): Aquí está el verdadero truco. Como almalinux-release es un paquete protegido, DNF jamás te dejará removerlo ni cambiarlo por las buenas. Usamos rpm -e --nodeps para saltarnos la protección de DNF y quitar quirúrgicamente la identidad de AlmaLinux sin que intente llevarse de encuentro medio sistema.
Instalar la identidad de CentOS Stream 10: Instalamos el paquete centos-stream-release usando DNF. Ahora el sistema se reconoce a sí mismo como CentOS Stream.
La gran sincronización: Aquí es donde ocurre la magia real. Al correr dnf distrosync --allowerasing, le ordenamos a DNF que sincronice todos los paquetes instalados con las versiones disponibles en los repositorios de CentOS Stream 10, permitiendo borrar cualquier paquete conflictivo que ande estorbando.
Alinear SELinux: ¡Mucho ojo con esto, compa! Como cambiamos la distribución y muchos paquetes cambiaron de dueño, los contextos de archivos de SELinux pueden quedar hechos un desmadre. Correr fixfiles onboot asegura que en el siguiente arranque se haga un re-etiquetado completo de todo el disco, evitando que SELinux nos bloquee servicios clave.
El reinicio final: Reiniciamos la máquina para entrar limpiecitos con el nuevo kernel y con las etiquetas de SELinux bien alineadas.

Conclusiones

Hacer este tipo de migraciones antes daba mello, pero con las herramientas modernas la neta es que es un proceso bastante noble. Aunque la persona que ofreció los servidores se me desapareció y no tengo los servidores todavía, estuvo bueno el reto para aprender a hacer esto si nos vuelven a ofrecer esto para MxOS.

¿Cómo la ves? Si alguna vez te donan servidores y no vienen con tu sabor preferido de Linux, ya te la sabes: ¡todo tiene solución, no?!

Warning

Esto se pudiera complicar si usas repositorios externos o instalas paquetes que no vienen en los repositorios. Es de sabios hacer pruebas primero, carnal.

Taking a break is good

Posted by Ben Cotton ( Fedora Account System Username

bcotton ) on 2026-06-17 12:00:00 UTC

Earlier this week, curl project lead Daniel Stenberg announced the “curl summer of bliss“. For just over a month, the maintainers will be taking a break. This includes not accepting any vulnerability reports. This is a good thing.

Most open source software relies in part or in total on the work of volunteers. Nothing can cause burnout quite like never getting a break. Even when someone is being paid to maintain software, they still need some time away. Taking time off is an investment in the long-term sustainability of the project.

“But this is bad for security!” you say. Yes, some vulnerabilities may go unaddressed. You get what you pay for sometimes. Stenberg made clear in his post that people with support contracts will still receive their agreed level of service. If the security of the project is important enough to you, there’s something you can do about it. curl has seen a large increase in security reports this year. If a month off buys extra years of maintenance, that seems like a good trade.

It’s easy for open source contributors to get wrapped up in the project. It becomes part of their identity and they sometimes feel like the project couldn’t run without them. In some cases, that’s true. But we’re all still people and we need time to regroup. If you find yourself overwhelmed, you can take a break.

This post’s featured photo by David Lezcano on Unsplash.

The post Taking a break is good appeared first on Duck Alignment Academy.

Web-Based Remote Installation for Fedora Linux: Here’s What We’re Building

Posted by Fedora Magazine ( Fedora Account System Username

admin ) on 2026-06-17 08:00:00 UTC

If you’ve ever needed to install Fedora Linux on a headless server, a Raspberry Pi, or any machine without a monitor attached, you’ve probably reached for VNC or RDP. They work – but as the installer moves to a web-based interface, there’s a new opportunity to do something more native to that model. We’re building it, and we want your input before we go too far down a path that’s hard to reverse.

Why This Is Happening

The Anaconda installer’s Web UI first landed in Fedora Linux 42 Workstation and was extended to all Live spins in Fedora Linux 43. It’s a full graphical installer built on Cockpit tooling and using PatternFly widgets. The GUI is rendered in a fullscreen browser window – but until now, that browser had to be running on the same machine you’re installing onto.

Here’s the thing: VNC and RDP were built around the GTK interface. While RDP could technically work with the Web UI too (it operates at the display level), a remote browser is a much better fit – orders of magnitude less data and much lower UI latency. As the Web UI becomes the primary installer interface across Fedora Linux editions, it needs its own native remote access story.

On top of that, there are two more forces pushing in the same direction.

As browsers move toward Flatpak packaging – already the reality for atomic desktops and derivatives like Bazzite – remote installation opens an opportunity for shipping focused, smaller boot images that don’t need to bundle a local browser at all. A lightweight ISO aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine.

And once you have a browser-rendered installer, serving it to a remote browser is the natural next step anyway. A headless ARM SBC doesn’t need to run a GPU-accelerated browser locally just to show you a disk partitioning screen. Your laptop can do that for it.

What It Actually Is

The concept is pretty straightforward: Anaconda’s Web UI, already built on Cockpit, gets served over HTTPS. You point a browser at the machine you’re installing, authenticate with a PIN, and you’re controlling the installation remotely. No VNC client, no RDP client, no X forwarding. Just a browser.

If you’ve used Cockpit to manage a server, you already have a feel for the experience. The difference is that the machine you’re connecting to is mid-install, not running a full OS.

Use Cases

The ones we’ve talked through most:

Headless servers – You’re installing onto a server in a rack with no attached display. You expose the Web UI over the network and control everything from your workstation.

Lightweight ARM SBCs – Devices like Raspberry Pi have limited resources. With remote rendering, the Pi just runs the installer backend; all the UI rendering happens on whatever machine you’re connecting from.

Remote monitoring – Even if you’re not fully headless, being able to watch an installation from another machine is genuinely useful. Kick off a server install, go make coffee, check progress from your laptop.

The Design Decisions So Far

We’ve had some meaty discussions about how this should work, and a few things are now settled.

Authentication: You set a PIN through kickstart or boot options, and type it into the browser login page. Same pattern as VNC and RDP – the user provides the password, not the system.

TLS with self-signed certificates: The connection is encrypted, but the certificate is generated on the fly at boot. That means your browser will show the “this certificate isn’t trusted” warning. We’ve accepted this tradeoff – shipping a private key on installation media is a security risk, and the IP address isn’t known ahead of time, so standard PKI doesn’t really apply. For environments that need proper certificates (say, a university deploying at scale), Image Builder is likely the right path to embed custom certs. That’s a later problem.

Single connection only: Only one browser session can connect at a time. Two concurrent sessions could genuinely conflict – one session starting installation while another changes the storage configuration. So: one connection, full stop.

Reconnection behavior: If you disconnect and reconnect, what happens depends on where the installation was. Before the review screen – the point of no return – you start from step one. After the review screen (installation actually running), you land on the progress view. Simple two-state model, covers the critical cases.

Config isolation and port: All Cockpit configuration specific to remote installation lives in /etc/anaconda/cockpit/, not the default Cockpit paths – otherwise the config could leak into the installed system. We’re leaning toward port 443 by default so you can just point your browser at the machine’s IP without specifying a port, but the port will also be configurable.

How This Compares to VNC and RDP

VNC has been around in Anaconda for years; RDP support was added more recently. Both work by screen-sharing the GTK interface. Technically, RDP could work with the Web UI too – it operates at the display level, scraping pixels from the screen. But a remote browser is simply better: you send orders of magnitude less data and get much lower UI latency compared to streaming a full desktop.

Beyond performance, there are practical advantages. No client is required – any modern browser works. No VNC viewer to install, no RDP client to configure, no protocol quirks across platforms. And it’s the same Web UI we’re already actively developing, so features and fixes automatically benefit the remote experience. With VNC or RDP, you’re screen-sharing a separate GTK codebase – a separate maintenance burden.

VNC and RDP aren’t going away for now – they still work with the GTK legacy interface. But as the Web UI becomes the default across more Fedora Linux editions, browser-based remote access is where the investment goes.

Where We Are Right Now

This is a developer preview. Here’s what’s working:

Custom login page with PIN-based authentication
Separate socket-activated systemd unit for auth (clean separation from the main Cockpit process)
Session cookies that survive tab closes, require re-login on browser close
Cockpit config in an isolated, anaconda-owned path

Here’s what’s still open:

Single-connection enforcement (this will likely require close collaboration with the Cockpit team)
Backend detection of whether installation is already running (this is needed for proper reconnection behavior)

If you want to see the PoC in action, there’s a draft PR at rhinstaller/anaconda-webui#1274 with the authentication setup – custom login page, pin-based auth script, socket-activated systemd units, and the Cockpit config override. To try it yourself, clone the PR branch, build an updates image, and boot it with virt-install:

git clone -b poc-remote https://github.com/bruno-fs/anaconda-webui.git
cd anaconda-webui
make create-updates.img

virt-install \
  --name anaconda-remote-test \
  --ram 4096 \
  --vcpus 2 \
  --disk size=20 \
  --location /path/to/Fedora-Everything-netinst-x86_64-Rawhide.iso \
  --extra-arg "inst.updates=http://your-host:port/updates.img" \
  --extra-arg "inst.webui.remote"

This is a proof of concept, not production-ready code. The PIN is hardcoded to 1234, there’s no TLS, and single-connection enforcement isn’t in place yet. Don’t use this for real installations – it’s meant to show the direction and let you poke at the approach. Once the installer boots, point a browser at the VM’s IP and enter 1234 on the login page. It’s rough, but it runs.

What We Want to Hear From You

We’re sharing this now because some of these decisions are hard to unwind once the feature ships, and community input is more useful now than after the fact. A few things we’re genuinely thinking about:

Remote installation is opt-in – you enable it through boot options or kickstart. But here’s a question we’re genuinely considering: should we ship a lightweight boot ISO without a local browser, with remote installation enabled by default? A minimal image aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine. Would that be useful to you? And if you’re using VNC or RDP for remote installation today, would this replace them? What would it need to do that it doesn’t yet?

Come talk to us on Matrix (#anaconda:fedoraproject.org), or leave a comment on this article. You can also follow the work on the anaconda-webui GitHub repo. We’re looking forward to hearing from you.

Flock to Fedora report 2026

Posted by Jakub Kadlčík ( Fedora Account System Username

frostyx ) on 2026-06-17 00:00:00 UTC

This post is tough to write because Flock to Fedora is my favorite conference, and last year’s Flock might have been the best conference I’ve ever been to. I love the Fedora community, Prague is beautiful, the venue is nice, we always have so many interesting talks and workshops, the organizers do an amazing job preparing this event for us, so I feel really guilty saying that I did not have much fun this year. That is 100% on me, though. Flock bears no blame.

It wasn’t exactly the wisest decision ever to run my first half-marathon the very evening before the conference, and then waking up early to commute to Prague. It must have hit me much more than I was willing to admit. I feel fine physically, but I can’t pay attention to anything because nothing feels exciting. That is the most lifeless I’ve felt in a long time.

So, in case anyone is wondering … it was me, not you.

Highlights

Despite all that, these were the highlights of the event for me.

Forging Fedora Project’s Future With Forgejo

Great job on the migration from pagure.io to forge.fedoraproject.org. It was handled exceptionally well. Next, we look forward to the migration of src.fedoraproject.org to Forgejo, which can’t come soon enough. Tomáš Hrčka teased us that this migration may take considerably less time than the previous one because they already know how to do things (e.g., deploy Forgejo, etc).

DIY AI: Build a Private, Customizable Chatbot on Lean Hardware

Ellis Low showed us how to run an LLM on our laptops through Llama and how to interact with it. I really appreciated him saying that, except for this one small text-in, text-out magic black box, everything else is standard software engineering as we know it.

Fedora Council Strategic Proposals + FESCo Q&A

Most of the discussion revolved around a decline of new contributors and us failing to connect with the next generation. “They talk about changing wallpaper, we talk about burnout” – Aleksandra Fedorova.

What’s Cooking in Copr, Testing Farm, tmt, Packit and Log Detective

I found Pavel Raiskup’s return to the stage hilarious.

Scrapers gotta scrape scrape scrape

As presentations go, Kevin Fenzi’s talk about AI scrapers was the best. It started with minor A/V dificulities, which is a nice reminder to not feel bad, the next time it happens to you, because it happens to everybody. Even the main infra guy. Semi-joking aside, I enjoyed the brief history of web scraping and Kevin’s taxonomy of scrapers, clearly showing that not all scrapers are the same (e.g., web.archive.org). However, the current AI scrapers are the plague of the internet, and I am so glad the Fedora Infra team fights them as best as they can to keep our services running.

Chat with Adam

I ran into my former Copr team mate Adam Šamalík in the hallway, and we had a nice chat about life. When we still worked together (10 years ago, oh how the time flies), I randomly asked him what he did on a weekend. “We had no plans, so we bought plane tickets and went on a date to Amsterdam with my girlfriend”. Fucking what?! That was the coolest response ever. Since that day, I remember it every time my creaking, lazy bones struggle to do something spontaneous. Why am I telling it now? Adam is now happily living in the Netherlands full-time. Funny how one impromptu decision can completely change your life.

Chat with Emmanuel

Made friends with Emmanuel Seyman. He said hello after seeing the Fedora Podcast episode with me as a guest. I really enjoyed our chat, and I am going to follow up online because I think he’ll really like Sundaram Krishnan’s project coprtree.

Chat with Miro

Miro Hrončok shared some of his ideas about improving the Fedora Package Review Process with me. This deserves an article on its own, so stay tuned.

What’s Next for Pagure.io?!

Posted by Fedora Magazine ( Fedora Account System Username

admin ) on 2026-06-16 14:59:15 UTC

At the Flock 2026 Birds of a Feather session, poetically named FFFwF (or, for us lazy people, Forging Fedora’s Future with Forgejo), we discussed the current state of our migration effort to the new forge. I asked the obligatory question: Who still has things on pagure.io?!

A few brave contributors raised their hands, some with an uneasy look in their eyes. Miro swiftly pointed out that everybody is affected by one particular repository; looking at you, `fedora-scm-requests`. Luckily, the RelEng folks have it in their sights. Sure, there are a few other repos lying around the old faithful, but it is time for the Fedora Project to move on and embrace the Forge.

Our new home is currently running on the LTS branch in v15.0.2. We are going to stick with it in production, and our next LTS upgrade will be to v19.

What is going to happen next?

Pagure itself as a project is hosted on pagure.io, and that service is going to be decommissioned at the end of July 2026. What does that mean for you? Well, that depends on when you are reading this.

If you just came back from Flock 2026 and you still have active repositories on pagure.io, here is what you need to do:

Check out the existing organizations in the Forge. If your project fits into any of the existing ones, ask its owners for a migration.

If it doesn’t fit, open a ticket with the forge team, and we will help you decide the best path forward.

Some of us have commits in projects that point back to pagure.io. Don’t worry, we are not going to break your links, for foreseeable future. We will explore options for implementing redirects so your historical links successfully point to their current locations.

The best way to handle the transition after your move, right now, is to inform your users about your new home. Add a BIG BOLD ANNOUNCEMENT to your README, close all open issues, and create a single pinned issue with your migration announcement.

Note: Do not expect to be able to log in to pagure.io after July 2026.

Wait… and what about `dist-git`?

Well, that is the next target in the scopes of the Forge team. As I showed you in the room, we have 11 Features that define the transition. The biggest task at hand is a bit more sneaky. We are missing multiple enhancements to the upstream project that will require a lot of coordination and Go code. So, if you find yourself in possession of spare cycles and a particular need to help us make it better and faster, Forgejo is waiting for you!

A road-map with all the tasks for the move will land in the Forge soon. (See resource list below.)

Important Links & Resources

Check out the new home: Browse existing organizations on the new Fedora Forge
Want to write some Go? Contribute to the upstream Forgejo project.
Track our progress: Migration roadmap will be posted here soon

AI Disclaimer: Grammar and formatting were done with the help of robots; all the original brain-farts are my own.

syslog-ng 4.12.0, syslog-ng PE 8.2.0 and SSB 7.8.0 are now available

Posted by Peter Czanik ( Fedora Account System Username

czanik ) on 2026-06-16 14:50:23 UTC

Today, the syslog-ng team released three different syslog-ng versions, which provided a good opportunity to wear my “Release is coming” t-shirt. This coordinated release is due to an SQL injection security bug fix, even if most likely it affects less than a handful of people (I mean, is there anyone who still uses SQL to store logs in 2026…?)

What’s new?

syslog-ng OSE 4.12.0 arrives with performance optimizations, making syslog-ng more scalable in several situations. Many user-reported bugs were fixed as well. RPM-based containers are now available, utilizing Alma Linux under the hood.
syslog-ng PE 8.2.0 focused on bug fixes and now also allows users to use extremely complex configuration files.
SSB 7.8.0 adds support for Proxmox and Nutanix virtualization.

What’s next?

For more details, check the respective release notes. The syslog-ng OSE release notes are available at https://github.com/syslog-ng/syslog-ng/releases/tag/syslog-ng-4.12.0 Release notes for the commercial products should be available soon at https://docs.oneidentity.com

From Contributor to Outreachy Intern: My Fedora Journey Begins

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-16 12:00:00 UTC

Introduction

Hi, I’m Aman, a software developer and open-source enthusiast who enjoys backend development, APIs, and building tools that are useful to others.

I recently started my Outreachy internship with the Fedora community, and this is my first blog as an intern. In this post, I want to share what my first two weeks have been like, what I’ve learned so far, and what I’m looking forward to in the next phase of the internship.

I’m working on the Fedora Release Schedule Planner API, a project focused on improving Fedora’s release planning workflow by moving away from older XML-heavy processes and strengthening the current FastAPI-based API through better tests, authentication, and infrastructure integration.

About the Fedora Community

Fedora is a global open-source community behind Fedora Linux and many related projects. People contribute in many areas, including packaging, infrastructure, design, documentation, testing, and release engineering.

One thing I’ve enjoyed learning about Fedora is its Four Foundations: Freedom, Friends, Features, and First. These values reflect Fedora’s focus on free and open-source software, community, innovation, and adopting new technologies early.

What I like about Fedora is that it is not only about writing code. Communication, documentation, reviews, and helping new contributors are also important parts of the community.

Through this internship, I’m also getting a better understanding of Fedora’s release process and how different contributors work together to improve the tools used by the community.

About My Project

My Outreachy project is Enhancing the Fedora Release Schedule Planner API.

Fedora’s traditional release planning workflow relied heavily on manually edited XML files, which made the process difficult for newcomers, harder to scale, and less connected to modern tooling.

The Fedora Release Schedule Planner API is a modern FastAPI-based project hosted on Codeberg. It has already moved from Flask to a modular FastAPI architecture, uses Pydantic for data validation, provides auto-generated Swagger documentation, and relies on Forgejo Actions for CI/CD testing.

The goal of my internship is to help make this API more production-ready. My work will focus on improving the test suite, strengthening CI reliability, adding secure authentication with OpenID Connect, integrating the API with Fedora infrastructure data, and preparing it for deployment.

Learning More About the Community

I had already started contributing to the Fedora Release Schedule Planner API during the Outreachy contribution period. During that time, I joined the project’s Matrix chat, went through issues and pull requests, and became familiar with the basic project structure.

So, during the first two weeks of the internship, my focus was more on understanding the project in depth. I followed discussions in the Matrix chat, worked through issue and pull request conversations, and learned how mentors and maintainers review changes.

We also have a weekly Google Meet call with the mentors. These calls are helpful for discussing progress, asking questions, and understanding what to focus on next.

Alongside exploring the codebase, I spent time reading Fedora documentation and project-related resources to better understand the release planning workflow.

I also explored the FastAPI codebase, tests, CI setup, and previous pull requests more closely. This helped me understand how tools like Pydantic, Swagger documentation, and Forgejo Actions are being used in the project.

Challenges and Wins

One of my biggest challenges in the first two weeks was understanding the codebase beyond its basic structure. During the contribution period, I had already become familiar with the main parts of the project, but during the internship, I started understanding how different layers work together, including API routes, database models, Pydantic schemas, services, templates, and tests.

Another challenge was making sure my changes did not affect existing behavior. I had to run tests, check formatting, and verify things locally before updating a pull request.

My biggest win was becoming more confident with the project workflow. I was able to work on issues, raise pull requests, respond to review feedback, and understand the expectations around code quality and maintainability.

I also became more comfortable with the tools used in the project, including FastAPI, SQLAlchemy, Pydantic, Jinja2, HTMX, tests, and CI checks.

A small win for me was getting some of my pull requests merged. For example, PR #425 and PR #427 helped me understand the review process better and gave me more confidence while working on the project.

Plans for the Next Month

In the next month, I want to continue building on the work from the first few weeks. Currently, we are focusing on fixing UI-related issues, improving the code structure, and aligning the codebase with the project’s expected structure.

Along with that, I want to keep improving the test suite and make sure the API works correctly with the current FastAPI and Pydantic structure.

I also want to start preparing for the authentication part of the project. Since OpenID Connect is an important goal of this internship, I plan to spend time understanding how Fedora authentication works and how it can fit into the Release Schedule Planner API.

After that, I want to gradually learn more about how this API can connect with Fedora infrastructure data. This is important because the long-term goal of the project is to move away from the older XML-based workflow and make the release planning process more modern and maintainable.

Conclusion

These first two weeks have helped me understand the project better. I now have a clearer understanding of the Fedora community, the Release Schedule Planner API, and how people collaborate in open source.

I still have many things to learn, but I feel more comfortable with the project now than I did at the beginning of the internship.

I am thankful to Outreachy, Fedora, and my mentors for this opportunity, and I am looking forward to continuing the work in the coming weeks.

PS: Cover image generated with the help of an AI tool.

The post From Contributor to Outreachy Intern: My Fedora Journey Begins appeared first on Fedora Community Blog.

Deux nouvelles versions majeures pour SeedboxSync et SeedboxSyncFrontend

Posted by Guillaume Kulakowski ( Fedora Account System Username

llaumgui ) on 2026-06-15 18:55:11 UTC

Ce week-end marque la sortie de deux versions majeures de mes projets SeedboxSync et SeedboxSyncFrontend. Au programme : support FTP, optimisations de performances, suivi en temps réel des téléchargements, administration depuis l'interface web et plusieurs améliorations de l'expérience utilisateur.

Sandbox AI coding agents with microVMs on Fedora Linux

Posted by Fedora Magazine ( Fedora Account System Username

admin ) on 2026-06-15 08:00:00 UTC

AI coding agents such as Claude code or Codex get more capable every month. This is great for productivity, but approving all commands gets annoying really quickly. On the other hand, allowing agents to run any command on your work machine is not a great idea. They are really good at exploring your production cluster using kubectl or running remote commands at your production servers over SSH.

Fortunately, Linux distributions come with plenty of options for process isolation. You can run agents as a completely different user, in a container, or in a VM. This article shows how to use microVMs to run coding agents.

Security concerns

Running AI agents in unattended mode is like running untrusted code. Companies behind these agents, such as Anthropic or Google, are not trying to steal credentials, but people keep coming up with new attack vectors like Slopsquatting or prompt injections virtually anywhere.

The coding agents themselves ship with built-in mitigations that try to refuse prompt injections as described, for example, here.

Lightweight sandboxing technologies are another layer of defense in coding agents. On Linux, bwrap is one of the possible implementations. This raises the bar, yet sandbox escapes are still a problem. Take a look at CVE-2026-39861 as an example of multi-platform sandbox escape.

You could use containers to isolate the agent in their own namespace, but they still share the host kernel. Some of the the recent kernel vulnerabilities resulted in privilege escalation (switching from regular user to root) suggesting that containers are not enough as a security boundary.

In the rest of this article, I describe how to use microVMs to easily sandbox coding agents on your Fedora Linux.

Exploring microVMs

First of all, let’s take a look at what microVMs are. Just like any VM, they have their own kernel, one per each microVM. Compared to traditional VMs they start in very short time (hundreds of milliseconds) but don’t offer all the features of full VMs.

This article explains usage of krun runtime for podman. This approach offers the same well-known workflow as containers, but simply runs every container as a microVM.

Start by installing the runtime:

dnf install crun-krun

To run a microVM, simply run podman with –runtime=krun in your terminal:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

Things to watch out for

A microVM is not a regular container, so a few things might behave differently. First, allocate enough CPU and RAM with krun annotations. The defaults are too small and might result in OOM (Out Of Memory) kills. Second, make sure you have libkrun version >= 1.8. Older versions have a bug which prevents you from pressing Enter in your coding agent. Third, the microVM ignores the USER set in the Dockerfile and always boots as root. Either switch to the correct user manually or put the switch into an entrypoint script.

Case study: sandboxing Claude Code for a Python project

This section outlines a simple setup for a Python project managed by uv. It uses podman-compose to mount the project into the microVM. Compared to containers, this podman compose needs additional annotations for UID/GID translation, SELinux labeling, and HW resources. The final setup is very similar to what you would need for containers.

To install podman compose from official Fedora repositories, run:

dnf install podman-compose

The setup has 3 parts:

Dockerfile
docker-compose.yaml
entrypoint.sh

Dockerfile

As mentioned above, podman with krun runtime still runs containers, but spawns each of them in a microVM. This example container includes uv package manager, claude code and a few additional RPM packages. Define your own container based on your project dependencies and programming language.

Make sure to create an unprivileged user and use it for running the agent.

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Create group and user matching host UID/GID
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Rarely-changing tooling. Kept above the dnf layer so editing the RPM list
# below does not invalidate (and re-run) these installs.
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# Frequently-changing RPMs. Kept last so adding a package only rebuilds from here down.
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

# This is needed because entrypoint does not have .local/bin in the PATH
ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

docker-compose.yaml

The compose file defines how to mount the project directory into the microVM. This is where most of the magic happens, because podman needs to translate UID/GID and manage SELinux labels, otherwise the files would not be accessible inside of the microVM or they would end up being owned by a different user.

services:
  claude:
    container_name: project-name-claude
    annotations:
      run.oci.handler: krun
      krun.ram_mib: "4096"
      krun.cpus: "4"
    user: "${HOST_UID}:${HOST_GID}"
    userns_mode: keep-id  # optional, for rootless host
    build:
      context: .
      args:
        HOST_UID: "${HOST_UID}"  # use UID and GID from the host so that files created in the container have correct permissions
        HOST_GID: "${HOST_GID}"
    volumes:
      - ../:/app:U,z  # bind mount your project
      - project-name-venv-cache:/venv:U,z
      - claude-config:/home/appuser/.claude:U,z  # persistent claude credentials/config
    working_dir: /app
    stdin_open: true
    tty: true
    environment:
      - CLAUDE_CONFIG_DIR=/home/appuser/.claude
      - UV_LINK_MODE=copy
      - UV_PROJECT_ENVIRONMENT=/venv/env  # This is inside the cached volume
      - UV_PYTHON_INSTALL_DIR=/venv/python  # So that uv-managed python installations are not in home but cached in /venv
      - TERM=xterm-256color
      - COLORTERM=truecolor

volumes:
  project-name-venv-cache:
  claude-config:
    external: true
    name: claude-config

There are 3 key parts:

annotations – these select krun as a runtime and specify HW requirements
user and userns_mode – this tells podman to translate UID/GID so that the files created in the microVM end up owned by your user on the host
volume labels – z tells podman to relabel the files with a shared SELinux label. Otherwise SELinux would prevent the process inside the microVM from touching the files in the volume. U tells podman to recursively chown all files.

entrypoint.sh

The entrypoint creates a virtual environment for the Python project, because we don’t want dynamic dependencies baked into the container image. It also runs the switch from root to regular user because podman with krun runtime ignores the USER directive from the container.

#!/bin/bash
set -e

echo "Sandbox started as user: $(id -un) in directory: $(pwd)"

if [ "$(id -un)" != "appuser" ]; then
  runuser -u appuser -- uv sync
  echo "Running ${@} as appuser"
  exec runuser -u appuser -- "$@"
fi

uv sync
exec "$@"

Run the setup

First, build the container:

$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml build
STEP 1/18: FROM fedora:44
...
Successfully tagged localhost/agent-sandbox_claude:latest

Then create the external volume and run the claude container interactively:

$ podman volume create claude-config
$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml run --rm claude
Sandbox started as user: root in directory: /app
Resolved 3 packages in 6ms
Checked 3 packages in 1ms
Running /bin/bash as appuser
tty: ttyname error: Inappropriate ioctl for device
[appuser@3bd1234b9a77 app]$

You can now check that the kernel is different by running uname -a inside of the microVM.

Putting it together: single script to create the whole setup

Creating the same setup manually for every project is not the greatest user experience, but you can automate the setup using a simple script like this. It installs a new sbx command that wraps the setup described above into 3 simple command options: init, build, and run.

A word of caution — microVM is not a bulletproof boundary

A microVM raises the bar considerably, but it is not perfect isolation, and it would be irresponsible to present it as such. Take a look at the libkrun git repository to read more about the security model.

If you want to run software that might be dangerous, prefer using a full VM or even cloud VM.

Conclusion

MicroVMs seem like a sweet spot for running AI Agents. They provide a familiar workflow of containers, but the agents run on their own kernel behind a hypervisor. This article describes workflow based on podman and krun runtime because Fedora Linux ships both of them natively, but there are plenty of other options available for any platform (for example docker sandbox).

Note about AI usage: I wrote this article myself. I used Claude (Anthropic) to significantly refine the grammar, wording, and sentence structure; the technical content and all claims are my own and tested.

F44 Election Results

Posted by Fedora Community Blog ( Fedora Account System Username

admin ) on 2026-06-13 16:16:29 UTC

The F44 election cycle has concluded. Below are the results. We are posting the results early this year as we are currently on the eve of Flock to Fedora 2026 and the results were ready. Thank you to all candidates and voters, and congratulations to the newly elected members!

Results

Council

Two Council seats were open this election. A total of 204 voters participated in this election.

# votes	Candidate
958	Miro Hrončok
788	Aleksandra Fedorova
744	Fabio Valentini
637	Tomáš Hrčka
509	Vít Smolík
451	Akashdeep Dhar
337	Hristo Marinov

FESCo

Five FESCo seats were open this election. A total of 199 voters participated in this election

# votes	Candidate
771	Neal Gompa
700	Fabio Valentini
662	Michel Lind
604	Maxwell G
549	Simon de Vlieger
537	Adam Miller

Mindshare

Four Mindshare seats were open this election. A total of 154 voters participated in this election.

# votes	Candidate
419	Samyak Jain
396	Akashdeep Dhar
395	Luis Bazan
351	Mat H (Mat Holmes)
214	Kenz S (Makenzie Stewart)

EPEL Steering Committee

Four EPEL Steering Committee seats were open this election. As the amount of interviews submitted equaled the number of open seats, candidates who interviewed were automatically elected.

# votes	Candidate
Automatically Elected	Carl George
Automatically Elected	Diego Herrera
Automatically Elected	Jonathan Wright
Automatically Elected	Troy Dawson

The post F44 Election Results appeared first on Fedora Community Blog.

Justin Wheeler on Growing Up in the Fedora Community

Posted by Fedora Magazine ( Fedora Account System Username

admin ) on 2026-06-12 15:53:38 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

In 2015, an 18-year-old student walked into his first Flock not knowing a single person. He was shy, a little overwhelmed, and had no idea what he was walking into. By the time he walked out, something had shifted. The community had been so genuinely welcoming, so warm and easy to fall into that he left not just curious about Fedora, but hungry to be part of it.

That student was Justin Wheeler. And Flock never really let him go.

What started as one conference became a thread running through his entire open source journey. First he became a Fedora Magazine author. Then editor-in-chief. And now, as Fedora Community Architect, he’s the one standing on stage at the opening and closing looking out at the very kind of room that once changed his life helping shape the event that shaped him.

He’ll be the first to admit it’s a lot. “It’s way more intense and hard work than I ever could have realized,” he says, with genuine respect for everyone who built Flock before him. But that experience of once being the nervous newcomer gives him something no job description could have: an instinct for why people show up and what makes it matter.

For Justin, the answer has always been the hallway track. Not the sessions, the spaces in between them. The moment you bump into the exact person you need to talk to. The lunch conversation that turns into a collaboration. The game night and candy swap where the ice finally breaks and people stop being usernames and start being friends. “It’s the relationships we get to strengthen and build,” he says, “that make us so much more effective in everything we do the rest of the year.”

That’s also what data can’t capture and Justin thinks about this a lot as part of the Data Working Group, where he works alongside Michael Winters and Robert Wright to understand community health. Numbers can tell you a lot. But they can’t show you a first-timer lighting up when they realise they belong here. They can’t measure the moment the community becomes real.

His advice for anyone walking into Flock for the first time? “Don’t be shy. Leave your comfort zone a little. And definitely don’t skip the social events.” He says it like someone who knows exactly what it feels like to need that push and exactly what’s waiting on the other side of it.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Friday Links 26-19

Posted by Christof Damian ( Fedora Account System Username

cdamian ) on 2026-06-11 22:00:00 UTC

A tall wall of bookshelves packed with colorful paperbacks, fronted by leather armchairs, a round wooden table, and an antique globe

Two good engineering podcasts to listen to this week, the one about OpenCode and the one about spec-driven development. I also really enjoyed the video about the Watchmen comic and film.

Quote of the Week

I had not quite realized that the interruptions were the journey.

Jupiter's Travels

Ted Simon

Engineering

Building OpenCode with Dax Raad [Podcast] - I have been trying to use it with local models. Those are just not as good yet.

What you need to know about the Microsoft Secure Boot certificate expiration: Don’t Panic!

Posted by Fedora Magazine ( Fedora Account System Username

admin ) on 2026-06-11 08:00:00 UTC

UEFI Secure Boot keys, used to sign the first stage boot loader, are expiring in June 2026 (this month!) But that only means that Microsoft can no longer sign with them. Machines, both bare metal and virtual, will continue to boot long after June is over as long as the current public keys are not removed from the firmware database or revoked via the dbx database. In the meantime, Fedora Rawhide (f45) already contains a first stage boot loader that is signed by multiple keys for maximal compatibility. So there is no need to panic, but action is recommended.

Secure Boot basics

UEFI Secure Boot is a security feature which ensures only trusted (signed) applications run during a computer’s boot up process. This applies to the boot loaders, the operating system kernel, and the kernel modules. Trust is established using asymmetric cryptography. Tested algorithms, like R S A or ECDSA, are used to create asymmetric key pairs. The private key is used to sign the application. A totally different but complementary public key is used to verify the application. The private key is kept secret while the public key is available to anyone who wants to run the application. UEFI Secure Boot is only available for machines that run UEFI firmware, and for Fedora, the key expiration only applies to the x86_64 architecture (Intel, AMD), and to those who have Secure Boot enabled.

The root of trust for Secure Boot is in the firmware. Hardware manufacturers add trusted Secure Boot public keys to their devices’ Secure Boot firmware database (db). Firmware for virtualization, known as edk2-ovmf, is built with similar trusted public keys. In order to simplify the process, there is a central signing authority which signs the first stage boot loader. This is the “shim” whose public key is enrolled pretty much everywhere, and that is Microsoft. Microsoft first started signing shim with their 2011 UEFI Third Party CA, but by the end of June they will no longer be able to do so. Since October 2025, Microsoft began signing with a new 2023 key as well. Once the 2011 key expires, new shims will only be signed with the 2023 key.

The OS maintains the rest of the Secure Boot chain. Fedora’s shim embeds a Fedora Secure Boot public CA key. Private keys on Fedora’s signing server are used to sign the next stage boot loader (grub2), the kernel, and any other applications that need to run during the boot process (like fwupd for firmware updates or unified kernel images– UKIs)

When the kernel is built, kernel modules are signed using an ephemeral key. Only signed kernel modules can be loaded when Secure Boot is enabled.

Action Recommended

The fact is that you don’t really have to do anything about any of this right now. Your computer will continue to boot. New installations of both older and new OSes will continue to be possible.

BUT, we recommend updating your Secure Boot database if and when an update is available. The next deliverable shim update can only be signed by the 2023 key and it is best to be prepared. While there are no known exploitable security vulnerabilities in shim at this time, new ones may be found next month or next year. Below are some commands that will help you determine what state your computer is in, and how to make the correct updates.

How to tell if you have UEFI or legacy BIOS

The presence of the /sys/firmware/efi directory is the clearest way to check whether you are running UEFI firmware or legacy BIOS. The following command will print “BIOS” if the efi directory does not exist:

$ [[ -d /sys/firmware/efi ]] || echo BIOS

How to check if Secure Boot is enabled

$ mokutil --sb-state
SecureBoot enabled

The Secure Boot state may be “enabled”, “disabled”, or the machine may be in “Setup Mode”, which means there are no Secure Boot keys enrolled in firmware.

How to identify which keys are in the firmware db

$ mokutil --db --short
580a6f4cc4 Microsoft Windows Production PCA 2011
45a0fa3260 Windows UEFI CA 2023
46def63b5c Microsoft Corporation UEFI CA 2011
b5eeb4a670 Microsoft UEFI CA 2023

This output is from a VM, and as you can see, it already contains the 2011 and 2023 public keys. Your laptop or desktop will also show other database keys from the manufacturer.

How to update the firmware db

Enable and use fwupd to get your updates from the Linux Vendor Firmware Service (LVFS):

$ sudo fwupdmgr update

If you have an HP or Fujitsu machine, the update will be available soon, after you have updated your firmware. Use either the above command, or the vendor-recommended command at that time.

How to check which key(s) signed the shim

$ sudo dnf install pesign -y
$ sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi
----------------------------------------------
certificate address is 0x7f3fffc11410
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
----------------------------------------------
certificate address is 0x7f3fffc139e0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft UEFI CA 2023 signer
No signer email address.
No signing time included.
There were certs or crls included.
-----------------------------------------------

The output shown here is from the dual-signed Fedora Rawhide (F45) shim. If Rawhide is not installed, the shim will only be signed with the first key, which is the 2011 key.

You can use the same pesign command to examine grub2 (/boot/efi/EFI/fedora/grubx64.efi) and the kernel (/boot/vmlinuz-…).

What NOT to do

If a database update is not available for your system, contact your hardware manufacturer. Do not attempt to force an incompatible update. Do not update your database manually unless you know exactly what you are doing!

Do not remove or revoke the 2011 key. The 2011 key is not compromised, it is only expiring, so there is no need to remove it. Additionally, it was used to sign option ROMs, so removing it could render peripherals on your system inoperable. Likewise, adding the 2011 key to the firmware dbx database (the forbidden database) will affect option ROMs. This will stop the dual-signed shim from booting.

New badge: Czech Mate! !

Posted by Fedora Badges ( Fedora Account System Username

admin ) on 2026-06-11 05:35:14 UTC

You joined the party at Flock 2026 in Prague!

Fedora People Blog List Feeds RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll

The Hallway Track

"Generational Switchover" and Packager Data Trends

Record-Breaking Sponsor Engagement

Fill Out the Flock 2026 Post-Event Survey!

My Halfway Journey as an AI/ML Engineering Outreachy intern at the Fedora Project: building toward a tool for 30 years of RPM Packaging guidelines

Resources

Installation

Changelog

Artifacts

Celestial Gift

Disenchantment in Deep Shadow

Characters

Nicole

Lohen

Prune

Weapons added

Angelos' Heptades

Disaster and Remorse

Appeal

Disclaimer

Table of contents

Announcements

Council

FESCo

Decisions

Packaging Committee

Mindshare

Ambassadors

Workstation / GNOME

KDE

Server

Infrastructure

Decisions

Release Engineering

Decisions

Quality

Decisions

Design

Decisions

Docs

Decisions

Internationalization

COPR

EPEL

Decisions

ELN

Atomic

CoreOS

Decisions

IoT

Cloud

AI & ML

RISC-V

Security

Gaming

Perl

Other Discussions

New contributor introductions

Orphaning packages

Package updates

RHEL10 migrations

2fa in Fedora

s390x builds backup and koji session bug

Some PTO next week

Background

Migration steps

Shrink the system partition on the source system

Erase the target system

Establish an Ethernet/Thunderbolt network link

Thunderbolt setup

Connectivity test

Replicate partition table from source to target

Copy all partitions

Expand the System partition on the target system

Reboot the target system

Boot problems

Mentions of other cloning approaches

Hardware used

The first issue

Fedora People
Blog List

RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll