In chapter 10 of Program Management for Open Source Projects, I talk about triaging bug reports. One of the questions in that process is “is it a security bug?” That’s good for helping you sort the security reports from the non-security reports, but what do you do when the answer is “yes”?
The crushing weight of security reports
In the first third of this year, we’ve seen a remarkable increase in security reports, particularly against popular open source projects. This isn’t (just) AI slop, it’s also AI quality. Daniel Stenberg says we’re in a “high-quality chaos era.” GitHub is tightening the rules on its bug bounty program because the staff can’t keep up.
Despite the hype about Claude Mythos Preview, I’m not particularly worried about the severity of security reports; I’m worried about the volume. There’s slop coming, yes, but also a lot of medium-to-high quality reports. And maintainers are going to have to deal with them.
How to triage security reports
The vast majority of open source projects are too small to provide the sort of reputational boost that finding a vulnerability in, say, the Linux kernel would provide. But even if you’re not get deluged with security reports (and even if you may never be), it’s good to start planning now.
Create a security policy
A good first step is to create a security policy and store it in a place like SECURITY.md in your repo. This doesn’t have to be long and complex. Even a few sentences is better than nothing.
At a minimum, tell people how to submit security reports. Do you want them sent through some private mechanism for coordinated disclosure? Do you want to take libxml2’s approach and treat them like any other bug report? If you are doing the private reporting mechanism, what should the reporter expect next? Do you have a response timeline? A default coordinated disclosure timeline? Do you offer a bug bounty program? These can all be “no”, of course. The goal here is not to place unwanted obligations on you as a maintainer; the goal is to set expectations in advance.
You may also want to add things that come up in the following section to your security policy as well.
And of course, the security policy is not just for reporters — it’s also for users. You may include information about what releases get security fixes and how those are handled. When do you bundle certain security fixes into a planned release and when do you do a special release? Do you even say which releases are “security releases”?
As you triage the reports you get, you should ask yourself some questions. There’s no scoring system here (although you could try to devise one if that makes you happy). Instead, this is about rejecting bad reports and moving a particular good report up and down the stack. If you only have one report to deal with at a time, you don’t need to worry about prioritizing against other vulnerabilities, only against your regular work.
Quick-reject questions
Is this in your software? If it’s a security issue in one of your dependencies, the reporter should file it upstream. (If you can mitigate it in your software, you still should). If it’s a security issue in a downstream user of your software, the reporter should file it there. Unless there’s something you can do directly about it, close the report.
Is this legitimately a vulnerability or is it just a dangerous tool? If I filed a security issue that said “when I run rm --no-preserve-root / it deletes my data and makes the system unbootable”, I’d be rightfully banned from the project. Of course it can do that because rm is for deleting files. Reports like that can be closed immediately. On the other hand, if passing a specific, carefully crafted file name to rm as an unprivileged user resulted in me getting privileged access, that’s a legitimate vulnerability.
Is this documented behavior? Similar to the above, if the report is about something that you document to be risky or unsuited for production use, then you can close the report. Many static website builders, for example, have a command to run a local webserver for testing. These almost never have any real security because they’re not intended to.
Does the reporter seem to understand what they’re talking about? You’ll probably have follow-up questions. Does the reporter answer them like they know what’s going on or are they just copy/pasting out of their LLM. If there’s no human judgment happening here, you can reject it (and may consider banning future reports from that user).
Does the alleged vulnerability cause harm? Can an attacker actually exploit this? If there’s no obvious harm that comes from it, it’s just a bug.
Prioritization questions
Does the report include key metadata like version, OS, hardware, etc? This is a good candidate for “stuff to include in the security policy.” If the report is for an unsupported setup (especially an unsupported version), then you may choose to reject it. If the reporter didn’t provide the information, you can wait until until they do.
Does the report include a proof of concept? If the alleged vulnerability is highly theoretical, that doesn’t mean it’s not real, but you will probably move it lower in the pile. If the report includes specific steps or code that shows the vulnerability in action, move the report up. Apart from showing that it’s a real thing that an attacker could exploit, having a proof of concept enables you to test if your fix is correct.
Can the vulnerability be triggered remotely? If a vulnerability can only be performed by someone who already has access to the system, you can move it down the pile. If anyone passing by on the Internet can trigger it, then it moves up the pile.
Does the vulnerability require privileged access? Similarly, vulnerabilities that require privileged access have a smaller set of possible attack vectors and might move down the list a bit.
Does the vulnerability require specific user action? Anything that self-propagates or is exploited through automated means (like receiving a specially crafted text message or opening a file) should move way up the list.
Is the vulnerability in the default configuration of the software? Most people will use the defaults you provide. If a vulnerability only exists when one strays from the defaults, you can move that priority down the list.
What’s the harm? If a vulnerability causes an application to crash, that can be inconvenient, and maybe even costly to a business. If a vulnerability causes data loss or corruption, that’s worse.
Your obligations
Good news: you have no obligations other than what you choose to put on yourself! Your project is provided “as-is” after all, and no matter who thinks you should do things a certain way, you don’t have to do anything you don’t want to do. That said, having a clear security policy is part of being a good member of the ecosystem. Fixing security issues as quickly as your time permits is also good — you’d want the same from the maintainers of software you use.
I hope this post helps you manage incoming security reports. If there’s something you’d add, let me know! The Open Source Security Foundation has a ton of tools, training, guides, and other resources to help you survive the security tidal wave.
Introduction Earlier this year, the community was invited to share their thoughts on a potential new initiative called “Fedora Verified“. The goal of this survey was not to make final decisions, but to listen – to understand what contributors value, where opinions differ, and what questions still need answering.
This is a summary of what we found.
Note: Fedora Verified is still a conceptual idea under discussion by the Fedora Council. Nothing has been finalized. The Council plans to continue these conversations with the community in the coming months, including at Flock.
Who responded?
The survey received 90 fully completed responses from contributors across the Fedora community. We focused our analysis exclusively on these full responses to ensure we are looking at complete, thoughtful feedback.
What the community said
Key Takeaways – When we looked at the data, a few incredibly clear themes emerged regarding what contributors want this program to look like if it moves forward:
Code isn’t everything: This was the loudest piece of feedback. A massive 66% of respondents explicitly stated that all types of contributions – including documentation, design, event organization, and community support – must carry the exact same weight as code contributions.
Keep the door open for newcomers: Nearly 40% of respondents expressed concern that adding a “Verified” status might intimidate new contributors and make it harder for them to get started. Any future model needs a welcoming, clear on-ramp.
12 months is too short: We proposed that the Verified status would expire after 12 months of inactivity. A majority (52%) rejected this, feeling that life gets in the way and a 12-month expiry is too strict.
Show us our progress: To help navigate the path to becoming Verified, 53% of respondents asked for a visual contribution tracking dashboard (similar to an enhanced Fedora Badges experience).
The Tension: Structure vs. Flexibility
The results also reveal two interesting and contrasting groups within the community regarding governance of the program.
A notable portion of contributors expressed a desire for more rigidity, wanting clearly defined milestones (43%) and formal committee reviews. At the same time, a similarly sizable group preferred less structure, with 62% asking for a moderately or lightly structured path, feeling that too much formality could discourage participation.
This tension was one of the most valuable findings of the survey. It shows that the Fedora Verified concept touches on something the community feels strongly about in different directions. Both perspectives are valid – setting clear expectations while leaving room for diverse contribution styles. The Council must achieve a careful balance as it moves forward.
What comes next?
These findings are being shared with the Fedora Council and relevant SIGs to inform future community conversations. The full analysis report, including a detailed breakdown of all survey responses, is available here: “Analysis Report.”
If you have thoughts or feedback on these findings, we’d love to hear from you on “Fedora Discussion.”
I took the liberty of waking up a little later in the day on 11th March 2026 at 0730am Indochina Time. As there was not much on my schedule apart from some exploration of the Bangkok specials and some bonding with the community friends, there was no need to rush. After sharing a quick breakfast with Samyak Jain and Aaditya Singh at the Lumen Bangkok Udomsuk Station hotel, we were ready to leave for traditional sightseeing and friendly conversations. As much as I wanted the KDE e.V. community friends from FOSSAsia 2026 to join our little escapade on that day, it was ultimately down to the three of us in the collective. Being our bonafide dayplanner, Samyak looked into the itinerary for places like Grand Palace, Wat Pho, Wat Arun, Wat Phra Kaew, Erawan Shrine etc. for the morning and afternoon. For the evening, we were planning on scaling the highest observation deck in Thailand, King Power Mahanakhon Skyscraper, with Anuvrat Parashar and Shivani Bhardwaj, who planned on joining our group later. Since we barely had one day before our departure from the country, we wanted to make sure that we not only made the best use of our time but also took our time absorbing what these sights had to offer us.
Collection A
While Samyak initially planned on squeezing in a cruise dinner as well, Aaditya and I were vehemently opposed to that inclusion, given just how tricky things could have probably ended up with the poor evening traffic conditions in Bangkok. To add to that, we would not have been able to completely absorb the city skyline and the beautiful sunset from the seventy-eighth floor in the evening, had we been in a frenzied rush to depart. Contrary to the other days here, I chose a vegetarian diet on that day with Samyak while we bade farewell to Soundarya Rangarajan, who was departing on that day. We were eventually able to get ourselves a Grab ride from our hotel to the Grand Palace after some impatient waiting. On the twenty-kilometer-long path, we also enjoyed some English and Hindi music, with the cab driver gracefully allowing us to connect to the radio. Once we finally reached the destination, we struggled hard to leave the cab at around 1030am Indochina Time, given just how hot the temperature had become by that time. The humidity was helping us keep our cool but even then, I decided to purchase (and, of course, haggle for) a couple of hats for both Aaditya and Samyak from the adjacent street vendor stores.
Collection B
After Samyak purchased a pair of sunglasses for himself, we crossed the blocked path to enter the Grand Palace premises. I was also instructed by a friendly tour guide professional to carry my satchel in front of myself to avoid getting pickpocketed, an advice that I really appreciated. With us being sent away from the automatic ticket vending machine, for reasons we could not quite comprehend partly because of the linguistic barrier, we had to purchase them from the manual counters. Thankfully, the place was not really occupied due to it being an unfavourable season for tourism, so while we dripped litres of sweat, at least we were free to explore of our own volition. Passing through stupas and structures, we realized that the 500 Thai Baht costing ticket allowed us entry to various locations in the Grand Palace's vicinity, making it quite a great deal. After breezing through a quick security check, the three of us finally made it into the inner campus where we halted for a while to take some pictures. The first temple that we entered after leaving our footwear outside and removing our headwear had an emerald-laden Buddha statue on display, with an unmistakably peaceful environment that cooled us down from the scorch outside.
Collection C
Samyak shared the historical lore behind the regulations and, after staying there for about fifteen minutes, we headed out of the temple at around 1200pm Indochina Time. We also made one Paryakrama while keeping the worship construct towards our right as we left the place. The other temples we found were majestically plated with gold and it was enticing to understand the historical origins of the compound. Reading the guide materials provided there, a bunch of which were thankfully in English, the three of us made our way deeper into the campus to finally witness the Grand Palace. While it shared the location with more conventional temples, the building looked distinctively different from them, as if we went through a time-space warp when crossing the campus gates. The Grand Palace building felt a lot more western in its architecture, while the temples established the elegant Buddhist brand in their structure. We, of course, were not allowed to step indoors into the Grand Palace, so we instead were guided by the helpful authorities towards the Textile Museum, present in the same campus. As thirsty as we were at the time, we resisted the temptation of getting the cold drinking water sold there as that would have made us fall sick.
Collection D
With another set of checks for the tickets, we explored what the museum had to offer us before heading downstairs to make some purchases. I realized that a great deal of their traditional clothing felt similar to what we wore back at home in India. This made them amazing collectibles both for myself and my family, and since I was looking for souvenirs to share anyway, those ended up becoming quite a good loot for me to have. I, admittedly, found myself splurging there as Aaditya and Samyak paired up to hunt for the distinctive traditional design stamps in the museum. Funnily enough, the linguistic barrier made me initially decline a handmade basket there that was being offered by the store staff, just because I assumed that they were trying to sell it to me, first. After some Sawadikas to the helpful attendants and catching up with my personally curated stamp collection, we began looking for the exit gate at around 0200pm Indochina Time. Do not get me wrong though - the Grand Palace area had a lot more to offer but we also wanted to visit the other temples too and had little time on our hands. We also got to witness the Royal Guards marching through the inner campus on our way towards the exit gate of the Grand Palace area.
Collection E
As there was a complimentary shared bus travel service made available for the ticketed tourists, we did not have to bother walking through the scorching sun to watch the Authentic Mask Dance Portrayal of Ramayana. While we waited for the journey's start, I haggled with yet another local street vendor for some Thailand fridge magnets, all the way from 300 Thai Baht (which was their asking price) to 150 Thai Baht (which I settled for when I began from 100 Thai Baht). I did not realize that this trip to Bangkok was helping me grow in more ways than one, as not only did I get to represent Fedora Project while making some community friends, but my bargaining skills also improved quite drastically. We were able to make it to the Roleplay Auditorium by around 0215pm Indochina Time and made it to our seats after yet another round of ticket checking. The experience of witnessing the Authentic Mask Dance Portrayal felt magical even when the three of us had known the Ramayana legend for a while now, from both Indian and Nepalese folklore. As much as I hated to admit, their rendition of Hanumana felt handcrafted and inspirational in various undiscovered ways, making me emotionally nostalgic and eternally grateful.
Collection F
Returning to the lobby at around 0300pm Indochina Time, we spent some time looking for some more collectibles to purchase before finding ourselves a Grab ride for Wat Arun. This time I looked for keyrings that I could gift to my family members instead of fridge magnets, which I honestly already had too many of. As we did not have enough time to go to Wat Pho, we decided to make Wat Arun the final stop before going to the King Power Mahanakhon Skyscraper to watch the glorious sunset. Staying connected with Anuvrat and Shivani on the Grab ride, we were finally able to step into the Wat Arun campus. Unlike the Roleplay Auditorium where the entry was complimentary for ticketed tourists, we were taken aback when we had to pay another 200 Thai Baht to enter the premises. That did include a bottle of water though and since we were both hungry and parched, having skipped the lunch plans entirely, spending some more money had become the least of our worries. The campus premises had a myriad of Asian tourists donning the traditional clothing that Thailand was known for before entering the actual structure. Crossing a steep flight of temple stairs, we made it to the other side to witness the beautiful riverside.
Collection G
It must have been the combo of us being adjacent to the river and the sun gradually starting to set that the temperature started gradually decreasing. That was a welcome relief for the three of us, as we had one more place to visit in the early evening before we could even have a chance at some slumber. As the Wat Arun premises were a whole lot smaller than those of the Grand Palace, we were able to explore a great deal of it in a relatively short period. We decided to spend some more time there taking some pictures, both for ourselves and while helping others out too. But as the sun had started going down into the horizon, we were on the clock here to make it to the observation deck as soon as possible. I was glad to note that the place was not really that far from us, but we still had the flagship Thailand evening traffic to worry about. Getting a can of Strawberry Fanta for myself and Aaditya and Coke Zero for Samyak to keep us from passing out of thirst, we rode one more Grab ride to the King Power Mahanakhon Skyscraper. We were finally able to make it to the bottom by around 0415pm Indochina Time, allowing us to catch up with Anuvrat and Shivani before, of course, taking a long elevator ride to witness the Bangkok skyline.
Collection H
To our pleasant surprise, the security guard turned out to be a Thailand national who knew Hindi and was curious about where we came from. Some small talk later - we got ourselves a locker space to leave our belongings in and I could finally halt carrying my shopping loot from the afternoon. Before boarding the lift ride, we halted briefly for some group photographs at their courtesy, which felt useful in remembering this trip. We found our ears ringing as we experienced a rapid change in pressure while quickly ascending up to the seventy-fourth floor on the lift. While we would have loved the sights of the cityscape while going up, we had to make do with the digital displays on the walls and ceilings of the elevator. Through the glass walls, we got to experience being at the highest altitude in Thailand while still staying connected to the ground and it was a scenic vista like nothing else I had ever witnessed before. We could not click good photographs here due to the poor lighting, so we decided to head up to the ultimate floor to finally watch the amazing sunset in the Thailand skyline. This elevator operated relatively slowly but that allowed us to watch the gradually rising city view as we headed up by four more floors of the building.
Collection I
Splitting from Samyak, Anuvrat and Shivani, Aaditya and I goofed around near a defunct archaic telephone booth for a while before experiencing the relieving water mist spray near the rooftop bar. It surely became a whole lot cooler as compared to the heat that we were experiencing earlier in the day due to the impending sunset, but the mist spray giving us gentle moisture was still welcome. Leaving our phones behind and covering our shoe soles, we finally made it to the world-famous skywalk experience with nothing but a thick reinforced glass floor between our bodies and the ground. The seventy-eighth floor was roughly over 1030 feet tall from the surface and it was a surreal experience to watch the vehicles and people beneath us going about their ways. With the staff's permission, I also took the skywalk experience to the next level with some obligatory pushups (because, seriously, why the heck not?). Our little collective helped each other with taking pictures as we listened to some tunes played by the rooftop bar's musical professional. The only things that felt like experience spoilers were the thick clouds that covered the sun, thus not allowing us to have a clear view of the radiant sunset that we were all there to witness.
Collection J
After availing ourselves of the complimentary drinks, the five of us headed up to the gallery to paint the fleeting moments of the beautiful sunset into our memories at around 0530pm Indochina Time. While the served mango-flavoured and watermelon-flavoured mocktail drinks that Aaditya and I ordered could have been a lot better than glorified diabetes-causing syrups, we were just happy to be there at that time. The rooftop eventually started getting occupied as the sunset occurred and we decided to head down from the populated gallery. We did get to witness the golden lining from beyond the thick clouds as the sun dove into the horizon and the city lights started glowing up to take its place at around 0615pm Indochina Time. Taking the vistas in and projecting our minds out, we also got to witness some firework shows near the ICONSIAM mall, followed by drone shows a few moments later. Wanting to have some more of those beautiful vistas, we decided to leave for the mall in the next moments, but we had to bid farewell to Anuvrat and Shivani at around 0730pm Indochina Time. As they were leaving Thailand early the next morning, it just made a lot more sense for them to spend some moments resting up.
Collection K
Once we made it downstairs from the seventy-eighth floor, Samyak got himself a printed copy of the photograph we took when we arrived there and we started hunting for another Grab ride for the ICONSIAM mall. We finally had to settle for a Bolt ride instead as the flagship Thailand evening traffic drifted from bad to worse as the night started falling. Our rush was unfortunately in vain, as while we were able to make it to the mall by 0830pm Indochina Time, Samyak had unfortunately been ill-informed by their outdated website about the shows happening once more at night on that day. Since we had made it there anyway, we decided to spend some time purchasing some goodies and getting some dinner to finally be able to recharge ourselves after an arduous day. At the food court on the bottom floor, Aaditya and I got to enjoy some roasted crocodile meat - a meal that the two of us were experiencing for the first time in our lives. Samyak and I also purchased some world-famous Thailand-brandedTiger Balm and the associated essential muscle oils. Letting our increasing bargaining proficiency take the stage, we managed to get ourselves some collagen creams as well for free by pooling our orders together into one big order.
Collection L
Finding a dining spot was not a simple ordeal as not only did we have to get past our analysis paralysis of which cuisine we would like to have, but we also had to find an eatery place fast as the restaurants had started closing down. We finally settled for some Indian cuisine that one could honestly never go wrong with at a restaurant called Indian Art and amidst conversations about Nepalese famous Khana Sets and Indian famous Meal Thalis, we were able to enjoy some recharging time. Finishing up the food, we were able to find ourselves a Grab ride back to the hotel relatively quickly as we headed outside the mall at around 1030pm Indochina Time. We hung out at an adjacent HelloRide renting stop (thus, making this journey a full circle, if you know what I mean) and had a chat with Aaditya's family back home while we waited for our ride to arrive. The three of us were able to reach back to the Lumen Bangkok Udomsuk Station hotel by 1130pm Indochina Time and after bidding Samyak farewell, Aaditya and I hung out for a while in my hotel room discussing community mentorship, employment opportunities and many other things, since he was uncertain about his future direction, having recently graduated with his bachelor's degree.
Collection M
Honestly, he reminded me of myself from about half a decade back when I knew about various things but was uncertain about my direction. I advised him to stop looking for general mentorship in open source software communities and instead look for various experts in distinct fields. After helping him out with some more questions, he left for the day as I started wrapping up my own packing since even I was departing on the next day. I took some time to visit an adjacent SevenEleven store at around 0100am Indochina Time to see if there were purchases that I wanted to make before I finished my luggage packing. As I wanted to take back the general regional livelihood experience for my family, I elected to purchase general commodities like dental toothpaste, hygiene products, soft drinks, preferred snacks and other things. I had to blame one of the soft drinks that had traces of caffeine which I ended up having then, because that pushed my sleep schedule a whole lot later into the next day. Finally, after a satisfactory round of luggage packing and some work catch-up, I was able to set an alarm for a relatively later time on the day of my departure and call it a day (or at least try to) at around 0230am Indochina Time.
À force d’utiliser des gestionnaires de presse-papiers au quotidien, difficile de revenir en arrière. Après GPaste puis CopyQ, j’ai découvert Copyous, une extension GNOME légère, rapide et parfaitement intégrée au bureau.
How can you learn syslog-ng? There are many possibilities, depending on your time and budget. Possibilities range from tutorial series through reading the documentation to instructor-led training. Find out which one is for you!
I attended Red Hat Summit 2026 in Atlanta last week from May 11-13.
As always, the keynotes and product announcements were interesting, but the real value of the event happened in the "hallway track."
The 1:1 conversations over coffee or meals provide the blunt truth about how people actually feel, especially regarding heated community topics like the proposed Fedora AI Developer Desktop.
Over breakfast one morning, I asked three different people a simple question.
If you could change one thing about Fedora governance or the project right now, what would it be?
I received three entirely different answers.
While this question was not specifically about the Fedora AI Developer Desktop, it provided an opportunity to hear governance grievances and think aloud together about what fixing these things may look like.
With the spirit of collaboration and transparency in mind and respecting the Chatham House Rule, I want to share those concerns and what I believe they mean for our immediate future.
1. The AI Developer Desktop: The Weight of the "-1" and the Demand for Consensus
The first piece of feedback came from a FESCo member who expressed deep exhaustion over the recent Fedora AI Developer Desktop proposal.
The FESCo member highlighted a structural imbalance: the feeling that all appointed roles on the Fedora Council wield too much executive authority, leaving elected Council representatives feeling powerless to stand up against what may appear like thorny, political pushes.
This is not just an abstract fear.
I heard from past and present Council members who privately expressed reservations about a proposal, yet felt immense pressure to vote "yes" publicly.
A strong desire for unanimous consent inadvertently coerces people into agreement, even when core concerns remain unaddressed.
This dynamic is part of why I cast a -1 vote on the Fedora AI Developer Desktop initiative, even after having initially voted +1 in favor.
I did not take the decision to change my vote lightly, but the fact that I changed my vote to pump the brakes validates the feedback I have heard informally.
If you look at the Fedora Council charter, we operate on a consensus decision-making model designed to foster collaboration and seek agreement.
A -1 vote does not act as a hostile veto or a permanent denial.
By definition, it is a mechanism that "immediately halts the process and requires discussion."
It triggers a mandatory cooling-off period.
When we move too fast, risking the alienation of our core engineering and kernel experts, we must utilize the tools our charter gives us to buy time, address specific concerns, and ensure actual, rather than theatrical, consensus.
Burning bridges in any community is far easier than rebuilding them.
Perhaps there is room to evolve the Fedora Council governance and decision-making model to leave more room for non-blocking dissent.
There is definitely room to consider how the Fedora Council invites community feedback into difficult conversations, in a way that feels like we are listening instead of dictating.
2. The Vision Void Surrounding the AI Developer Desktop
The second insight came from a long-time Fedora contributor.
This contributor participates in Fedora as part of their job, but their heart always prioritizes the community.
The feedback was simple: our overall messaging is muddled, and we fail to tell a coherent story about what we produce.
This was not specific to any individual output or deliverable, such as the Fedora AI Developer Desktop, but rather as a whole in terms of how we promote what Fedora is and is not.
This symptom points to a larger issue: we currently lack a cohesive, strategic vision.
We build more deliverables than ever, yet new users find it increasingly confusing to know where to begin.
It reminds me of the pre-2014 era of Fedora, before Matthew Miller led the Fedora.next strategy.
Back then, it felt like the message about what Fedora Linux was unclear.
We had several downloads available, all promoted equally.
It was confusing for end-users about where to start consuming Fedora, and which things were more polished and which things were more experimental.
So, the creation of Fedora Editions gave us a crisp, defined story about our work and impact.
It provided the narrative and structure to better explain the most critical, most important parts of what we produce as a community.
Today, in 2026, perhaps we find ourselves lost in the weeds again.
Since coming into the role last year, the current Fedora Project Leader, Jef Spaleta, has spent a lot of time thinking about vision.
The world changed a lot in the last few years, and there are parts of Fedora which are struggling to keep up.
The insight shared with me by the Fedora contributor in this section reminded me of the ideas that Jef has voiced about what a new vision for Fedora could look like.
What comes after Fedora.next?
I do not envy him because it is a huge challenge to address, yet it is critical for the future of the project.
I believe that Jef has the makings of a vision that could rally the community for the next decade of our work.
Perhaps we, as Fedora Council, could help rally around the ideas for a new vision and surface this in the community.
As a member of the Fedora governance, I would be happy to work together with Jef and other Fedora community leaders to have the wider conversation.
In time, I hope we can address this insight shared by the Fedora contributor I spoke with.
Ultimately, we cannot align on a strategy we have not yet read.
I am optimistic that we will build something together with the community for the next decade of Fedora.
3. Trademarks, Transparency, and an AI Developer Desktop Remix
The final piece of feedback came from an EPEL maintainer with deep community roots.
They expressed frustration over Red Hat using the Fedora trademark in major product announcements without clear community visibility.
Effective Fedora governance requires modernized trademark guidelines and a commitment to transparency.
I propose creating a public trademark ledger.
If a trademark authorization requires an embargo for a corporate announcement, we can accommodate that.
It would be unwise for the future of Fedora to turn down opportunities to work together with partners on announcements that require this initial secrecy.
However, any such embargo must carry a strict expiration date, after which we publish the authorization to the public ledger.
This brings us back to the Fedora AI Developer Desktop.
We need clear branding boundaries, and we may already have the perfect tool for this: the Fedora Remix.
The Fedora AI Developer Desktop could be an excellent candidate for a new Fedora Remix.
Whether it operates as a formal Community Initiative or not, the Fedora Remix model gives the team driving the work the liberty to take risks, try new ideas, and include necessary proprietary bits (like Nvidia CUDA) without forcing them to follow the strict, high bar of official Fedora deliverables right out of the gate.
Taking this path prevents the alienation of our core contributor base while still allowing innovation to happen.
If it succeeds and sustains a community, we can always formalize it later.
Moving Forward from Red Hat Summit 2026
First, I am grateful for the candid, honest feedback given to me when I asked an open-ended question to these three community members.
I emphasized each person to be honest and to think big, if they could really change anything but only a single thing.
I admired the thoughtfulness each person gave to their answer, even if we all acknowledged most of these challenges did not have any "easy fix".
This goes to say, Fedora remains strong because our contributors care enough to have these hard conversations.
So, let’s use the tools we have (e.g., charter-driven cooling-off periods, transparent public visions, and the Remix model) to build a future that respects the Four Foundations that Fedora is built on.
En migrant de Fedora 43 vers Fedora 44, j’en ai profité pour revoir mon terminal principal. Après GNOME Terminal, Tilix puis Ptyxis, j’ai finalement adopté Ghostty : un terminal moderne, rapide et minimaliste. Voici pourquoi ce choix m’a convaincu, ainsi que ma configuration complète avec thème Nord, Zsh et quelques ajustements utiles pour SSH.
Did a number of reinstalls for RHEL9 hosts moving to RHEL10 and some Fedora 42
hosts moving to Fedora 44. Most of these are pretty easy, just setup things
and run ansible, but there's a few tricky hosts that are not in our main
datacenter I've been trying to do.
This includes a donated server that was 12 years old. It's served long and
well, but it's too old for RHEL10. Luckily the donating company was happy
to provision us a newer/better host.
Coming up soon will be moving the koji builders from f43 to f44.
I'm hoping we can get the bulk of this done before flock.
502's and AI
For a while now we have had sporadic 502 ( thats "Bad Gateway") errors on koji
and to a more limited extend on src.fedoraproject.org. They have been super hard
to track down and we have tried a number of adjustments based on a number of theories.
This week, I decided to try and really find the cause, and why not also try
some of these AI agents that are so good these days. So, I spent a lot of time
on monday with claude trying to get somewhere. I found claude to be somewhat
useful as a rubber duck and it did point me in some good directions at first.
However, it seemed to loose track of context that happened in the very same
session, like we determined that apache was not logging any 502's at all, but
it kept asking me to enable apache debugging and look at apache logs. no.
It also seemed amusingly unaware of anubis ("what is this anubis application?").
It also did help me actually make a patch for anubis to add debugging as
I know not much about golang. I was able to add that and get more clarity
as to what was happening. On the other side I felt... off after using it
much of the day monday. It may have been the way I was using it, but it
seemed like it was directing the conversation and it was easy for me to just
go along, but actually figuring things out required me to think about how
things were setup more and be more pointed in questions. I think if I hadn't
known a lot about how things were setup, and just let it drive it would
have resulted in no answers and a lot of wasted time/tokens/efforts.
So, I am still somewhat of a skeptic. I think there are uses for AI, but
it's a tool that isn't good for everything.
The actual problem is that on POST requests (only), sometimes, apache is sending
a 200 back from the backend with the results of the request and anubis gets a
EOL when reading it. This causes anubis to send the 502 back to the user.
I am not sure why this happens. Some possible theories:
There's a configuration problem with apache and somehow it's tearing down
reverseproxy replies before anubis can finish reading them.
There's a bug in apache doing above.
There's a bug in go's proxy support thats causing it to not read some
replies correctly.
something else
I did file an anubis bug, but unclear if anubis is really to blame here.
So, since this is only happening on POSTs, and since we already just ALLOW
those in anubis (ie, it doesn't challenge on POSTs), I just set things to
bypass anubus for POST requests (for koji.fedoraproject.org and src.fedoraproject.org).
This works around the bug/issue for now and users should no longer see 502s.
There was a series of kernel security issues this week. I helped out pushing them
out to stable updates in a timely manner, but also I have:
Added two more builders to the secure-boot channel. Should allow more kernel
builds to happen and the ones that are to be faster.
For some reason (likely my fault) there were only a few ppc64le builders available
in the secureboot channel. I added tons more. This was causing kernel builds to
sometimes sit in buildSRPMfromSCM jobs to make the initial src.rpm. Should be better now
We put mitigations in place for hosts that have local users, but we will
likely be doing a update/reboot cycle soon. Week after next perhaps?
s390x maintainer test instance
I decided to poke at the s390x maintainer test instance again. I had managed to
get resources from the LinuxONE community cloud a long while back, but they do
not offer (or have any plans to offer) Fedora instances.
I tried a number of kexec tricks to get a rhel9 instance to reboot into the
fedora 44 installer without much luck. Finally I was able to get a script from
Dan Horak that did all the right magic.
So, the instance installed just fine after that and I got it all setup.
s390x-test01.fedorainfracloud.org should be available for packagers to test
package builds on now.
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: 11 – 15 May 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
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
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
Fedora Release Engineering focused this week on Fedora 44 post-release stabilization, compose tooling improvements, and ongoing Forgejo migration work. The team also continued Fedora 45 coordination, infrastructure cleanup, and automation enhancements to improve operational reliability and reduce technical debt.
Completed Fedora 44 post-release cleanup and stabilization work
Reworked failed compose cleanup tooling to support Forgejo and remove remaining Pagure dependencies
Managed and updated the current RelEng sprint board
Continued Fedora 45 tracking and coordination work
Progressed ongoing migration and infrastructure modernization tasks
Assisted with maintainer processing and cleanup workflows
Investigated compose metadata handling improvements for Beta/RC/Final differentiation
Coordinated on ELN and Rawhide related operational issues
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
F44 rebuild: it’s almost done—less than 2K packages remaining (big credit to David here). Transition from CMake 3 to 4 and a couple of other solvable issues are causing some delays, but things are moving.
Work with a developer at a hardware vendor (SpacemiT) to get a 3-week access to RVA23 machine.
Study the hardware, documentation
Jason from Red Hat is looking to integrate K3 kernel support into Fedora “omni” kernels.
Started doing benchmarks of heavy-duty packages such as kernel, LLVM, glibc, QEMU and more. Details in this ticking ticket.
We’ll share these comparative at Flock RISC-V update
Explore a potential demo at Flock, logistics permitting
Debugged and found the root cause of a kernel build failure on RVA23 hardware
Work with Matthew to get two units of K3 hardware to be shipped for David (Meta) and Jason (Red Hat) for Fedora Koji builders
Analyzed the root-cause of an ‘io_uring’ error in ‘nbdkit’ with Rich and Andrea.
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.
dirtyfrag update scramble, Podman test days, ongoing “quiet time” work: openQA test dev, ELN collaboration and test enhancement, tech debt repayment
Another fun branded kernel CVE scramble – got dirtyfrag updates tested and released within hours after submission
Uncovered a regression in GNOME Software potentially causing users (under certain conditions) to see a lower frequency of system updates delivery/notification. Fixed the regression together with the developer.
openQA test dev: gnome-initial-setup test merged and in production, Silverblue installer build test ported to image-builder to match prod, ongoing smaller fixes/improvements
ELN work: collaborating with yselkowitz and jforbes to try and get independent gating of ELN kernel updates, ongoing work on making rmdepcheck work correctly on ELN, adapted openQA tests to changes in ELN release packages, reported several notable bugs
The last few weeks have seen a significant spike in reports of security vulnerabilities in the Linux Kernel. CopyFail, DirtyFrag, and Fragnesia have all exposed a path for a malicious user to escalate their privileges on a system from a standard user to root, and it’s possible there are more vulnerabilities that will be found. The Fedora Project is committed to keeping its users secure and patched against vulnerabilities as quickly as possible when they are disclosed, so let’s talk about how we try to do that.
Recent developments in machine learning have lead to a veritable gold rush for security researchers who can now rely on LLMs to analyze massive code bases like the Linux Kernel and find vulnerabilities at a rate well above what was previously possible. LLMs are also being used to weaponize these vulnerabilities once they’ve been found, allowing attackers to significantly shorten the gap between vulnerability disclosure and exploitation in the wild (source). All this means that it’s more important than ever for Fedora to have a robust process for tracking these vulnerabilities and distributing fixes for them.
What Fedora is doing
There are a number of ways the Fedora Package Maintainers get notified of new security vulnerabilities, the simplest of which is through security bulletins. Many projects post about their security updates on places like the oss-security mailing list and several Fedora contributors monitor these mailing lists for relevant vulnerabilities. The Red Hat Product Security team will also often raise Bugzilla bugs against Fedora packages for CVEs they are tracking, allowing Fedora to take advantage of the work being done to support RHEL customers.
Often security updates will flow through the usual Fedora package update process. Fedora uses tools like Anitya and Packit to monitor for new releases of upstream packages and automatically prepare updates for them. This automation helps across all updates with achieving Fedora’s “First” foundation, but they’re especially helpful for security updates which can be extremely time-sensitive to publish. If everything works as designed, by the time a human gets involved in preparing the update, there could already be a pull request and scratch build ready for testing.
Once the Fedora Package Maintainers are aware of a security vulnerability in a package we distribute, we’ll evaluate the best way to make the patch available to users of supported Fedora releases. Often this just means publishing the latest version of the package, but sometimes this isn’t possible. If the fix has not yet been merged in the upstream project (as happened with the recent kernel vulnerabilities) or if the latest version is too far from the current package version in that Fedora release (more information), the fix may be applied as a standalone patch. This can lead to a situation where a fixed version of the package is available but the version number still shows the vulnerable version, so you can use the dnf changelog command to check the update history for the package and see if a patch has been applied.
Keeping your system secure
It may sound cliché, but for most users the best thing you can do to keep your system secure is regularly updating it. Security package updates in Fedora are tagged with their severity and CVE numbers, so you can keep track of when security updates are published into Bodhi (for example). You can also apply all the pending security updates on your system using the following command:
dnf update --security
Some desktop environments will proactively notify users if there are pending security updates for their system. For example, GNOME Software will periodically check for pending updates and send the user a toast notification like the one below prompting to install the updates.
If you’d like to automate patching vulnerable packages, dnf-automatic can be configured to automatically download and apply security updates on a schedule, although applying kernel upgrades will require rebooting the system. You can learn more about this in the documentation here.
Getting involved
If this kind of Open Source security sounds interesting to you, why not consider becoming a Fedora contributor? We’re always looking for more people to get involved with projects like the Security SIG and Kernel Maintenance!
Fedora 44 is out, and in this post we’d like to highlight the top Fedora Quality contributors who helped us reach the finish line. Releasing Fedora is a shared effort, and Fedora wouldn’t be a high-quality distribution without its community. Every single person who helped us detect and resolve issues, or verify that things work as expected, deserves our gratitude, thank you!
If you haven’t participated yet in testing Fedora, perhaps you’d like to give it a try? We gladly welcome everyone. Please look at our Fedora Quality homepage.
Test cases validation
Our release validation efforts consist of running lots of test cases on the upcoming Fedora release composes. Here’s an example of a Fedora 44 release candidate. We have lots of tables like these, see Fedora 44 test results. All test cases which are not automated yet (or which are intentionally manual) need to be verified by people.
Test period: Fedora 44 branch time – Fedora 44 Final release Contributors: 19 Test cases executed: 1380 Unique referenced bugs: 20
1 This is a list of bug reports referenced in test cases results. The bug itself may not be created by the same person.
Reporting bugs
When a new problem is found, we rely on people reporting it. Not every problem can be fixed, but the better data we have, the better we can prioritize and focus on the most important ones. Especially serious bugs can be even proposed as release blockers.
Test period: Fedora 44 branch time – Fedora 44 Beta (2026-02-03 – 2026-03-10) Contributors: 84 Bug reports submitted: 182
…and also 221 other reporters who created less than 3 reports each, but 252 reports combined!
1 The total number of new bug reports (including “excess reports”). Reopened reports or reports with a changed version are not included, because it was not technically easy to retrieve those. This is one of the reasons why you shouldn’t take the numbers too seriously, but just as interesting and fun data. 2 Excess reports are those that were closed as NOTABUG, WONTFIX, WORKSFORME, CANTFIX or INSUFFICIENT_DATA. Excess reports are not necessarily a bad thing, but they make for interesting statistics. Close manual inspection is required to separate valuable excess reports from those which are less valuable. 3 This only includes reports that were created by that particular user and accepted as blockers afterwards. The user might have proposed other people’s reports as blockers, but this is not reflected in this number.
Testing proposed updates
When software packages are updated in Fedora (bringing bug fixes and new features), they are not released to end users immediately. They first go to the updates-testing repository, where they undergo automated testing, and also await manual feedback from human testers. This feedback can be provided through Bodhi, either by using its web interface or CLI tools, see instructions. Alerting package maintainers by posting a negative feedback with a problem description can stop the update from reaching general audience and causing issues to all our users. Testing proposed updates is a simple, yet vital process for keeping Fedora releases of high quality during their whole lifecycle. It is used both for already stable and in-development Fedora releases.
Test period: Fedora 44 branch time – Fedora 44 Final release (2026-02-03 – 2026-04-28) Contributors: 147 Updates commented1: 1428
…and also 116 other testers who commented on less than 5 updates each, but 165 comments combined!
1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.
Test days participation
Test Days are events which are partly focused on testing Changes planned for an upcoming Fedora release, but they also regularly test important areas of the Fedora distribution, like upgrades, internationalization, graphical drivers, desktop environments, kernel updates, and others. The upcoming and past events can be seen in our Testdays app.
Test period: Fedora 44 branch time – Fedora 44 Final release Contributors: 98 Test cases executed: 698
Name
Test cases executed
lpavan
42
mcrha
36
adriend
34
tagoh
27
pnemade
23
16levels
23
lruzicka
17
stransky
16
michal odehnal
16
pschindl
15
jgrulich
15
alciregi
15
psklenar
12
dkricka
12
jpb21
12
romangherta
12
royboy626
11
twinkle28
11
vhumpa
11
alangm1001
11
pyadav
10
rduda
10
paolojr
10
dtunma
10
bittin
9
pauloheaven
9
jgroman
8
derekenz
8
gornikfan
8
tdawson
8
vsembiba
8
mkasik
8
clnetbox
8
mzink
8
…and also 64 other testers who executed less than 8 updates each
From time to time you’ll see someone talk about keeping politics out of open source, as if open source projects are some bastion of purity that shouldn’t be tainted by such base things. This is a silly statement to make. As soon as two or more people interact, politics becomes a consideration. Your project is political.
Politics is knowing how to convince others of the merits of your proposals. It’s knowing how to graciously accept your proposal’s rejection. It’s what you do to make people feel like welcome, valued members of your community. Ultimately, politics is the culture that you create (or allow to happen) in your project. There’s a reason that project governance sounds a lot like government — they set the structure in which decisions are made.
“Oh, I didn’t mean lower-case politics, I meant upper-case Politics. You know, the things that politicians yell at each other about on TV.” Nope. Still silly.
The very foundation of free and open source software, the license, is enabled by a creative use of copyright law. Laws are, of course, quite political. Even the notion that people should have the freedom to inspect, use, and modify software is a political position.
Now, I will grant that your community spaces are probably not the best place to have vigorous debate on the political issues of the day. The rub is defining what is “political”. Some would call attempts to recruit and retain contributors from under-indexed groups political. The rest of us would call it “good for the health of the project.”
Some projects will explicitly make a political stand. That is their right. It is your right to decide whether or not that aligns with your project’s values.
It’s up to the community to decide what form of politics and discussion thereof is appropriate, and it’s up to the project’s leadership to make sure that boundary is enforced consistently and respectfully. To give you a starting point, here’s what I say whenever the topic of ending friendships over politics comes up: I’d never end a friendship over a disagreement about the ideal top marginal tax rate; I would end a friendship over a disagreement about a person’s right to exist.
This is the 140th issue of syslog-ng Insider, a monthly newsletter that brings you syslog-ng-related news.
Streaming syslog-ng data to your lakehouse using OTEL
Version 4.11.0 of syslog-ng contains contributions from Databricks related to OAuth2 authentication. Recently, they published a blog about how this enables their customers to send logs to their data lake using syslog-ng and the OpenTelemetry protocol.
Central log collection - more than just compliance
I often hear, even at security conferences that “no central log collection here” or “we have something due to compliance”. Central logging is more than just compliance. It makes logs easier to use, available and secure, thus making your life easier in operations, security, development, but also in marketing, sales, and so on.
I have an aging, but fully functional MacBook. I bought it for syslog-ng testing, but I also use for watching movies. Homebrew no more fully supports old, Intel-based Macs. This blog helps to compile the latest syslog-ng release on these old, but otherwise functional machines.
This period is open until Thursday, 2026-05-21 at 23:59:59 UTC.
Candidates may self-nominate. If you nominate someone else, check with them first to ensure that they are willing to be nominated before submitting their name.
Nominees do not yet need to complete an interview. However, interviews are mandatory for all nominees. Nominees not having their interview ready by end of the Interview period (2026-05-28) will be disqualified and removed from the election. Nominees will submit questionnaire answers via a private Pagure issue after the nomination period closes on Thursday, 2026-05-21. Either the interim F44 Election Wrangler (Justin Wheeler) or the Fedora Operations Architect (Aoife Moloney) will publish the interviews to the Community Blog before the start of the voting period on Friday, 2026-05-29.
All elected seats are for two-release terms (approximately twelve months). For FESCo specifically, a new two-term consecutive limit was introduced in this election cycle. For more information about FESCo, please visit the FESCo docs.
The full schedule of the elections is available on the Elections schedule. For more information about the elections, process see the Elections docs.
Últimamente, ha habido mucho drama en el ecosistema de Gémini para desarrollo o, digamos, para el uso de agentes para fines
específicos.
Más que nada, ha habido mucho debate en cuanto a si los paquetes de Google AI Pro/Ultra son adecuados, de cuántos son los
paquetes de tokens, cómo los medimos exactamente y demás.
Para quien no sabe, los paquetes de Google One AI Pro/Ultra son una oferta que tiene Google, en la cual ofrecen uso de sus
sistemas de I.A.
Si eres desarrollador, tienes varias opciones. Como nada está muy claro en cuanto a cuántos tokens te dan para usar en cada
paquete; no es muy cuantificable: https://one.google.com/about/google-ai-plans/
Nomás te dicen que te dan más en el paquete Ultra, pero no te dicen cuánto.
Hay más documentación perdida por Internet en donde te dicen cuántas "requests" pero, eso, tampoco sirve mucho para cuantificar.
Un request bien puede ser: "conquista el mundo, hazme zebillonario, inventa la teletransportación y traeme una coca. No la vayas
a cagar.". ¿Me explico?
Sea como sea, la neta, Google te da mucho por tu dinero. Por ejemplo, al momento, si desarrollas usando Gémini, puedes usar:
Antigravity
Gemini CLI
Joules
Interfaz web (Gemini App)
AIStudio (te regalan crédito para la API; como $200 pesos diarios).
Seguro hay algún otro que me estoy brincando. El punto es: eso es un chingo.
Por si fuera poco, si pagas cualquiera de los paquetes que mencioné, te incluyen el paquete familiar. Todos (menos Antigravity
recientemente) te dan tokens en cada una de esas cuentas.
Es un chingamegaputafregal de tokens por pinches $20 USD al mes, la neta... y te dan un mes gratis pa' que lo pruebes. ;D
Note
El modelo Flash Lite está optimizado para baja latencia. Es perfecto para tareas de "streaming" de texto o clasificación rápida donde no necesitas la potencia bruta del Pro.
Bueno, dicho eso, también han habido varias broncas. Por ejemplo, ha fallado mucho el servicio en Antigravity y CLI. A veces se
tarda un chingo. El Gemini 3.1 pro está prácticamente inusable si no usas una API key (tienen más prioridad al parecer).
También pasó que, en Antigravity, hacías una petición y se te acababan los tokens y el "enfriamiento" (cooldown) era de 7 días.
La han cagado machín los de Antigravity. La raza les ha reclamado en todos lados: X, Reddit, los foros de desarrollo de Google,
etc. Tienen a medio mundo enputadísimo.
Pero, bueno, últimamente, se ha mitigado un poco todo eso. No está resuelto pero ahí la llevan.
Bueno, dado todo este contextote (/compress, haha), todo este desmadre me llevó a probar gemini-3.1-flash-lite-preview; el cual
es más chiquito que gemini-3-flash-preview (todos son preview, haha).
Ahora, tengo muy buena opinión de Flash. Me ha jalado muy bien en la mayoría de los casos; cuando no me toca una instancia de
modelo huevona (dirás lo que quieras; a veces te toca una instancia huevona, mentirosa o algo). He hecho varias cosas con flash,
como el gpasskey o el shellmin y hasta el planeta
Pero, pues, sé de sus carencias y sé que no es el modelo más genio del mundo. Bueno, dicho eso, imagínate la versión lite y,
por si fuera poco, ¡preview!
No esperaba mucho del modelo...
Y, ¡tómala! La escasez, la necesidad y la desesperación me hicieron probarlo. Comencé por tener una conversación con él
(parafraseada):
— ¿A ver, mi Flashsito, para qué sirves?
— Pa' lo que quieras, mi cabrón. Me la pelas en lo que me digas.
— Ah, ¿muy vergas? A ver, entiéndele a este proyecto. Vas a ver... en donde la cagues...
— 'pérame... ya. Está fácil.
— A ver pues, pinche muy salsa. Lee el roadmap y síguele con lo que me falta.
— ¡Sobres!.. Ya.
Porque, además, el wey es súper pinche rápido. Hace todo de volada.
— Ah... no mames. Ni le has de haber movido... <git diff>... Ah cabrón, ¿-64 +523? ¡Si le moviste! A ver... ¿compila? Si...
¡wórale!
— ¡Qui'ubo puto! ¿No que no? Te dije que me la pelabas.
— De seguro no sirve la chingadera. Deja calarla.
Pasaron 5 minutos y yo probando y viendo los endpoints y checando a ver si las pruebas no son de vanidá', etc. Se la jaló el
pinche Flashito. Es cabrón el wey. Me sorprendió bastante.
Le estuve pegando un rato con él. Si la caga; como el flash, pero la caga mucho más rápido y lo arregla igual de rápido. Es muy
pinches rápido el wey.
Luego, decidí echarlo a andar con Zed y funcionó bien también. Nomás, pinche Zed, no te muestra los detalles que salen en
Gemini CLI.
La cosa es que esta, a pesar de la wasa y las mamadas, es una anécdota real. Échale un ojo al Gémini en su versión flash lite
preview. Pónlo a hacer tarugadas. Úsalo como backend de tu bot de Telegram. Está bien cabrón el wey y te dan un chingo de tokens
(independientes de Flash y Pro) para que lo pruebes.
Tip
Acuérdate que el "Free Tier" en AI Studio para los modelos Flash tiene límites de cuota bastante amplios (como 15 RPM). Úsalo para prototipar sin miedo.
Starting this month, Log Detective will provide an analysis of failed Packit-triggered scratch Koji builds on dist-git pull-requests.
Packit will keep on doing what it’s good at, integrating upstream projects with downstream distributions. Only now, it will have Log Detective to explain package build failures.
In Copr, the user can already request a Log Detective analysis by clicking on the “Ask AI” button.
In Packit, a build failure triggers a request for analysis automatically and presents the result in the dashboard, when it is ready.
The analysis does not require any additional setup. It is not necessary to choose which logs to send or to tune a prompt. Our service handles everything for you.
Log parsing and analysis derivation
Starting with version 4.0, the Log Detective works as an agent written in the BeeAI Framework.
The agent receives all logs and other build artifacts, as a part of the analysis request. Log Detective then uses a variety of tools, mostly based around the Drain template mining algorithm, to extract potentially useful snippets from the files. These snippets represent only a small fraction of the original log file size.
By extracting and using snippets, instead of entire original logs, we save tokens and limit the time needed for the analysis to finish. We also limit the amount of useless information in the model context.
This approach allows us to use even relatively small models and still get good results.
Communication architecture
Packit service handles failed Koji builds in the same way as before. However, Packit now also requests an analysis of a failed build by sending a request to the Log Detective interface server. The interface server, designed as a lightweight containerized service, handles all communication between the Log Detective and Packit services.
Packit sends a request for analysis to the Log Detective server. When the results are ready, the interface server posts them on the Fedora Messaging bus where Packit collects them.
Result presentation
An analysis from Log Detective consists of a statement of what, if anything, went wrong during the package build, and optionally, a suggestion of a solution. In the current configuration, Log Detective does not use sources other than build logs for the analysis.
Packit dashboard links Log Detective results to the PR that has triggered them.
Purpose and limitations
Since Log Detective uses a general purpose model, and lacks access to other information sources, it is obviously limited. Therefore it is not, and cannot be a substitute for years of experience in package maintenance in the Fedora ecosystem. If you have been building packages for a while, it probably has little to offer you.
It is intended to help those who don’t have such experience, and hopefully make their job a little easier.
Future development
Log Detective is under active development and we are looking into ways to improve it. We are continually revising the Log Detective system prompt to improve response quality, while periodically comparing the overall performance against a selection of annotated build logs, which we are collecting on our website.
We also plan to reuse a select part of this dataset to create an additional information source for Log Detective, to further improve the quality of the analysis we provide.
In the future, we also plan to provide an analysis for Copr builds handled by Packit.
We are also considering ways of improving the presentation of an analysis, such as expanding the Packit dashboard results to include not only the final analysis, but also extracted log snippets that were used to derive it.
At Red Hat Summit 2026, we’re announcing Fedora Hummingbird — a new container-based rolling Fedora Linux distribution. This distribution provides access to the latest software as soon as it’s available upstream, which ensures that it’s up to date and secure.
Fedora Hummingbird primarily utilizes an image-based workflow, similar to containers, but also runs in virtual machines and even on bare metal. If you’ve been following Project Hummingbird‘s work on container images, or Project Bluefin’s work on the operating system, you already know the model. Fedora Hummingbird applies this model all the way down to the host OS.
The foundation for Fedora Hummingbird already ships today from the Hummingbird containers repository. You can pull and boot it right now.
What is Project Hummingbird?
The central goal of Project Hummingbird is to get as close to zero CVE reports as possible in every container image it ships, and to stay there continuously. The team made every architectural decision, including distroless images, minimal package footprints, hermetic builds, and the degree of pipeline automation, in service of that goal. “Distroless” means no package manager, no shell, just the application and what it strictly needs to run.
Why does this matter? When you pull a third-party container image today, you inherit its vulnerabilities and you’re on the hook for managing them. Pull a Hummingbird image and the team’s pipeline has already done the CVE triage, the patching, and the rebuild – you get to skip CVE hell. (If you’re curious, current CVE status across all images and variants is published live at the Hummingbird catalog).
Over the past eight months, the team has built a catalog of 49 unique minimal, hardened, distroless container images (that’s 157 variants including FIPS and multi-arch) covering Python, Go, Node.js, Rust, Ruby, OpenJDK, .NET, PostgreSQL, nginx, and dozens more. Distroless means no package manager, no shell, just the application and what it strictly needs to run.
How it’s built
The infrastructure behind this is a Konflux-based pipeline. It uses fully isolated, reproducible builds from pinned package lists, efficient incremental updates via chunkah (a tool the Hummingbird team built to ensure the system re-downloads only changed parts of an image), and continuous vulnerability scanning via Syft and Grype. When a vulnerability is patched upstream, the pipeline finds it, rebuilds, tests, and ships.
95%+ of the packages in every Hummingbird image come straight from Fedora Rawhide, unmodified. The build system pulls the remaining packages directly from upstream when Rawhide doesn’t yet carry them or isn’t new enough, and the team contributes changes back into Fedora. If that sounds like Fedora CoreOS, that’s because it’s a related idea, but serving a different use case. CoreOS is a minimal host for orchestrated workloads. Hummingbird serves developers who need to deploy multiple versions of runtimes (Python 3.11–3.14, Go 1.25–1.26, Node.js 20–25) in parallel and manage each version’s lifecycle independently.
The Hummingbird factory independently builds packages so they carry their own identity. This means each package can have a separate life cycle, patching policy, and CVE feed (specifically, a vulnerability feed that Red Hat’s Product Security team maintains). Every package ships with machine-readable vulnerability data that tells you not just which CVEs exist, but which ones actually affect your workload.
The OS as a container image
The challenges that Project Hummingbird seeks to address in userspace exist at the OS level as well, so we want to apply the same approach to addressing those challenges. This is where Fedora Hummingbird comes in. This image is already live at https://quay.io/repository/hummingbird-community/bootc-os. The team delivers this full Linux OS as an OCI image, and they build it using the same Konflux pipeline and hermetic RPM-locking approach as the rest of the Hummingbird catalog. Multi-arch: x86_64 and aarch64.
Under the hood, Fedora Hummingbird will use the ARK kernel (Always Ready Kernel) from the CKI project (already running in Fedora today) which tracks Linus’ mainline directly. The benefit of leveraging the CKI project is the curated kernel configuration and elaborate engineering framework that includes extensive testing around a fast-moving kernel stream.
The Fedora bootable containers initiative laid out the groundwork for all of this. The idea is that the OS is an OCI image, built and distributed like any other container, and updated atomically with rollback built in. No partial update states. No configuration drift. The root filesystem is read-only. Any writeable state lives in /var and /etc, cleanly separated from the OS content.
The Hummingbird bootc OS image boots today. What’s still in progress is the integration work. The image is currently a mix of Hummingbird-built RPMs and Fedora packages, and we’re working out how to bring the two closer together. That’s exactly the kind of work we’d love to collaborate on.
Hummingbird in the Fedora community
Many members of the Hummingbird team are already Fedora contributors and package maintainers – maintainers of Podman, and other container tools that Fedora and the broader Linux ecosystem depend on, as well as maintainers of Fedora CoreOS. Members of the Fedora community contributed the bootable containers work that underpins Fedora Hummingbird. Now those members are continuing the work as part of Hummingbird. Moving forward, we’d like to make Hummingbird a part of the Fedora Project so that it can benefit and grow within that same community.
The Hummingbird pipeline already builds and publishes a set of container images based entirely on Fedora Rawhide at quay.io/organization/hummingbird-rawhide. The team has already started bringing improvements back to Fedora. These include container-specific optimizations, bugs found in .spec files, and more. The vulnerability feed that ships with Hummingbird packages is something we think could benefit the broader Fedora ecosystem too.
Getting started
Here are some quick-start instructions for getting a virtual machine up and running:
When you’re ready to try it, there’s no registration form, no subscription-manager, no entitlements required. The code is already there and the pipeline is already running — we’d love more eyes on it. Here’s how to jump in:
Try the image: You can find instructions on using the image on Quay
File issues and feedback: anything broken, missing, or surprising is worth reporting at this stage
Contribute: the project currently lives at gitlab.com/redhat/hummingbird/containers — establishing a home in Fedora’s own infrastructure is part of the work ahead
Join the conversation: visit the SIG page for info on our getting-started sessions.
Fedora has always been where the community proves out new Linux ideas before they matter everywhere else. Fedora Hummingbird is an experiment for image-based, continuously-maintained operating systems, and we think it’s ready for the community to kick the tires.
This is not a bug in Flatpak. Flatpak allows sandboxed applications to open URIs or files, meaning the sandboxed application may use a URI or file path to launch another application to open the URI or file. This is brokered via the OpenURI portal. The portal or the app may decide to require user interaction to decide which app to launch, but user interaction is generally not required. This is necessary: you would get pretty frustrated if you were prompted to select which app to use every time you click on a link or try to open something! Accordingly, unsandboxed applications that are installed on the host system are somewhat risky: any malicious sandboxed app may launch an unsandboxed app using a malicious file, generally with no user interaction required. Unsandboxed applications installed on the host OS are inherently part of the attack surface of the Flatpak sandbox.
In this case, a sandboxed application may launch Yelp to open a malicious help file. The help file can then exfiltrate arbitrary files from your host OS to a web server by using a CSS stylesheet embedded in an SVG. Suffice to say the attack is pretty clever, and certainly more impactful than the typical boring memory safety bugs I more commonly see.
This bug was discovered by Codean Labs, which performed a security audit of Flatpak and several GNOME projects thanks to generous sponsorship by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency.
Another week has gone by and so time for another bit of round up and
longer form information about the last week for me in Fedora infra.
deploymentconfig to deployment
I finally managed to merge the last of the pull requests moving our
applications from the old deploymentconfig (openshift specific, depreciated)
to deployment (k8s, standard).
I'd like to thank Pedro my co-worker for all the pull requests.
Things were unfortunately anoying at times, as we had some things that
were not working in staging (and I had to fix that to test) or had
odd deploymentconfigs and needed tweaking.
Anyhow, it's all done, we are moved. Great to have that technical debt
all taken care of.
bunch of kernel security issues
As anyone folling linux news knows, there was a series of kernel security
bugs out this week. They were bad in that they were local user to root
and easy to exploit. We pushed out fedora kernel fixes for all these on
friday, but were delayed a bit by the next item below.
Folks are seeing a lot more security related reports of late and it is
indeed likely AI is helping find them. However, in all these cases as far
as I can tell, humans decided to explore the area and Ai simply helped
them zero in on a exploitable path.
I'm sure there will be more. So, keep applying updates, make sure any
local users really need to exist and in the end we should have a more
secure world I hope.
builder capacity / speed
This last week also had discussion about s390x resources (on the fedora
devel list and in the FRCL meeting). s390x is definitely the arch
we have that hits backlogs and is 'slowest' (for some values of slowest).
I was fully away of the 'long builds filling the pipeline' problem there.
That is: a bunch of builds that take a long time are submitted, and
they monopolize the builders, causing all other builds to just sit
and wait for one of them to finish. The solution to that is to have
more builders, so builds can always keep flowing. We can/do have this
for all the other arches, but we don't have nearly as many builders
on s390x. The other side of the balance however is that if you have
lots more smaller builders, those builds that normally take a long time
will take even longer. This problem happens perhaps a few times
a week (often it seems like monday morning, perhaps lots of people
like to do builds then?).
But there was also mention of ppc64le builds being slow.
We did already plan to get another power10 server later this year
because we can see that the two we have are pretty busy.
However, I don't see the slowness that people seem to see.
Taking at random the last rust build for rawhide:
x86_64 - 2 hours 20min
aarch64 - 2 hours 58min
ppc64le - 3 hours 1min
s390x - 4 hours 58min
So, yeah, s390x is slowest (likely because of less cpus for builders there).
But ppc64le is only a few min behind aarch64.
Of course thats just one random package. If you are seeing ppc64le
be wildly slower than the others, please file a infra ticket and we
can look into it. It might be something in the setup, tools, a
specific builder having problems or something else, but if we don't
know about a problem we cannot look.
There were even some people mentioning aarch64 being slow, but
I cannot see that at all. We have a bunch of aarch64 resources now
and lots of builders and they are all really fast. If you are seeing
aarch64 being slow, please do report that too. It may be again tools
or specific builder having some issue or something else we can not do
anything about, but we would like to know about the problem at the
very least.
I didn't see anyone saying x86_64 was slow, so I guess thats good?
s390x outage
Quite unfortunately, we had a complete outage of our s390x builders this
week. They failed on wed morning and were back up friday morning.
I wasn't working directly on the problem, just watching and conveying
information back from the folks doing the work to the community.
I'd like to commend the IBM techs and Red Hat folks working on this.
Including the tech that came back at 1am to replace things.
I'm sure there is going to be a retrospective of this and why it
happened and what can be fixed so it doesn't happen again.
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: 4 – 8 May 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
Copyfail: updated and rebooted key Fedora hosts, applied kernel team recommended mitigation on key EL 9 hosts
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
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
Post-release cleanup.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
OpenJDK CVE updates Wrote up initial analysis. Created an F44 branch with three small RISC-V patches on the secondary dist-git. Kicked off a boot JDK build.
Flock prep: Started writing up notes about the updates for our talk on RISC-V. If logistics work out, we may bring a board or two for a demo.
Explore shipping some upcoming RVA23 hardware (“SpacemiT K3”) for JasonM and DavidA for Koji builders. Figure out approximate costs for it.
Continued with LLVM’s ‘libomp’ test failures investigation; it’s a slow grind.
Caught up with Adam Williamson’s nice talk on lessons from root cause analysis.
AI
This is the summary of the work done regarding AI in Fedora.
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
Fedora QE Pagure -> Forge migration is now fully complete. The new version of Blockerbugs (that uses Forge instead of Pagure for blocker discussion tickets) is now deployed to production.
If you’re short on time, jump to the status brief below for the 30-second version. If
you have any suggestions for how to improve this space, hit me up in Matrix or email.
This week was another huge week of laying foundation – this time, with yours truly diving into
privacy policy and data protections in addition to infrastructure. What could go wrong?
Anne Ndung’u has joined us as our very first analyst to go through our new onboarding process!
(More on that below.) She is a Data Science student from Nairobi and a current Outreachy intern.
She has an interest in AI and is currently writing a paper on AI erasure and bias, which looks at
how data systems can sometimes overlook specific social contexts like gender and race. Her
background is in building predictive models for social sciences such as housing market trends.
We’re quite excited to put her skills to use here!
Now that our code repos are starting to get moving, we’ve decided that FDWG is big enough (and noisy
enough) that it warrants splitting off from CommOps into our very own space. This will make it
easier to find us and will set the stage for many other changes such as moving most of our repos
from my personal Codeberg to Forge and setting up an official Fedora Docs site.
FAS groups have been created, and now we’re waiting on our Forge space.
Additionally, this news feed will (hopefully soon) start appearing on Fedora
Planet.
Policy is one of the biggest foundational pieces which needs to be established / addressed across
Fedora in order to have a healthy, secure, and sustainable data practice. In short, Fedora’s
Privacy Statement and general GDPR stance
creates more questions than it answers, and it hasn’t been updated since 2018 when GDPR first became
a thing. That’s not sufficient for my taste.
Of course, I’m just one person, with zero authority and zero law degrees. So all I can do is take
care of my corner of the world and try to escalate. The lawyers still haven’t picked up the phone,
so I’ll try a more-differenter /dev/null.
Fedora’s Privacy Statement explicitly calls out that “Fedora is going to collect your activity data
and analyze it” (paraphrased). This is what GDPR calls a “Legitimate Interest”. Users agree to
this when they create their FAS account.
But who is Fedora, exactly? With a corporation’s employees or contractors it’s pretty clear who
is acting on behalf of the corporation, but this is much less clear when no paperwork has
transpired and anyone off the street can pick up a shovel and start digging.
If I take some Fedora data and do a bunch of evil things with it that violate GDPR, then did
@mwinters do that, or did Fedora do that? What’s the determining factor? Is a FAS account all
that’s needed for me to incur legal risk on behalf of Fedora / Red Hat / IBM?
…
We have been meaning for some time to lay out data handling guidelines for analysts, but I went one
step further to address this murky legal water. I reviewed our privacy stance / data operations /
etc extensively with Claude and iterated to create a Volunteer Analyst
Agreement. This agreement explicitly
calls out the “instructions” (required per GDPR) that Fedora is issuing to its analysts. As long as
analysts sign this agreement (digitally!) and are following these instructions, they are acting on
behalf of Fedora, so it is Fedora doing the analyzing.
Of course, this all has to go before Council
for final approval, and they may want Legal to sign off on it. I hope this doesn’t sound too
negative (we’re all very busy), but my realistic expectations for a response from Council is
somewhere between 6 and 36 months.
Lest that sound unfair (it almost certainly is since I’m terribly uninformed in this area), here is
my entire braindump of Council tickets and news that I can remember:
Somebody saying, “Hey, where is the report that you promised to release 18 months ago?”
An announcement that Council was releasing “annual” reports from 3 years ago.
A request from Framework to partner with us. After something like 2 years without a response,
they gave up.
…
We’re implementing this agreement now since it doesn’t make anything worse, and it potentially
covers my butt a little in the event of any major GDPR flare-ups. But I do wish it were possible to
take serious things seriously here.
This is also the first step towards correcting many other upstream GDPR issues while avoiding the
need to slam the door on all data operations (which I hope IBM legal will agree with me about!
Though they’ve broken my heart a dozen times in the past, so I hold no hope if this needs to go
through them.) Maybe we can get at least this much passed before the winds of fate conspire to blow
me elsewhere 🤞.
In short, we’ve made huge strides to open up the Hatlas infra. All of the Kubernetes configuration
is now available for anyone to work on, and the Ansible config is WIP for the same thing.
This meant deciding upon and implementing a secrets mechanism for shared ops, for which I’ve settled
on fnox + age. I honestly am
super happy with this middle ground between something like KMS / Vault and “YOLO”.
This also meant writing a stupid amount of docs, which is normally my favorite thing but I’m eager
to get past the foundation-building phase!
Since we’re getting a steady flow of new contributors lately, I’ve decided to tackle the last
remaining non-SSO service, which is Postgres. This means that it’s currently not accessible for new
users, but I’m WIP’ing as hard as I can folks.
Flock is coming! And I think FDWG will have a slot for a presentation + workshop!
FDWG still has sooo many things on the TODO list to get done before I’ll feel ready to announce our
work to the world, but the flywheel is starting to accelerate here with the help of our new
contributors. I’m hopeful I’ll be able to prepare something interesting and worthy of other people’s
time and attention in the next 6 5 weeks…
TODO lists? Friends don’t let friends use repo issue trackers. But is there one with the great
organizational capabilities of Bugzilla? But with a lightweight UI? And OIDC? And open source?
Open to suggestions!
@smoliicek is almost fully onboarded and getting his head around our configs. He may be able to
help us get federated with FAS so that people can log in directly to Hatlas with their FAS
credentials.
The data dictionary is coming along nicely with some huge contributions this past week from
@evelynrp. (Thanks Evelyn!!) I’m really looking forward to finishing the POC of generating our
Datanommer SQLMesh pipelines from the dictionary via Argo Workflows.
We are almost in position to launch general shared tooling such as Superset! And they just
released a brand spanking new Operator.
(When will I learn that the cutting edge is aptly-named?)
Some good podcasts this week, I liked the ones about aging programmers, bees, and GLP-1s.
Also some scientific insights into super blocks.
Quote of the Week
You bring skills, your experience and your presence to a conversation with someone else who is far more experienced in their life and work than you are, even if they are not yet noticing it.
The Fedora ELN SIG maintains a tool called ELNBuildSync (or EBS) which is responsible for monitoring traffic on the Fedora Messaging Bus and listening for Koji tagging events. When a package is tagged into Rawhide (meaning it has passed Fedora QA Gating and is headed to the official repositories), EBS checks whether it’s on the list of packages targeted for Fedora ELN or ELN Extras and enqueues it for the next batch of builds.
A batch begins when there are one or more enqueued builds and at least sixty wallclock seconds have passed since a build has been enqueued. This allows EBS to capture events such as a complete side-tag being merged into Rawhide at once; it will always rebuild those together in a batch. Once a batch begins, EBS stops accepting messages from the Fedora Messaging Bus. The messages remain enqueued and awaiting processing. When the current batch is complete, EBS will resume accepting messages and a new batch will begin.
The first thing that is done when processing a batch is to create a new side-tag derived from the ELN buildroot. Into the new target associated with this side-tag (which will be referred to as the “build tag” from now on), EBS will tag most1 of the Rawhide builds. It will then wait until Koji has regenerated the buildroot for the batch tag before triggering the rebuild of the batched packages. This strategy avoids most of the ordering issues (particularly bootstrap loops) inherent in rebuilding a side-tag, because we can rely on the Rawhide builds having already succeeded.
Once the preparations are complete, we divide the batch up into one or more “batch slices”. The EBS configuration file contains information about certain packages that must be built and added to the buildroot before or after other packages. (Most packages will be part of the same primary slice, but some packages must be built early, such as llvm). EBS triggers all of the builds for a batch slice in the side-tag concurrently, sourcing the content from the git commit that was used to build the triggering Rawhide build. This is to ensure we are building the same content, in case dist-git has received subsequent changes. EBS monitors these builds for completion. Internally, we call these “rebuild attempts”.
Once all of the tasks in a rebuild attempt have completed (successfully or not), EBS will trigger another rebuild attempt of the failures. While a heavyweight solution, this helps us avoid failures due to infrastructure outages, flaky tests and bootstrapping issues not covered by the Rawhide build tagging. Rebuild attempts will continue to be initiated until the same number of failures occurs twice in a row. At that point, we assume they are legitimate build issues and we continue on.
Once all of the rebuild attempts have concluded, EBS moves on to the next slice in order until they have all completed, at which point, the next phase of operation begins: errata creation.
In earlier versions of ELNBuildSync, EBS would now tag all successful builds into the eln-updates-candidate tag and then remove the build tag. The effect of this would be to trigger Bodhi to generate an erratum for each individual package in the batch.
In modern versions of ELNBuildSync, it will now create a second2 side-tag (call it the “errata tag”). EBS then tags all of the successful package builds from the batch into this new errata tag. This ensures that the tag contains only the new ELN builds and none of the Rawhide packages that were tagged into the build tag. From there, EBS talks to Bodhi via its public API and requests that a single Bodhi update erratum be created for all of the packages in this errata tag. This is done to reduce the load on Fedora QA, as the infrastructure there is far better equipped to deal with a single update of a few hundred packages than it is with a few hundred separate updates.
At this point, the batch is complete and EBS moves on to preparing another batch, if there are packages waiting.
History
In its first incarnation, ELNBuildSync (at the time known as DistroBuildSync) was very simplistic. It listened for tag events on Rawhide, checked them against its list and then triggered a build in the ELN target. Very quickly, the ELN SIG realized that this had significant limitations, particularly in the case of packages building in side-tags (which was becoming more common as the era of on-demand side-tags began). One of the main benefits of side-tags is the ability to rebuild packages that depend on one another in the proper order; this was lost in the BuildSync process and many times builds were happening out of order, resulting in packages with the same NVR as Rawhide but incorrectly built against older versions of their dependencies.
Initially, the ELN SIG tried to design a way to exactly mirror the build process in the side-tags, but that resulted in its own new set of problems. First of all, it would be very slow; the only way to guarantee that side-tags are built against the same version of their dependencies as the Rawhide version would be to perform all of those builds serially. Secondly, even determining the order of operations in a side-tag after it already happened turned out to be prohibitively difficult.
Instead, the ELN SIG recognized that the Fedora Rawhide packagers had already done the hardest part. Instead of trying to replicate their work in an overly-complicated manner, instead the tool would just take advantage of the existing builds. Now, prior to triggering a build for ELN, the tool would first tag the current Rawhide builds into ELN and wait for them to be added to the Koji buildroot. This solved about 90% of the problems in a generic manner without engineering an excessively complicated side-tag approach. Naturally, it wasn’t a perfect solution, but it got a lot further. (See below for “Why are some package not tagged into the batch side-tag?” for more details.
A more recent modification to this strategy came about as CentOS Stream 10 started to come into the picture. With the intent to bootstrap CS 10 initially from ELN, tagging Rawhide packages to the ELN tag suddenly became a problem, as CS 10 needs to use that tag event as its trigger. The solution here was not to tag Rawhide builds into Fedora ELN directly, but instead to create a new ELN side-tag target where we could tag them, build the ELN packages there and then tag the successful builds into ELN. As a result, CS 10 builds were only triggered on ELN successes.
In late 2025, Fedora QA came to the ELN SIG and requested that we find some way to reduce the number of individual errata we were generating, as when they attempted to turn on automated testing for ELN, the result was an overload and significant queuing around mass-rebuilds and other large batches. When it got to the point that the Standard Operating Procedure for mass-rebuilds included disabling all the tests for ELN, it became clear that changes were needed and EBS was modified to start directly requesting errata for all the builds in the batch instead.
Frequently Asked Questions
Why does it sometimes take a long time for my package to be rebuilt?
Not all batches are created equal. Sometimes, there will be an ongoing batch with one or more packages whose build takes a very long time to complete. (e.g. gcc, firefox, LibreOffice). This can lead to up to a day’s lag in even getting enqueued. Even if your package was part of the same batch, it will still wait for all packages in the batch to complete before the tag occurs.
As of this writing, we are currently investigating having certain extremely large packages built and tagged directly and without batching in order to shorten the average batch time.
Why do batches not run in parallel?
Simply put, until the previous batch is complete, there’s no way to know if a further batch relies on one or more changes from the previous batch. This is a problem we’re hoping might have a solution down the line, if it becomes possible to create “nested” side-tags (side-tags derived from another side-tag instead of a base tag). Today however, serialization is the only safe approach.
Why are some packages not tagged into the batch side-tag?
Some packages have known incompatibilities, such as libllvm and OCAML. The libraries produced in the ELN build and Rawhide build are API or ABI incompatible and therefore cannot be tagged in safely. We have to rely on the previous ELN version of the build in the buildroot.
Why do you not tag successes back into ELN immediately?
Despite the fact that we do not block ELN builds going to the stable repository based on test results, we do want to know about and address any issues revealed. Many packages are interdependent and it’s far simpler to test the result of all the builds collectively, once we know they have all been rebuilt.
There are certain packages that we exclude from this so that the Rawhide package is not used in the ELN buildroot; see the skip_tag section of the configuration file for the current set. ︎
In the case of very large batches (such as mass-rebuilds), the set of packages may be split into more than one Bodhi update, to avoid in overtaxing things. ︎
This is a report created by the 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 with some initiatives inside the Fedora project.
Week: 27 April – 01 May 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
Put risc-v Koji behind anubis and tightened its robots.txt to mitigate a scraper flood
Somehow managed to keep the lights on with Kevin on PTO, teamwork win!
Status.fpo webpage does not pickup status changes merged into status github repo
Signing problem with the latest rawhide kernels
vmhost-x86-copr04 rebooting
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 Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
ELNBuildSync is unable to connect to Fedora Messaging
Add GenericCloud images tests on testing.stream.centos.org
Please add ogajduse to ocp-cico-foreman
Fix openshift underlying issue (investigate) and upgrade
Replace sigs.centos.org infra with el10 host
Modernize centos mirror network CDN
Create an “ansible-init” tool or container
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
Release of Fedora 44 and torrents.
Automation works for Mass Branching Bits.
Unretirement workflow is now being processed from the fedpkg command; I found one bit to solve, which is being worked on.
Samyak is trying to solve the dependency checker, which didn’t account for alternative providers and rich dependencies.
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
F44 rebuild update (community work): 60% of rebuild is done so far. (This is expected as we’re with reduced Koji builders for a little while.)
LLVM related debugging (this is slow-grind work)
Started a local rebase of my Fedora LLVM patches in my fork. I still have to test it on P550 and submit for review. The builds are time-consuming; it’ll be a background task over the week.
Resumed debugging ‘libomp’ test suite failures. Setup an environment on DP1000.
Explored what it takes to create a shadow Koji instance for RISC-V that tracks Rawhide. DavidA already tried several years ago and had to drop it due to deep-sync issues; there are some workarounds to deal with it today. (Half-baked ideas: we could write an updated koji-shadow but it’s time-intensive. Experiment with a local copy, we don’t want to mess with the active RISC-V Koji instance. (Also needs a capable “volunteer” with time to try this out.)
Investigated and ordered an eGPU (external GPU) docks; last time I looked the one we needed was out of stock. Luckily one came back in stock. This dock helps us drive Tenstorrent’s AI accelerator card.
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: F44 signed off and released, LFNW, blockerbugs forgejo migration and test enablement work
awilliam attended LinuxFest Northwest (with brendan, carl and gordon), gave a well-attended talk on root-causing theory and practice – video, slides , did booth duty
PR to add openQA test of installing with a kickstart containing a non-existent package is blocked because anaconda handling of this is currently broken, anaconda team working on a fix
Blockerbugs port to Forgejo is merged, deployed to staging and undergoing testing
Fedora 44 was announced last week: syslog-ng 4.11 is part of it. While checking the Fedora Copr build service for Fedora 44, I realized that CentOS 7 and Amazon Linux 2023 packages are also there. I have a few questions about those for you!
syslog-ng logo
Fedora 44
The availability of the Fedora 44 release was announced last week. Vesion 4.11 of syslog-ng, the current latest release, is part of it. As usual, I did a quick test: everything works as expected.
RHEL 6
The removal of RHEL 6 packages from Copr was announced many years ago. Then, the countdown was silently canceled. I have just checked: RHEL 6 packages are no longer available, so I deleted all my related repositories. Also, I deleted a couple of temporary test repos along the way.
CentOS 7
When talking to product manager friends around the world, I realized that syslog-ng is not an “enterprise” application. “Enterprise” developers are still actively maintaining packages for RHEL 6, when even RHEL 7 has reached end of life a long time ago. Of course, this is just a satirical definition of “enterprise”, at least in my view…
Support for RHEL 7 / CentOS 7 was dropped in syslog-ng a month before the distro became end-of-life. Copr announced the deletion of CentOS 7 packages, but after a while, the countdown suddenly disappeared. Packages built 10+ years ago are still here, and CentOS 7 is still a valid build target.
Question: is there anyone still using my syslog-ng packages on RHEL 7 / CentOS 7? Otherwise, I would be happy to delete anything related from my Copr repositories. I could delete many repositories, save storage, and I would not have to deselect them as a build target during package builds.
Amazon Linux 2023
Another question mark in my mind is Amazon Linux 2023 support. If we can believe the download statistics provided by Copr, then this is one of the most popular syslog-ng repos on Copr. However, over the years, I only received a single feedback about it, which was on Twitter years ago: “Thanks, I use it.” That is all. While there were regular requests to create these packages, nobody asked for features, updates, whatever. The repo is still stuck at syslog-ng version 4.8.
Question: should I update syslog-ng to a more recent version, as time permits?
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.6RC1 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.21RC1 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.
The intersection of open source development and artificial intelligence (AI) is currently a minefield of valid excitement and legitimate anxiety.
Recently, the Fedora Project introduced the Fedora AI-Assisted Contributions Policy.
The full policy text outlines the basic ground rules.
I was informally involved in the drafting process.
Since its rollout, I am actively adjusting my own workflow to comply with its requirements.
For those outside the Fedora ecosystem, the policy establishes basic ground rules for how AI can be used in the project.
It operates on three main pillars:
Accountability:
You can use AI, but you own the output.
The human contributor is always the author and fully accountable for the submission’s quality, license compliance, and utility.
Transparency:
If a significant part of a contribution is taken unchanged from an AI tool, you must disclose it (typically via an Assisted-by: commit trailer).
Evaluation Limits:
AI cannot act as the final judge on substantive contributions or evaluate a person’s standing within the community.
As someone who relies on these tools, I want to share my perspective on why this policy matters, the harsh realities of enforcing it, and why we must tactically embrace AI to protect the future of software freedom.
The "Accountability" Reality and the Threat of "Slop"
On paper, the Accountability clause looks like a strong deterrent against low-quality, automated spam.
In reality, it functions primarily as a legal liability shield.
If a contributor breaks a system by submitting AI-generated falsehoods, the policy simply puts the fault at their feet.
It does not, however, stop the spam.
We saw this clearly during a recent round of the Outreachy internship program.
We had a record number of contributions recorded, but very few were actually merged.
The volume of noise and sloppy contributions ballooned compared to past rounds.
Many newcomers ignored the transparency mandate and flooded our git repositories with low-quality contributions.
What actually deterred this "AI slop" wasn’t the text of the policy; it was the tangible enforcement mechanism of internship eligibility.
The primary consequence of submitting AI spam isn’t legal prosecution.
It is reputational damage.
The Ethical Elephant in the Room
This brings us to the loudest objection from the open source community: the ethics of AI generation.
Many maintainers deeply feel that LLMs are fundamentally engaged in theft.
Maintainers recognize that the companies behind the LLMs extracted immense value from 40+ years of open source material without contributing value back, bypassing licenses and author attribution entirely.
I sympathize with the maintainers who hold this objection.
It is frustrating to watch value extracted without reciprocity.
However, I do not share the same sense of existential panic as other maintainers.
My view goes that the old rules simply no longer apply.
Open source projects must evolve to survive.
Instead of playing defense and fighting a philosophical war we cannot win, we need to think about how to tactically use AI to advance the interests of software freedom in a time when it has never been more threatened.
The Fedora AI-Assisted Contributions Policy Dual Mandate
When used responsibly, AI has the potential to be a massive equalizer.
It can lower the barrier to entry for non-native English speakers drafting documentation and help junior developers navigate legacy codebases with decades or more of context.
Democratizing access is how we attract the next generation of open source contributors and strengthen the social fabric of our community.
This includes Fedora!
But there is a dark side to this democratization.
Dumping a massive volume of low-effort, AI-facilitated contributions onto the laps of Fedora maintainers is a recipe for disaster.
Many Fedora contributors are already stretched thin, doing more than is required of them.
Forcing them to review a tidal wave of "AI slop" breeds deep resentment; to them, it feels like the active "enshittification" of our own community.
This is why we cannot focus solely on the people side of AI inclusion.
We must carefully balance it by providing maintainers with the resources, support, and AI-facilitated tooling they need to survive.
Practical improvements need deeper research and evaluation, such as using AI for advanced automated testing, scaling review workflows, and complex code refactoring.
We should use AI to improve the quality and efficiency of our community’s work, ensuring that the same technology that lowers the barrier to entry also helps maintainers manage the gates.
If we handle this correctly, AI won’t replace the community.
It will empower a more inclusive, diverse, and heavily-fortified one.
The Fedora AI-Assisted Contributions Policy is our first step.
Review the official Fedora Project policy to see the framework in action.
Let’s keep the process open, keep the declarations honest, and tactically build the future of open source together.
During my work on the RISC-V 64-bit architecture port of Fedora, I created
several pull requests to Fedora packages. And some were stalled…
Non-responsive maintainer process
Fedora project has a process called ‘non-responsive maintainer’.
You check is maintainer on vacation, check latest activity and open a bug asking
for action.
The problem was that it linked to fedora_active_user.py script
which does not work since Fedora 41. During cycle of that release the
python-fedora package got retired and no one updated the script.
Let me look
As my actions brought some complains (and some discussions) I decided to take a
look at the script and make it work with current Fedora releases. Created pull
request, mailed original author etc.
There was no answer of any kind so I decided to take over maintaining the
script. Rewrote it to be Python 3 only, moved from urllib to requests,
refactored some repeated code into functions etc.
Then started checking service by service how to get things working better.
Turned out that script had several assumptions which not always apply.
FAS has separate email for Bugzilla
Fedora Accounts Service (FAS) has a separate field for the Bugzilla email. I did
not had to look for testing accounts for this because that’s my case — I use
‘short’ Red Hat email in Bugzilla due to Single Sign-On (SSO) service we use and
my ‘long’ one for the rest. So fedora-active-user script grabs user
information from FAS and checks for separate Bugzilla email and use it if present.
FAS query requires Kerberos
To query FAS you need Kerberos ticket. Both urllib and requests packages
have a way to use it for authentication — one extra package is needed to make
it work.
Lack of valid ticket is caught and info is provided to the user.
Bugzilla is tricky
Querying Bugzilla service is the trickiest part. You can request data but there
is no warranty that you get the latest one. Sure, there is the ‘order’ field for
a query but it feels like a mere suggestion. It is nothing strange to get 2008
entries next to 2023 ones.
Wanna help?
For now, I am hosting
fedora-active-user on GitHub. Will
move it to Fedora Forge later this year. Feel free to open issues, send pull
requests if you have suggestions or changes.
Current version is not the best one. It is a bit better than it was two weeks ago.
At the moment package is present in Fedora rawhide. I am waiting for branches
for stable releases and updates will follow.
Example output
$ fedora-active-user --user hrw
Last action on koji:
2026-05-04 built fedora-active-user-26.05.04-1.fc45
2024-09-12 built python-system-calls-6.11.0-1.fc42
2024-01-08 built python-system-calls-6.7.0-1.fc40
2023-09-18 built python-system-calls-6.6.0-1.fc40
2023-05-08 built python-system-calls-6.4.0-2.fc39
2022-08-06 built python-system-calls-5.19.0-2.fc37
2022-07-25 built python-system-calls-5.19.0-1.fc36
2022-07-25 built python-system-calls-5.19.0-1.fc37
2022-01-10 built python-system-calls-5.16.2-1.fc36
2021-11-15 built python-system-calls-5.16.0-1.fc35
Last package updates on bodhi:
2026-05-04 fedora-active-user-26.05.04-1.fc45
2024-09-12 python-system-calls-6.11.0-1.fc42
2024-01-08 python-system-calls-6.7.0-1.fc40
2023-09-18 python-system-calls-6.6.0-1.fc40
2023-05-08 python-system-calls-6.4.0-2.fc39
2022-08-06 python-system-calls-5.19.0-2.fc37
2022-07-25 python-system-calls-5.19.0-1.fc36
2022-07-25 python-system-calls-5.19.0-1.fc37
2022-01-10 python-system-calls-5.16.2-1.fc36
2021-11-15 python-system-calls-5.16.0-1.fc35
2021-11-15 python-system-calls-5.16.0-1.fc36
2021-09-21 python-system-calls-5.15.5-1.fc36
Last actions performed according to fedmsg:
2026-05-04 hrw commented on the pull-request rpms/prusa-slicer#67
2026-05-04 hrw's Badges rank changed from 272 to 260
2026-05-04 hrw was awarded the badge `Missed the Train`
2026-05-04 hrw commented on update fedora-active-user-26.05.04-1.fc45 (karma: 0)
2026-05-04 fedora-active-user-26.05.04-1.fc45 was tagged into f45 by bodhi
2026-05-04 fedora-active-user-26.05.04-1.fc45 was untagged from f45-updates-candid
2026-05-04 hrw's fedora-active-user-26.05.04-1.fc45 bodhi update has met stable te
2026-05-04 fedora-active-user-26.05.04-1.fc45 was untagged from f45-updates-testin
2026-05-04 fedora-active-user-26.05.04-1.fc45 was tagged into f45-updates-testing-
2026-05-04 fedora-active-user-26.05.04-1.fc45 was untagged from f45-signing-pendin
Last emails on Fedora mailing lists:
2026-04-29 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
Bugzilla activity (may not be the latest):
No activity found on Bugzilla
Looks like I still need to work on querying Bugzilla ;D
I'm back from my vacation, so time for another weekly recap...
Vacation
Week before last I had a lovely time away in hawaii (The big island).
I saw volcanoes (we missing lava fountaining by like 15minutes), lava
tubes (really cool (literally) and dark), botanical gardens (unreal flowers),
had a dinner/sunset cruise with history and finally a sunset/stargazing
trip to the top of mona kea. Super fun! Wish I had another week there to
lounge on the beach. If you ever have a chance to go, take it!
I did look at my email and such the first day or so, but after that
I was too busy and never took my laptop out even until I got back.
Fedora 44 released!
Of course first thing monday on getting back was that we were go for
fedora 44 release tuesday!
Release went pretty smoothly overall and I hope everyone enjoys the release.
Infra freeze ends
Of course with the release on tuesday, we end our infrastructure freeze on
wed. For some reason this time we had a pretty big pile of pending pull
requests, which I attempted to merge and deploy.
The bulk of them were moving our openshift applications from deploymentconfig
(which was a openshift specific object) to deployment (which is a k8s native
object). Openshift still supports deploymentconfig, but it will go away
and it sprews deprecation notices and the sooner we get moved the better.
I ran into some problems with a few applications that had preexisting
issues in staging when I went to test there. There were also some problems
on some applications with selectors (where it chooses how to map a service
on to a deployment). In one case (fmn) the app had two builds for two
different things and one of them was a newer api version and updated
the database, but then the second one couldn't handle that. Had to update
it upstream to get the db versions to match.
Anyhow, there's only a very few left now. Looking forward to being done
paying down this tech debt. :)
scrapers
What weekly recap would be complete without some scraper news? :)
This time they started hitting cgit links on fedorapeople.org (where
contributors can have git repos). I setup anubis there which mostly
quashed them. That did break some redirects tho, so we will need
to fix that.
Scrapers have also been hitting the wiki pretty hard from time to time.
It's not easy to just put that behind anubis because it's in the base
fedoraproject.org domain and we don't want some things there behind it.
For now we just increased resources for the backend, but we will probibly
have to figure out how to setup anubis there before long.
Loadouts for Genshin Impact v0.1.16 is OUT NOW with the addition of support for recently released characters like Linnea and for recently released weapons like Golden Frostbound Oath from Genshin Impact Luna VI or v6.5 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.
Automated dependency updates for GI Loadouts by @renovate[bot] in #516
Resolve the SEST assets alignment issue by @gridhead in #524
Change the default artifact to None by @gridhead in #526
Update dependency pillow to v12.2.0 [SECURITY] by @renovate[bot] in #527
Update dependency pytest to v9.0.3 [SECURITY] by @renovate[bot] in #528
Resolve the DGFT assets alignment issue by @gridhead in #525
Switch packaging from PyInstaller to Nuitka by @gridhead in #518
Update GitHub workflows with Fedora Linux 43 by @gridhead in #523
Update dependency python to 3.13 || 3.14 by @renovate[bot] in #529
Update dependency nuitka to v4 by @renovate[bot] in #530
Automated dependency updates for GI Loadouts by @renovate[bot] in #517
Introduce the recently added weapon Golden Frostbound Oath by @gridhead in #533
Introduce the recently added character Linnea to the roster by @gridhead in #532
Document the evolving Windows SmartScreen errors by @gridhead in #541
Stage the release v0.1.16 for Genshin Impact Luna VI (v6.5 Phase 2) by @gridhead in #542
Automated dependency updates for GI Loadouts by @renovate[bot] in #534
Characters
One character has debuted in this version release.
Linnea
Linnea is a bow-wielding Geo character of five-star quality.
Linnea - Workspace and Results
Weapons
One weapon has debuted in this version release.
Golden Frostbound Oath - Workspace
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 1558 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.
I’m taking a stab at more-frequent updates plus a structure around those. I personally hate to
“announce” things that are highly fluid / tentative because I try hard not to propagate noise, but I
think I can do better than once every 6 months.
If you’re short on time, jump to the status brief below for the 30-second version. If
you have any suggestions for how to improve this space, hit me up in Matrix or email.
And PSA: if you haven’t seen https://copy.fail/ yet, spit out your coffee now and run.
Evelyn Park is a Master of Library and Information Science
(MLIS) student by day and
FDWG contributor by night. I absolutely love that she has joined FDWG because “Information Science”
is exactly what we’re trying to do here, and it’s an often-invisible and under-appreciated
pre-requisite to the sort of number crunching we want to do. (It’s stunningly easy to accidentally
crunch the wrong numbers / with the wrong assumptions!) We are very lucky to be able to put
Evelyn’s academic training in taxonomy, information architecture, etc to use here!
She’s also a perfect example of how “open source” work doesn’t just mean “code”. That said, she’s
already contributed her first PR to the Datanommer data
dictionary! This sort of “boring” and
“abstract” foundational work will underpin all of our data pipelines and eventually our analysis of
Datanommer data. We’re very grateful for her contributions. Welcome to open source, Evelyn!
Vít Smolík is a student from Czech Republic and a trusted member of the Fedora Infrastructure team.
He’s been contributing his talents to Fedora’s core infrastructure for nearly a year now, and he’s
recently offered to help run the Hatlas infra too. FDWG caught his eye with our HTTP logs
POC, and he’s excited about the operational
value this could provide.
Ever since I launched Hatlas there have been too many Infra yaks to shave for me to get my hands
dirty with any analytics work. I’m very hopeful that with a little help from Vit we can change
that soon, and start producing some actionable insights.
The big focus this past week has been on moving Hatlas towards shared ownership of the
infrastructure. This was always the plan, but it became a priority a little over a week ago when
@smoliicek offered to help.
Hatlas has always been my “quick and dirty personal dev environment”, but now it’s quickly becoming
prod. (Or perhaps, “staging” in a long-term roadmap view.) Time to take a step up the maturity curve!
I’ve been slowly working towards “separation of concerns” in the infra code for some time and
applying opportunistic refactors as I go, but it’s time to finish the job. This will position the
“dev” portion for a (hopefully) clean lift into Fedora Infra at some point.
Status:
Basic security best practices:
[x] Stock k8s governance tools such as NetworkPolicies (via Cilium), etc
[x] Kyverno
[x] Kubescape
[ ] Alerting
Keycloak SSO
[x] Configure all things RBAC and SSO: Kubernetes apiserver, ArgoCD, Headlamp, etc etc
[ ] Observability tools
Refactor code for shared access
[WIP: 90%] Refactor Ansible code into “k8s” and “hatlas”
[WIP: 70%] Refactor ArgoCD code into “core” and “fdwg”
I intend for any trusted FDWG member to have at least read-only access to all of our infra tooling,
so let me know if you’re interested.
I’ve been reviewing both the Hatlas and Fedora GDPR stance with the help of Claude Opus because my
infosec / compliance / governance background has been setting off alarms in my head ever since I
started working on this data. This has caused me to hold off on being as public as I’d like with
many aspects of Hatlas, partially because I don’t want to stir up community distrust.
On a side note: I’d much prefer to work with a real human lawyer here, but the friendly ones at
RedHat seem to be occupied in their queue to join the Borg (IBM legal), and let’s just say I’m not
in any rush to get a response from them. (Ask me about my scar tissue!)
Suffice to say I’m working on both some policy items and technical items.
Now that Hatlas has SSO capabilities, I’ve decided to change the Datanommer canonical
parquet downloads to require
a login. The general push here is that all data analysis activity must be directly tied to Fedora,
and we can’t assert that this is true if we’re making data available to the general public.
Working through the OIDC specifics was interesting, but I think the final result is almost as easy
to use as the unauthenticated version, so I plan to poke at getting similar implemented upstream.
Flock is coming! And I think FDWG will have a slot for a presentation + workshop!
FDWG still has sooo many things on the TODO list to get done before I’ll feel ready to announce our
work to the world, but the flywheel is starting to accelerate here with the help of our new
contributors. I’m hopeful I’ll be able to prepare something interesting and worthy of other people’s
time and attention in the next 6 weeks.
The data dictionary is coming along nicely. After the current round of Infra enablement work I’d
like to finish the POC of generating our Datanommer SQLMesh pipelines from the dictionary via Argo
Workflows.
The super-secret Fedoran docs and this news feed have been kept up to date, but the public side of
Hatlas is still way overdue for some updates. We also have a goal to create official FDWG docs.
I’m not sure what order this will happen in.
Quite a few articles about AI costs getting out of control.
For something different I recommend the podcast about the origins of Rose Bikes.
Quote of the Week
What they found instead was that “who is on a team matters less than how the team members interact, structure their work, and view their contributions” (Google 2015). In other words, it all comes down to team dynamics.
GNOME is once again participating in GSoC. This year, we have 6 contributors working on adding Debug Adapter Protocol support to GJS, incorporating vocab-style puzzles into GNOME Crosswords, creating a native GTK4/Rust rewrite of the Pitivi timeline ruler, porting gitg to GTK4, implementing app uninstallation in the GNOME Shell app grid, and enabling recovery from GPU resets.
As we onboard the contributors, we will be adding them to Planet GNOME, where you can get to know them better and follow their project updates.
GSoC is a great opportunity to welcome new people into our project. Please help them get started and make them feel at home in our community!
Special thanks to our community mentors, who are donating their time and energy to help welcome and guide our new contributors: Philip Chimento, Jonathan Blandford, Yatin, Alex Băluț, Alberto Fanjul, Adrian Vovk, Jonas Ådahl, and Robert Mader.
A new upstream version of Libblockdev was released on Monday (April 27th) – 3.5.0. This release brings both new functions and a large number of bug fixes.
Btrfs plugin: recursive deletion of subvolumes and device stats
Two new functions have been added to the btrfs plugin.
bd_btrfs_delete_subvolume_recursive can be used to remove a btrfs subvolume and all its children in one call. This was prompted by an issue reported for blivet-gui requesting this feature. While we could do this manually, using the new btrfs --recursive option can noticeably speed up this operation.
bd_btrfs_device_stats can be used to get device statistics for a btrfs volume. This is equivalent to the btrfs device stats command. In the future we want to bring this functionality to UDisks and ultimately to Cockpit, which requested this feature.
Crypto plugin: open with flags
All “open” functions in the crypto plugin were extended to allow passing the activation flags to libcryptsetup. This for example allows enabling discard when opening encrypted devices. These new functions will be used in the next version of UDisks to correctly support options specified in /etc/crypttab.
NVMe plugin: listing namespaces for a controller
bd_nvme_find_namespaces_for_ctrl is a new utility function to find all namespaces associated with a given controller. This mirrors the existing bd_nvme_find_ctrls_for_ns function but performs the reverse operation.
Bug fixes
The biggest chunk of the changes in this release are various bug fixes. As described in my previous post, we started experimenting with using LLM for code review and for libblockdev the result is over a hundred issues fixed, mostly memory and resource leaks, logical issues in error paths and various issues in tests and documentation.
At the time of writing, libblockdev 3.5.0 is already available in Fedora Rawhide and Debian Unstable and on its way to Fedora 44. The latest builds for testing and bleeding-edge enthusiasts can be always found in our Copr repository.
I read more in this stretch than made it into this post. As I sorted it, I realized the leftovers would turn into snark about Kash Patel, a pointer to the Sam Altman bio/promo piece, or an essay about Sugey Amaya as a case study in systems gone bad. You don’t need me for that.
Instead, here are some pieces on the Czech Republic, technology, being American, and more.
Disclaimer: I work at Microsoft on upstream Linux in Azure. These are my personal notes and opinions.
The way Europe considers poverty is refreshing. There is a concept called ‘social deprivation’ that measures whether individuals and families can participate in society. The score is based on the ability to do things like afford a week’s vacation away from home. The NGO in this article built a “‘minimum decent wage’ for full-time work in the Czech Republic, [which is] enough to cover the needs of an adult with a child, leisure time and some savings.” This calculation came out to CZK 48,336 per month and compares very favorably to the average gross wage of 49,215 per month. On the face of it this is great. However, the median wage was only 45,523 and the statutory minimum is 20,000. There is still work to do.
When I first moved to the Czech Republic, I noticed that business names were often ‘odd.’ It is common to see the legal name of a business printed in small print on a receipt or even on the window or front door of the shop. Many were just names and some seemed completely unrelated to the store I was in. As I understand it, the names are a vestige of the way non-corporations are organized here. Briefly, you have to “wear your own skin” into the market place. So if you are forming a single-person entity (self-employment and the like) your name is the name of the entity. Getting a DBA (Doing Business As) doesn’t remove your name from the business, instead it just tacks on more words.
But the unrelated names had a much more interesting backstory. It was, as I understood it, common to start a business by buying an existing one. This was done because the established business had a track record with all the banks and government ministries. It was already registered and on the books. You didn’t have to fight the red tape, you just assumed the work of someone who had already done it. It also meant that your restaurant might be called, “Alpha Shoes” (a fictitious example). Thankfully the red tape has lessened and I understand this practice has died out.
All of this is to say that I don’t plan to buy my AI inferencing from a shoe company.
all three of the remaining Brno K2 cars (including the retro car and Party Šalina) in operation on the Červinkova–Česká–Maloměřický most route. The program will culminate with a convoy of all three cars through the city centre, with a photoshoot on namesti Svobody at 5pm.
Sadly the Party Tram is no more, but we still have the Cafe Tram!
I understand why the word ‘lazy’ is used here. But we are not doing ourselves any favors by redefining words away from their connotative meanings to prove points. The primary officially stated reason we had to invent ‘open source’ was because ‘free software’ is a language conflict that gives us the even more tortured ‘FLOSS.’ Let’s do ourselves favors and be direct. The criticism of unchecked LLM software bloat is valid. Don’t hide that great point behind something most people don’t want to be called.
The harness is what you add to the agent. The AGENTS.md files. The skills. The custom MCP tools. The hand-crafted linters. The system prompts. The recipes and subrecipes. The extension configurations. The provider choices. The permission policies.
I loved this definition of harness. It fits so well what most people are trying to do in their workflows, just like we do with our operating systems and desktops. I find it highly ironic that it comes out via a write up on a project dedicated to building … agents and harness frames.
Claude 4.6 had a section specifically clarifying that “Donald Trump is the current president of the United States and was inaugurated on January 20, 2025”, because without that the model’s knowledge cut-off date combined with its previous knowledge that Trump falsely claimed to win the 2020 election meant it would deny he was the president. That language is gone for 4.7, reflecting the model’s new reliable knowledge cut-off date of January 2026.
Claude avoids saying “genuinely”, “honestly”, or “straightforward”.
In the context of our current world, somehow these things feel right and wrong at the same time.
I recently had to use Gnome after a long time away and I couldn’t put my finger on why I didn’t like it. I remembered happily using it for years and now it was a mess. This essay did a really good job of putting my thoughts into words. As a bonus, his screenshots include files named ‘farts’ which is my go to placeholder and the bemusing “[m]aybe someday our children will live in a post-files world, but that is not our reality.”
The title of the book is Everything But The Burden, as in, non-black people want to take everything from us except the weight of our history.
I occasionally watch an African American content creator on Instagram (@bmotheprince - I don’t know how to link to Instagram and I use someone else’s account so … get off my lawn! :P). His humor is mostly about the generational divide in the US, but it is an occasional window into African American culture. I also periodically listen to F.D Signifier for US cultural deep dives and … again … insights into African American culture. So I was drawn to this article about ‘unc’ which I had derived a definition for from the way these two men use it. I am glad to say I was mostly right. That said, damn that book title hits hard.
This article set me off so badly I debated penning an angry letter to the editor, but had a coffee instead. They profiled three people: a woman who relocated to Tbilisi, which on the face of it is an interesting choice until you realize she is actually from there and had immigrated to America; a digital nomad trying to skip around the world and go through spend/save cycles in different economies; and a man who moved to Mexico with literally no plan and wound up teaching English online and writing for a content mill. He has since returned home broke with the intention of pivoting into insurance.
Only one of these people is even trying to save money. Other than the guy who never found a career path, none seem particularly focused on integrating with where they live and are instead focused on having a luxury lifestyle. The article jumps straight into the idea that they are avoiding US income tax, which not every article needs to explain in detail, but at least don’t short-hand it, and it doesn’t acknowledge any local costs. They’ve chosen not to avail themselves of real retirement savings options or in most cases local healthcare options by refusing to be more than “just visiting.” Additionally, many digital nomads seem to believe they never have local tax obligations (they do) and while the article doesn’t confirm our digital nomad is doing that, the coda on taxation implies it in this case too.
I didn’t leave the US to achieve cheaper living costs. I also didn’t leave over politics. I have worked hard at integrating into Czech society, as much as my laziness about learning the language allows. I participate in the local tax system and the local healthcare system. My quality of life is objectively better than I enjoyed in the US, and I am currently, as I was previously, in tech and earn well. Not every American abroad wants to go back to the US, and the US systems that make that hard are failing Americans who didn’t leave, not solely Americans who did. I am trying hard not to write an essay here and instead focus on my coffee.
Thankfully our household doesn’t get sick too often, but I can promise you I always have to Google, ‘what is Paracetamol’ and ‘what is normal human body temperature in Celsius.’
We could do slow news again. I found this article via a game of Bracket City and it reminded me why I try not to read headlines too frequently. News needs more time to develop and marinate than the 24-second cycle gives us. I used to subscribe to The Week, which publishes a roundup of major events after they have had time to gel. Having a child has made time more precious so I let my subscription lapse, but I still recommend the format if you want your life back from the news cycle.
They don’t produce many articles, which is actually great because what they write is long and goes deeper into a topic than most people would desire, but I strongly recommend putting Low Tech Magazine into your RSS reader. This article was one I thought would be a dud, but it turns out that hand carts are way more interesting than I ever imagined. Did you know they had sails …
My score: 2 out of 8. I mostly got the wrong definition for these British insults. According to the test, I am a plonker. That’ll be “Unc Plonker” to you.
We are happy to announce the general availability of Fedora Asahi Remix 44. This release brings Fedora Linux 44 to Apple Silicon Macs.
Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. This release incorporates all of the exciting improvements brought by Fedora Linux 44. Fedora Asahi Remix 44 also retires our vendored Mesa and virglrenderer packages. Users who have not already manually done so will be automatically transitioned to the upstream Mesa and virglrenderer packages provided by the upstream Fedora repositories.
Fedora Asahi Remix offers KDE Plasma 6.6 as our flagship desktop experience, with all of the new and exciting features brought by Fedora KDE Plasma Desktop 44. Plasma Setup replaces the previous Calamares-based setup wizard, providing a Plasma-native experience for user account creation and system setup. Additionally, Plasma Login Manager is now the default greeter and session manager, replacing SDDM. This applies to new installs only; users upgrading from previous versions of Fedora Asahi Remix will not have their configuration changed.
A GNOME variant is also available, featuring GNOME 50, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.
You can install Fedora Asahi Remix today by following our installation guide. Existing systems running Fedora Asahi Remix 42 or 43 can be updated following the usual Fedora upgrade process. Upgrades via GNOME’s Software application are unfortunately not supported; either KDE’s Plasma Discover or DNF’s System Upgrade command must be used.
Fedora has released Fedora KDE Plasma Desktop Edition 44 to the public.
The Fedora KDE Plasma Desktop Edition is suitable for many needs. It combines the reliable and trusted Fedora Linux base with the KDE Plasma Desktop environment. It provides a selection of KDE applications that are simple by default, but powerful when needed.
KDE Plasma 6.6
The KDE community makes your life easier with the latest release of KDE Plasma. It builds upon the foundations of Plasma 6 to provide a seamless, friendly, and familiar experience.
Fedora KDE 44 ships with Plasma 6.6.4 featuring:
Custom global theme creation by saving the current theme setup
More options for using color accent in windows with tint intensity for window frames
Support for connecting to Wi-Fi networks by scanning QR codes
Per-application volume adjustment from the task manager
New grayscale filter for colorblindness correction
New screen magnifier feature that tracks the mouse pointer
New “Slow keys” and “reduced motion” settings
Spectacle can do OCR scanning of images to capture text
Per-window filter from screencast through the menu in the title bar
Beyond just the updates included in KDE Plasma 6.6, there are some major new features with Fedora KDE on Fedora Linux 44.
Fresh installations now use the brand-new Plasma Setup and Plasma Login Manager. These provide a more cohesive and integrated experience from the moment the computer is powered on the first time. The installation process has been simplified. It now enables you to easily set up a computer with Fedora KDE Plasma Desktop for a friend or a loved one.
The on-screen keyboard uses the new Plasma Keyboard, providing a fresh and future-forward implementation for keyboard input.
Fedora Linux 44 general updates
Some broader changes in Fedora Linux also directly impact Fedora KDE Plasma Desktop Edition, notably:
PackageKit now uses version 5 of the DNF package manager as the backend.
Support for select Qualcomm-based laptops.
The /etc/pki/tls/cert.pem file no longer exists by default. This may impact some programs that expect this file to provide system CA certificates instead of leveraging behaviors built into cryptographic security libraries to offer this information.
Fedora Ready is ready for Fedora KDE
The Fedora KDE Plasma Desktop 44 edition is fully supported within the Fedora Ready program. Fedora KDE is actively engaging with hardware vendors to support Fedora KDE Plasma Desktop on their devices.
We are pleased to announce that Star Labs offers preinstalled Fedora KDE Plasma Desktop as an option for their portfolio of devices. As makers of computers with an open source ethos embedded into the core of their products with even open source firmware powered by Coreboot, they share many of the same principles the Fedora community values. This is a very exciting moment for Fedora KDE and we look forward to deepening our collaboration with Fedora Ready participants and extending to other vendors. If you are a vendor potentially interested in Fedora Ready, please reach out!
I’m happy to announce that we have sealed bootable container images ready for testing for the Fedora Atomic Desktops!
What are sealed bootable container images?
Sealed bootable container images include all the components needed to create a fully verified boot chain, from the firmware to the operating system composefs image. This relies on Secure Boot and thus only supports system booting with UEFI on x86_64 & aarch64.
The components are:
systemd-boot as bootloader
a Unified Kernel Image (UKI) which includes the Linux kernel, an initrd and the kernel command line
a composefs repository with fs-verity enabled. This is managed by bootc.
Both systemd-boot and the UKI are signed for Secure Boot. The images are test images so the components are not signed with the official keys from Fedora.
The main direct benefit that we will get from this support is that we will be able to enable passwordless disk unlocking using the TPM in a way that will be reasonably secure by default.
We welcome testing and feedback! Please see the list of known issues and report new issue at github.com/travier/fedora-atomic-desktops-sealed. We’ll redirect them as needed to the right upstream projects.
Beware, those are testing images. The root account does not have a password set and sshd is enabled, by default, to make debugging easier. The UKI and systemd-boot are signed for Secure Boot but, since those are test images, they are not signed with the official keys from Fedora. Don’t use those images in production.
Where can I get more details about how this works?
If you want to know more about how sealed images work (i.e. how we make bootable containers, UKI and composefs work together to create a verified boot chain), see the following presentations and documentation:
Fedora Linux 44 has been released! So, let’s see what is included in this new release for the Fedora Atomic Desktop variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
Changes for all Atomic Desktops
Issue tracker moved to the new Fedora forge
We have moved the cross-variants issue tracker to the new Fedora forge. This is the best place to file issues that impacts all variants or to coordinate work between all of them. If you have issues specific to a given desktop environment then we usually prefer to track them in each respective SIG trackers. These are available on the README for the atomic-desktops organization.
Unified documentation, hosted on the new forge
The unified documentation for all Atomic Desktops is finally live! Unfortunately the translations have not been migrated so we will need help to re-translate everything again, once the translation setup is ready with the new forge. It should be mostly copy/paste from the previous docs and this time we will only have to translate the docs once and not for every (new) variant.
Some AppImages are still using an old AppImage runtime that relies on FUSE 2 libraries being available on the host. See the Discussion thread for examples on how to check the runtime of an AppImage.
If some of your AppImages do not work on Fedora Atomic Desktops 44, we recommend:
Looking for a Flatpak for the application and giving it another try. Consider helping upstream package their application as a Flatpak.
Reporting the issue upstream so that they are aware that they should use a newer runtime. Consider helping upstream with this as well.
EncFS or CryFS backends for Plasma Vaults are removed
KDE upstream no longer recommends using the EncFS nor CryFS backends for Plasma Vaults, notably because they rely on the FUSE 2 libraries. If you are using one of those backends, you should migrate your data to a new vault using the only maintained backend (gocryptfs). Ideally this should occur before the update to Fedora Linux 44. If you have already updated to Fedora Linux 44 and need access to your data, you can layer the needed packages (cryfs or fuse-encfs) using rpm-ostree install <package>, then migrate your data and finally reset the layers with rpm-ostree reset.
Dropping compatibility for pkla Polkit rules
Support for the legacy pkla Polkit rules format has been removed. It is unlikely that you were relying on support for those rules as most of the ecosystem has moved on to the new JavaScript based format.
Unified out of the box experience with KDE Plasma Setup (OEM installation)
Thanks to the new Plasma Setup, it is now possible to install the system with Anaconda with minimal configuration and then complete the installation on the first boot by creating a new user and selecting the timezone. This is great when you want to install Fedora Kinoite on a computer and don’t want to setup a user in advance.
As always, I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra media codec, out of tree kernel drivers, etc.).
What’s Next
Helping us with a few nasty bugs
If you have an interest in contributing to Fedora Atomic Desktops, here are some bugs that we will have to fix in the short term. We would greatly appreciate help with:
Fixing root mount options (atomic-desktops#72): This is a long standing and mostly invisible bug that impacts performance.
Moving away from nss-altfiles (atomic-desktops#108): This is another long standing source of issues that new users regularly face.
A lot of work is happening to make the transition to Bootable Containers as smooth as possible for our existing users. You can look at the road map for this transition at atomic-desktops#26.
Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to rebase to Fedora Linux 44 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.
Update your existing system
Prior to actually doing the rebase to Fedora Linux 44, you should apply any pending updates. Enter the following in the terminal:
$ rpm-ostree update
or install updates through GNOME Software and reboot.
Note
rpm-ostree is the underlying atomic technology that all the Fedora Atomic Desktops use. The techniques described here for Silverblue will apply to all of them with proper modifications for the appropriate desktop.
Rebasing using GNOME Software
GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.
First thing to do is download the new image, so select the Download button. This will take some time. When it is done you will see that the update is ready to install.
Select the Restart & Upgrade button. This step will take only a few moments and the computer will restart when the update has completed. After the restart you will end up in a new and shiny release of Fedora Linux 44. Easy, isn’t it?
Rebasing using terminal
If you prefer to do everything in a terminal, then this part of the guide is for you.
Rebasing to Fedora Linux 44 using the terminal is easy. First, check if the 44 branch is available:
$ ostree remote refs fedora
You should see the following in the output:
fedora:fedora/44/x86_64/silverblue
If you want to pin the current deployment (meaning that this deployment will stay as an option in GRUB until you remove it), you can do this by running this command:
# 0 is entry position in rpm-ostree status $ sudo ostree admin pin 0
To remove the pinned deployment use the following command:
# 2 is entry position in rpm-ostree status $ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora Linux 44 branch.
$ rpm-ostree rebase fedora:fedora/44/x86_64/silverblue
Finally, the last thing to do is restart your computer and boot to Fedora Linux 44.
How to roll back
If anything bad happens (for instance, if you can’t boot to Fedora Linux 44 at all) it’s easy to go back. At boot time, pick the entry in the GRUB menu for the version prior to Fedora Linux 44 and your system will start in that previous version rather than Fedora Linux 44. If you don’t see the GRUB menu, try to press ESC during boot. To make the change to the previous version permanent, use the following command:
$ rpm-ostree rollback
That’s it. Now you know how to rebase Fedora Silverblue to Fedora Linux 44 and roll back. So why not do it today?
FAQ
Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.
Question: Can I skip versions during a rebase of Fedora Linux? For example from Fedora Silverblue 41 to Fedora Silverblue 44?
Answer: Although it could sometimes be possible to skip versions during rebase, it is not recommended. You should always update to one version prior (41->42->43->44 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I get errors during rebase. How should I do the rebase?
Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:
After doing this you can follow the guide in this blog post.
Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?
Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/44/x86_64/kinoite
You went above and beyond - Fedora Project would not be the same without you!
You visited Fedora and CentOS at Red Hat Summit 2026
︎
So, let’s see what is included in this new release for the Fedora Atomic Desktop variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
comments? additions? reactions?
As always, comment on the fediverse: https://fosstodon.org/@nirik/116585359828306662