/rss20.xml">
fedora

Fedora People
Blog List
RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll

misc fedora bits second week of may 2026

Posted by Kevin Fenzi on 2026-05-16 16:30:26 UTC
Scrye into the crystal ball

RHEL10 and Fedora44 migrations

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.

If you do see one, I am keeping the ticket about this open until monday: https://forge.fedoraproject.org/infra/tickets/issues/12913

kernel security updates whirlwind

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.

comments? additions? reactions?

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

Community Update – Week 20

Posted by Fedora Community Blog on 2026-05-15 15:09:12 UTC

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 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

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

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

  • 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 
  • Rebased and rebuilt OpenJDK 26 for F43 with CVE fixes. 
  • 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.
  • Podman 6.0 test days are happening this week: Test_Day:2026-05-11_Podman_6.0
  • 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
  • Tech debt: modernization work on testdays-web and stats tools, cleaned up membership of several significant groups

Forgejo

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

EPEL

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

  • Carl is attending RH Summit and supporting the community booths
  • Working on making CentOS 10 available in the lxd image catalog.

UX

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

  • Madeline and Emma alternating PTO for whole month
  • Flock branding is top priority for the next two sprints.

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 20 appeared first on Fedora Community Blog.

How Fedora is responding to recent Kernel vulnerabilities

Posted by Fedora Magazine on 2026-05-15 14:40:13 UTC
Banner showing a drawing of a padlock and the text "How Fedora is responding to recent Kernel vulnerabilities".

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!

Heroes of Fedora Quality for Fedora 44

Posted by Kamil Páral on 2026-05-15 08:46:46 UTC

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

NameTest cases executedReferenced bugs1
derekenz4682365456 2438905 2444046 2448211 2456542 2458714 (6)
lruzicka1322442593 2442988 2444078 2458907 (4)
geraldosimiao1322444046 (1)
psklenar112
kparal106
nielsenb812442689 2448757 (2)
aggraxis70
jlinton582183626 2402621 2444775 2444776 2457333 2457336 (6)
robatino56
jcline36
abhis3k35
xariann20
osalbahr19
jgroman15
pboy15
ahmedalmeleh9
korora8
adamwill52448283 2453216 (2)
supakeen3

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

NameBug reports submitted1Excess reports2Accepted blockers3
Lukas Ruzicka209 (45%)1
Petr Sklenar161 (6%)1
Adam Williamson91 (11%)2
Steven Hollingsworth90 (0%)0
Steve Cossette70 (0%)0
Kamil Páral61 (17%)0
Mr. Beedell, Jared Richard William50 (0%)0
Akira TAGOH41 (25%)0
Jeremy Linton41 (25%)0
lpavan at redhat.com40 (0%)0
Neal Gompa40 (0%)0
Adrian Vovk30 (0%)0
gav at gavworld.co.uk30 (0%)0
Laurențiu Nicola30 (0%)0
Matt Fagnani30 (0%)0
Osama Albahrani30 (0%)0
Than Ngo30 (0%)0
…and also 67 other reporters who created less than 3 reports each, but 76 reports combined!

Test period: Fedora 44 Beta – Fedora 44 Final release (2026-03-10 – 2026-04-28)
Contributors: 252
Bug reports submitted: 426

NameBug reports submitted1Excess reports2Accepted blockers3
Davide Repetto181 (6%)0
Petr Sklenar182 (11%)0
Fabio Valentini120 (0%)0
Kamil Páral115 (45%)1
Adam Williamson100 (0%)3
Ricardo Ramos70 (0%)0
Lukas Ruzicka61 (17%)1
Matt Fagnani60 (0%)0
Calum Chisholm50 (0%)0
lray+redhatbugzilla at mailbox.org50 (0%)0
Andrey Motoshkov40 (0%)0
Artem S. Tashkinov41 (25%)0
Brian Morrison40 (0%)0
Chang Qian40 (0%)0
Derek Enz42 (50%)0
Dominic40 (0%)0
iltis at posteo.de40 (0%)0
Jan Macku40 (0%)0
Jeremy Nickurak40 (0%)0
kxra at riseup.net40 (0%)0
Luke40 (0%)0
Mr. Beedell, Jared Richard William40 (0%)0
Steven Hollingsworth40 (0%)0
tk2345_ at outlook.com30 (0%)1
Alan Altmann31 (33%)0
anotheruser30 (0%)0
Cristian Ciupitu30 (0%)0
Eugene Mah30 (0%)0
Jonathan S.30 (0%)0
speedlemma at gmail.com32 (67%)0
Steve Cossette30 (0%)0
…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

NameUpdates commented
Geraldo S. Simião Kutz (geraldosimiao)307
Filipe Rosset (filiperosset)185
Eugene Mah (imabug)98
Derek Enz (derekenz)88
anotheruser78
bojan71
Ian Laurie (nixuser)66
Kamil Páral (kparal)37
Neal Gompa (ngompa)35
Fabio Valentini (decathorpe)33
František Zatloukal (frantisekz)31
Xariann Cat (xariann)25
ramot24
Cristian Ciupitu (ciupicri)23
Ankur Sinha (ankursinha)20
Adam Williamson (adamwill)17
Alex Gurenko (agurenko)15
Benjamin Beasley (music)14
Lukáš Růžička (lruzicka)11
Simon de Vlieger (supakeen)9
Michel Lind (salimma)9
brett h (bretth)9
Dennis Gilmore (ausil)8
Paul Whalen (pwhalen)7
Wasser Mai (wasser19641)7
Peter Robinson (pbrobinson)7
Lukas Slebodnik (lslebodn)7
Colin Thomson (g6avk)6
Juha Uotila (inffy)6
Steve Cossette (farchord)5
markec5
…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

NameTest cases executed
lpavan42
mcrha36
adriend34
tagoh27
pnemade23
16levels23
lruzicka17
stransky16
michal odehnal16
pschindl15
jgrulich15
alciregi15
psklenar12
dkricka12
jpb2112
romangherta12
royboy62611
twinkle2811
vhumpa11
alangm100111
pyadav10
rduda10
paolojr10
dtunma10
bittin9
pauloheaven9
jgroman8
derekenz8
gornikfan8
tdawson8
vsembiba8
mkasik8
clnetbox8
mzink8

…and also 64 other testers who executed less than 8 updates each

We sincerely thank all contributors!🏅

Are you also interested to help? Please look at our Fedora Quality homepage.

Every project has politics

Posted by Ben Cotton on 2026-05-14 12:00:00 UTC

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 post’s featured photo by Maayan Nemanov on Unsplash.

The post Every project has politics appeared first on Duck Alignment Academy.

The syslog-ng Insider 2026-05: OTEL; central log collection; old Mac

Posted by Peter Czanik on 2026-05-14 11:46:57 UTC

Dear syslog-ng users,

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.

https://www.syslog-ng.com/community/b/blog/posts/streaming-syslog-ng-data-to-your-lakehouse-using-opentelemetry

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.

https://www.syslog-ng.com/community/b/blog/posts/central-log-collection—more-than-just-compliance

Compiling syslog-ng on an old Mac

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.

https://www.syslog-ng.com/community/b/blog/posts/compiling-syslog-ng-on-an-old-mac

syslog-ng logo

Your feedback and news, or tips about the next issue are welcome. To read this newsletter online, visit: https://syslog-ng.com/blog/

F44 election nominations now open

Posted by Fedora Community Blog on 2026-05-13 20:38:01 UTC

The Fedora Project is now in the nomination period during which we accept nominations to the “steering bodies” of the following teams:

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.

The post F44 election nominations now open appeared first on Fedora Community Blog.

Gratamente sorprendido con gemini-3.1-flash-lite-preview

Posted by Rénich Bon Ćirić on 2026-05-13 16:00:00 UTC

Ú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?

https://geminicli.com/docs/resources/quota-and-pricing/

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.

Por lo pronto, lo voy a estar usando bastante.

Log Detective in Packit

Posted by Fedora Magazine on 2026-05-13 08:00:00 UTC

Log Detective analysis is coming to Packit.

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.

Fedora Hummingbird: Taking the Hummingbird model to the full operating system

Posted by Fedora Magazine on 2026-05-12 12:00:00 UTC

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:

0. Retrieve the image

sudo podman pull \
  quay.io/hummingbird-community/bootc-os:latest

1. Create the image

sudo podman run --rm --privileged --pull=newer \
  --security-opt label=type:unconfined_t \
  -v /tmp/bib-config.toml:/config.toml:ro \
  -v /var/lib/libvirt/images:/output \
  -v /var/lib/containers/storage:/var/lib/containers/storage \
  quay.io/centos-bootc/bootc-image-builder:latest \
  --type qcow2 --rootfs ext4 \
  quay.io/hummingbird-community/bootc-os:latest

2. Rename the image

sudo mv /var/lib/libvirt/images/qcow2/disk.qcow2 \
  /var/lib/libvirt/images/fedora-hummingbird.dc2.crunchtools.com \
  && sudo rmdir /var/lib/libvirt/images/qcow2

3. Create a virtual machine

sudo virt-install --connect qemu:///system \
  --name fedora-hummingbird.dc2.crunchtools.com \
  --memory 4096 --vcpus 2 \
  --disk /var/lib/libvirt/images/fedora-hummingbird.dc2.crunchtools.com,format=qcow2 \
  --import --os-variant fedora-unknown \
  --network network=default,model=virtio \
  --graphics vnc --noautoconsole

Get involved

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.

Restart of database server @ Copr Frontend

Posted by Fedora Infrastructure Status on 2026-05-12 11:00:00 UTC

Going to restart PostgreSQL, there would be a short outage.

Affected Services:

copr-frontend - https://copr.fedorainfracloud.org

Flatpak Sandbox Escape via Yelp

Posted by Michael Catanzaro on 2026-05-11 14:12:53 UTC

Yelp 49.1 fixes a significant Flatpak sandbox escape related to last year’s CVE-2025-3155. CVE assignment for this new issue is currently pending.

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.

misc fedora bits first week of may 2026

Posted by Kevin Fenzi on 2026-05-09 17:30:29 UTC
Scrye into the crystal ball

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.

comments? additions? reactions?

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

Community Update – Week 19 2026

Posted by Fedora Community Blog on 2026-05-08 10:00:00 UTC

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 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

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

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

  • 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.

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.

Forgejo

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

EPEL

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

  • prep work for EPEL presentations and booth work at Summit
  • routine packaging and documentation work

UX

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

  • Finished Bootc Sealed Images logo [ticket]
  • Flock t-shirt design finalised and handed over 
  • Had our first Backlog Refinement call ahead of our next sprint 🙂

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 19 2026 appeared first on Fedora Community Blog.

Hatlas News: 2026-05-08

Posted by Hatlas FDWG on 2026-05-08 08:00:00 UTC

News #

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?

Community Updates #

New member: @andungu #

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!

You can check out more on her blog at https://dev.to/andungu

Split from CommOps #

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.

Privacy Updates #

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.

Volunteer Agreement #

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 🤞.

Technical Updates #

Multiplayer Ops #

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!

SSO Everywhere #

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.

Next (?) #

My standard disclaimer: my priorities shift constantly depending on opportunities and obstacles.

Flock #

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…

More team foundations #

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!

FAS federation #

@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.

Datanommer Pipeline Automation #

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.

BI Tooling #

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?)

Docs Updates #

The public side of Hatlas is still way overdue for some updates. We also have a goal to create official FDWG docs to house this info.

Employment? #

I’m still unemployed. I’m trying not to get neurotic about that, though my situation is becoming desperate.

My family and I would be incredibly grateful if you’re able to contribute to any of the hosting costs for Hatlas (roughly $100/mo). ❤️

Status brief #

Done #

  • Hatlas k8s infra code is now fully public and mostly documented
    • @smoliicek 90% onboarded
  • FAS groups created
  • Contributor Agreement created and submitted to Council
  • We have our first official analysts: @evelynrp and @andungu

WIP #

  • Refactoring ansible to make it public
  • Waiting on our Forge space to move infra repos
  • Final OIDC integrations

On-deck #

  • Flock
  • Automation
  • Shared BI tooling

🛡️ PHP version 8.1.34, 8.2.30, 8.3.29, 8.4.16, and 8.5.1

Posted by Remi Collet on 2025-12-19 09:39:00 UTC

RPMs of PHP version 8.5.1 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.4.16 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.3.29 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.2.30 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.1.34 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

ℹ️ These versions are also available as Software Collections in the remi-safe repository.

ℹ️ The packages are available for x86_64 and aarch64.

🛡️ These Versions fix 4 security bugs (CVE-2025-14177, CVE-2025-14178, CVE-2025-14180), so the update is strongly recommended.

Version announcements:

ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.5 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.5/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.5
dnf update

Parallel installation of version 8.5 as Software Collection

yum install php85

Replacement of default PHP by version 8.4 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.4/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.4
dnf update

Parallel installation of version 8.4 as Software Collection

yum install php84

Replacement of default PHP by version 8.3 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.3/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.3
dnf update

Parallel installation of version 8.3 as Software Collection

yum install php83

And soon in the official updates:

⚠️ To be noticed :

  • EL-10 RPMs are built using RHEL-10.1
  • EL-9 RPMs are built using RHEL-9.7
  • EL-8 RPMs are built using RHEL-8.10
  • intl extension now uses libicu74 (version 74.2)
  • mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
  • oci8 extension now uses the RPM of Oracle Instant Client version 23.9 on x86_64 and aarch64
  • A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)

⚙️ PHP version 8.4.20 and 8.5.5

Posted by Remi Collet on 2026-04-10 05:48:00 UTC

RPMs of PHP version 8.5.5 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.4.20 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

ℹ️ These versions are also available as Software Collections in the remi-safe repository.

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ There is no security fix this month, so no update for versions 8.2.30 and 8.3.30.

Version announcements:

ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.5 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.5/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.5
dnf update

Parallel installation of version 8.5 as Software Collection

yum install php85

Replacement of default PHP by version 8.4 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.4/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.4
dnf update

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

⚠️ To be noticed :

  • EL-10 RPMs are built using RHEL-10.1
  • EL-9 RPMs are built using RHEL-9.7
  • EL-8 RPMs are built using RHEL-8.10
  • intl extension now uses libicu74 (version 74.2)
  • mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
  • oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
  • A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)

 

🛡️ PHP version 8.2.31, 8.3.31, 8.4.21 and 8.5.6

Posted by Remi Collet on 2026-05-08 05:52:00 UTC

RPMs of PHP version 8.5.6 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.4.21 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.3.31 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.2.31 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

ℹ️ These versions are also available as Software Collections in the remi-safe repository.

ℹ️ The packages are available for x86_64 and aarch64.

🛡️ These Versions fix 8 to 13 security bugs (CVE-2026-6735, CVE-2026-7259, CVE-2025-14179, CVE-2026-6722, CVE-2026-7261, CVE-2026-7262, CVE-2026-7568, CVE-2026-7258, CVE-2026-6104, CVE-2026-42371, CVE-2026-7263, CVE-2026-29078, CVE-2026-29079), so the update is strongly recommended.

Version announcements:

ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.5 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.5/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.5
dnf update

Parallel installation of version 8.5 as Software Collection

yum install php85

Replacement of default PHP by version 8.4 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.4/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.4
dnf update

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

⚠️ To be noticed :

  • EL-10 RPMs are built using RHEL-10.1
  • EL-9 RPMs are built using RHEL-9.7
  • EL-8 RPMs are built using RHEL-8.10
  • intl extension now uses libicu74 (version 74.2)
  • mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
  • oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
  • A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)

New badge: Red Hat Summit 2026 !

Posted by Fedora Badges on 2026-05-08 02:54:50 UTC
Red Hat Summit 2026You visited Fedora and CentOS at Red Hat Summit 2026

Friday Links 26-16

Posted by Christof Damian on 2026-05-07 22:00:00 UTC
Bumblebee on pale yellow flowers against a white wall

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.
Simplifying Coaching
Claire Pedrick

Engineering

How it feels to be a software engineer when AI is changing our relationship with code [Podcast] - very insightful views from Nate.

Sausage Factory: Fedora ELN Rebuild Strategy (2026 Edition)

Posted by Stephen Gallagher on 2026-05-07 18:03:40 UTC

The Rebuild Algorithm

Slow and Steady Wins the Race

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.

  1. 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. ↩︎
  2. 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. ↩︎

Community Update – Week 18, 2026

Posted by Fedora Community Blog on 2026-05-06 14:37:01 UTC

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.

Forgejo

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

  • Foundational private issues frontend codebase implementation.
  • Had a discussion on the collaboration strategy for the private issues
  • Private Issues, Web UI: Push the foundational private issues frontend codebase implementation.
  • Made some headway in the private issues dependencies implementation [Ticket]
  • Spent a lot of Claude credits while brainstorming, nay, CUDA-storming what-if conditions
  • Aarch64 runner successfully tested on staging (running on an AWS arm64 VM)
  • New Forge Runner automation successfully deployed to production (and fixing discrepancy between openshift staging and production volume snapshots)
  • Work towards getting the runnerhostvm enrolled in zabbix.

EPEL

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

  • presented RPM packaging workshop and staffed booth at LinuxFest Northwest
  • routine packaging work, including CVE fixes in forgejo-runner, glow, and vhs packages

UX

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

  • Sketches for Bootc Sealed Images logo [ticket]
  • Mockup for Flock 2026 t-shirt [ticket]
  • Aligning with Brand for Fedora Hummingbird Linux
  • Providing feedback to Jess Chitas from OSAIPO for Flock to Fedora Website Redesign [ticket]

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update – Week 18, 2026 appeared first on Fedora Community Blog.

s390 builder outage

Posted by Fedora Infrastructure Status on 2026-05-06 12:00:00 UTC

Our s390 machine is currently offline due to a suspected storage issue. We are investigating.

Affected Services:

  • s390 builders

Fedora 44, CentOS 7 and Amazon Linux syslog-ng questions

Posted by Peter Czanik on 2026-05-06 11:28:09 UTC

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?

What is next?

Share your thoughts with us in this syslog-ng GitHub discussion: https://github.com/syslog-ng/syslog-ng/discussions/5691 or reach out to me on Twitter / Mastodon / LinkedIn.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/fedora-44-centos-7-and-amazon-linux-syslog-ng-questions

🎲 PHP version 8.4.21RC1 and 8.5.6RC1

Posted by Remi Collet on 2026-04-24 04:58:00 UTC

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

RPMs of PHP version 8.5.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.

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

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

Update of system version 8.4:

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

ℹ️ Notice:

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

Software Collections (php84, php85)

Base packages (php)

Join Us for Podman 6.0 Test Days – May 11-15, 2026

Posted by Fedora Community Blog on 2026-05-05 11:56:11 UTC

The Fedora QA team invites you to participate in the Podman 6.0 Test Days from Monday, May 11-15, 2026.

Podman 6.0 is a major modernization release that removes legacy
components and finalizes previously announced deprecation:

What’s New in Podman 6.0

  • Modern networking: Netavark switches from iptables to nftables,
    aligning with current Fedora defaults
  • Simplified architecture: Removal of slirp4netns (replaced by Pasta)
    and BoltDB (replaced by SQLite)
  • Cleaner configuration: Redesigned client/server configuration

These changes reduce technical debt and create a cleaner, more
maintainable codebase.

How to Participate

Requirements:

  • Fedora 45 (Rawhide) – use the latest nightly image
  • Virtual or physical machine
  • Fully updated system

Testing:

  1. Visit Podman 6.0 Test Days wiki and find links to rawhide iso and test cases.
  2. Run tests and report results.

Need help?

Join us on Matrix: #podman:fedoraproject.org – developers and QA
specialists will be available all throughout the week. Or join our mailing list test@lists.fedoraproject.org.

Learn more:

The post Join Us for Podman 6.0 Test Days – May 11-15, 2026 appeared first on Fedora Community Blog.

Restart of Copr servers

Posted by Fedora Infrastructure Status on 2026-05-05 10:00:00 UTC

Restart of Copr servers. There is possibility of short outage.

Affected Services:

copr-frontend - https://copr.fedorainfracloud.org copr-backend - https://copr-be.cloud.fedoraproject.org/

Why the Fedora AI-Assisted Contributions Policy Matters for Open Source

Posted by Justin Wheeler on 2026-05-04 08:00:00 UTC
Why the Fedora AI-Assisted Contributions Policy Matters for Open Source

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:

  1. 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.

  2. 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).

  3. 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.

New Fedora package: fedora-active-user

Posted by Marcin Juszkiewicz on 2026-05-04 06:37:00 UTC

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

misc fedora bits last of april 2026

Posted by Kevin Fenzi on 2026-05-02 17:41:55 UTC
Scrye into the crystal ball

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.

comments? additions? reactions?

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

Loadouts For Genshin Impact v0.1.16 Released

Posted by Akashdeep Dhar on 2026-05-01 18:30:56 UTC
Loadouts For Genshin Impact v0.1.16 Released

Hello travelers!

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.

Resources

Installation

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

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

Installation command for Fedora Linux

Changelog

  • 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.

Loadouts For Genshin Impact v0.1.16 Released
Loadouts For Genshin Impact v0.1.16 Released

Linnea - Workspace and Results

Weapons

One weapon has debuted in this version release.

Loadouts For Genshin Impact v0.1.16 Released
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.

Hatlas News: 2026-05-01

Posted by Hatlas FDWG on 2026-05-01 08:00:00 UTC

News #

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.

Community Updates #

I’m thrilled to announce that we’ve had two new FDWG contributors join us, and they’re both already making huge contributions:

@evelynrp #

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!

Check out her blog at https://evelynpark.com/ .

@smoliicek #

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.

Check out his blog at https://smoliicek.cz/ .

Technical Updates #

Multiplayer Ops #

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.

Privacy Updates #

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.

Parquet Downloads #

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.

Next (?) #

My standard disclaimer: my priorities shift constantly depending on opportunities and obstacles.

Flock #

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.

Automation #

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.

Tooling #

We are almost in position to launch general shared tooling such as Superset.

Docs Updates #

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.

Employment? #

I’m still unemployed. I’m trying not to get neurotic about that, but it does add up after a while.

My family and I would be incredibly grateful if you’re able to contribute to any of the hosting costs for Hatlas (roughly $100/mo). ❤️

Status brief #

Done #

  • SSO, security policies, data governance technical controls.
  • @smoliicek has been granted access as the first ops user.
  • @evelynrp has made her (and FDWG’s) very first PR.

WIP #

  • Refactoring Infra code to allow FDWG to manage Hatlas infra.

On-deck #

  • Flock
  • Automation
  • Shared BI tooling

Friday Links 26-15

Posted by Christof Damian on 2026-04-30 22:00:00 UTC
Pink bike covered in pink flowers parked on the Joes Kloppenburgbrug in Amsterdam

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.
Accelerate
Nicole Forsgren PhD, Jez Humble, Gene Kim

Engineering

Do I belong in tech anymore? - I can relate to some of this.

Let’s Welcome Our Google Summer of Code 2026 Contributors!

Posted by Felipe Borges on 2026-04-30 21:05:07 UTC

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.

For more information, visit https://summerofcode.withgoogle.com/programs/2026/organizations/gnome-foundation

Libblockdev 3.5.0 released

Posted by Vojtěch Trefný on 2026-04-29 09:25:00 UTC

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.

Things I Read: 16-29 April 2026

Posted by Brian (bex) Exelbierd on 2026-04-29 07:40:00 UTC

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.

Czech Republic

  • Minimum Decent Wage in The Czech Republic Was CZK 48,336 in 2025, Says Study

    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.

  • Sneaker Company Allbirds Plans to Pivot to A.I. Yes, A.I.

    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.

  • Brno Will Say Goodbye To Long-Serving Tatra K2 Trams This Weekend

    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!

Technology

  • NearlyFreeSpeech.NET Blog » How (and why) we rewrote our production C++ frontend infrastructure in Rust

    An article about why Rust may be a great choice from the non-oxidation crowd.

    Was it not bad enough that we reinvented the wheel in the first place? We had to reimplement that reinvented wheel?

    The Conversion Process: Stealing all your furniture and replacing it with exact duplicates

  • The peril of laziness lost | The Observation Deck

    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.

  • Stop building agents, start harnessing Goose

    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.

  • Changes in the system prompt between Claude Opus 4.6 and 4.7

    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 Don’t Care for Gnome - woltman.com

    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.”

I was born in the USA

  • That’s Not What Unc Means

    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.

  • They Went Abroad to Save Money. Moving Back Seems Unaffordable.

    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.

  • The Mystery in the Medicine Cabinet

    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.’

  • The Only 3 Knives You Actually Need in Your Kitchen

    Let’s try three pennies of an angle away from the honing rod

    Anything but an internationally recognized measurement system.

Lifestyle

  • ‘There is no news’: What a change from 1930 to today

    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.

  • Rediscovering the Handcart

    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 …

  • Quiz: Can You Tell Real British Insults From Fakes?

    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.

Fedora Asahi Remix 44 is now available

Posted by Fedora Magazine on 2026-04-28 14:05:33 UTC

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.

Please report any Remix-specific issues in our tracker, or reach out in our Discourse forum or our Matrix room for user support.

What’s New in Fedora KDE Plasma Desktop 44

Posted by Fedora Magazine on 2026-04-28 14:04:00 UTC

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

There’s so much more detail available in the Plasma 6.6 release announcement.

Fedora KDE 44 specific updates

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!

Wrap-up

The Fedora KDE SIG hopes that you’ll find the Fedora KDE Plasma Desktop 44 to be a wonderful experience. When you’re ready to try it, click here for download links and verification instructions. If you’d like to learn more, check out the Fedora KDE Plasma Desktop website.

Sealed Fedora Atomic Desktop bootable container images

Posted by Fedora Magazine on 2026-04-28 14:03:00 UTC

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.

How do I test those images?

See the instructions at github.com/travier/fedora-atomic-desktops-sealed on how to give the pre-built container and disk images a try and how to build your own.

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:

Thanks to all the contributors that made this possible, notably (but non exhaustively) from the following projects: bootc & bcvk, composefs & composefs-rs, chunkah, podman & buildah and systemd.

What’s New for Fedora Atomic Desktops in Fedora Linux 44

Posted by Fedora Magazine on 2026-04-28 14:02:00 UTC

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.

See the tracking issue atomic-desktops#10.

Removal of FUSE version 2 libraries

FUSE version 2 has been deprecated and unmaintained for a while so we have removed it from the images. In practice, this means two things:

  • If you are using AppImages, some of them may not work anymore.
  • If you are using legacy backends with Plasma Vault on Kinoite, you need to migrate your data.

See the Fedora Change and the tracking issue atomic-desktops#50. The implications are detailed below.

AppImages and the FUSE 2 libraries

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.

See the Fedora Change and the tracking issue atomic-desktops#102.

What’s New in Silverblue

GNOME 50

Fedora Silverblue comes with the latest GNOME 50 release. For more details about the changes that occur alongside GNOME 50, see What’s New in Fedora Workstation 44 on the Fedora Magazine.

What’s New in Kinoite

KDE Plasma 6.6

Fedora Kinoite ships with Plasma 6.6, Frameworks 6.24 and Gear 25.12.

See also What’s New in Fedora KDE Plasma Desktop 44 in the Fedora Magazine.

KDE Plasma Login Manager replaces SDDM

The brand new Plasma Login Manager replaces SDDM to provide a more integrated experience with systemd and the KDE Plasma session.

See the Fedora Change.

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.

See the Fedora Change.

What’s New in Sway Atomic

Nothing specific for this release.

What’s New in Budgie Atomic

Fedora Budgie Atomic comes with the latest 10.10.2 Budgie release. This release brings Wayland support to Budgie Atomic. See the 10.10 release announcement for more details.

What’s New in COSMIC Atomic

Fedora COSMIC Atomic comes with the latest 1.0.8 release of the COSMIC desktop. This is now considered stable.

Universal Blue, Bluefin, Bazzite and Aurora

Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora Linux 44. Look for upcoming announcements in their Discourse.

As always, I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra media codec, out of tree kernel drivers, etc.).

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.

Sealed Fedora Atomic Desktop bootable container images

Sealed images are now ready for testing! See the other article for all the details.

Road map to Bootable Containers

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.

One of the tasks is to move away from our unmaintained installation ISO building scripts to the new image-builder tooling. This is planned for Fedora Linux 45 for the ostree variants and support for Bootable Container will follow right after.

Another task is to start building the Fedora Atomic Desktops Bootable Container images using the Fedora Konflux instance.

Where to reach us

We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.

How to Rebase to Fedora Linux 44 on Silverblue

Posted by Fedora Magazine on 2026-04-28 14:01:00 UTC

Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to rebase to Fedora Linux 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:

$ rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release

After doing this you can follow the guide in this blog post.

Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?

Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/44/x86_64/kinoite

What’s New in Fedora Workstation 44

Posted by Fedora Magazine on 2026-04-28 14:00:00 UTC

This article highlights a few noteworthy changes in the latest release of Fedora Workstation that we think you will love. Upgrade today from the official website, or upgrade your existing install using GNOME Software or through the terminal with dnf system-upgrade.

GNOME 50

Fedora Linux 44 Workstation ships with the latest GNOME release, GNOME 50. This comes with a long list of refinements to your desktop, including everything from accessibility, to color management and remote desktop.

As part of the Digital Wellbeing initiative, new native Parental Controls let you set screen time limits and bedtimes directly from Settings.

Many of the applications that are installed by default on the Fedora Workstation have also seen improvements, from the Document Viewer to the File Manager and the Calendar.

To learn more about these and other changes, you can read the GNOME 50 release notes.

Wrap-up

Be sure to check out the Fedora Linux 44 Change Set wiki for even more details about all the features and changes that went into Fedora Linux 44. Use the Fedora Discussion forum or Fedora’s Matrix chat server if you want to converse with the Fedora community about this new release!

The Fedora Linux 44 Release is Here!

Posted by Fedora Magazine on 2026-04-28 13:59:00 UTC

I’m excited to announce that Fedora Linux 44 is here! Keep reading to discover highlights of Fedora Linux 44, or if you are ready, just jump right in and give Fedora Linux 44 a try!

Thanks to everyone who helped!

Thank you and congrats to everyone who has contributed to this release. And thanks to everyone who showed up for the virtual release party last Friday. We celebrated a little early this year, just after the go/no-go meeting made the release official. If you weren’t able to join us live, you can watch the recording and hear about some of the great work from the contributors involved.

Looking to upgrade?

If you have an existing system, Upgrading Fedora Linux to a New Release is easy. In most cases, it’s not very different from just rebooting for regular updates, except you’ll have a little more time to grab a coffee.

Ready to Fresh Install?

If this is your first time running Fedora Linux, or if you just want to start fresh with Fedora, download the install media for our flagship Editions (Workstation, KDE Plasma Desktop, Cloud, Server, CoreOS, IoT), or one of our Atomic Desktops (Silverblue, Kinoite, Cosmic, Budgie, Sway), or alternate desktop options (like Cinnamon, Xfce, Sway, or others).

What’s new?

As usual with Fedora Linux, there are just too many individual changes and improvements to go over in detail. You’ll want to take a look at the release notes for that.

Notable User Visible Changes

Anaconda

For those of you installing fresh Fedora Linux 44 Spins, you may notice a change in how Anaconda handles network devices. Anaconda now only creates network profiles for devices configured during installation (by boot options, kickstart, or interactively in UI) instead of providing default profiles for all devices. This change will simplify post-installation network configuration for users who need to customize after installation.

Workstation

Fedora Linux 44 Workstation ships with the latest GNOME release, GNOME 50. This comes with a long list of refinements to your desktop, including everything from accessibility to color management and remote desktop. Many of the applications that are installed by default on Fedora Workstation have also seen improvements, from Document Viewer to File Manager and Calendar. To learn more about these and other changes, you can read the GNOME 50 release notes.

KDE Plasma Desktop

KDE Plasma Desktop: If you are a KDE user, you should also notice a couple of very obvious changes. Fedora KDE Plasma Desktop 44 is based on the latest Plasma 6.6, which includes the new Plasma Login Manager and Plasma Setup to provide a more cohesive and integrated experience from the moment the computer is powered on for the first time. The installation process has been simplified, enabling you to easily set up Fedora KDE Plasma Desktop for a computer for a friend or a loved one.
 

Plumbing Upgrades

Beyond the user-visible changes, there are some important plumbing changes user should be aware of.

OpenSSL Cert File Handling Improvements

The loading time of OpenSSL has been improved by making use of directory-hash support for ca-certificates. This improvement required changes to where some certificate bundles are stored on the filesystem. You can read the specific Change details for more information.

The MariaDB default version is now 11.8

MariaDB packages use a versioned package layout, which allows Fedora to deliver both, mariadb-10.11 and mariadb-11.8 for users.  The “distribution default” unversioned MariaDB packages now install the 11.8 versions in Fedora Linux 44. User doing upgrades to Fedora Linux 44 won’t notice the change in the default. For new users installing MariaDB for the first time, unless you specify the version, you’ll now get 11.8 by default.

Wine NTSYNC

The NTSYNC kernel module is enabled for select packages by package recommendation (notably Wine and Steam), which can improve compatibility and performance when running Windows applications (especially games).  When packages that recommend the wine-ntsync package are installed, the package recommendation ensures NTSYNC is configured automatically on subsequent boots, so that users don’t have to manually enable NTSYNC.

Fedora Cloud boot partition using Btrfs

The /boot partition has been replaced with a Btrfs subvolume for Fedora Cloud images that support it.  This results in better space utilization and smaller images.

If you hit a snag

If you run into a problem, visit our Ask Fedora user support forum. This forum includes a category where we collect common issues and solutions or work-arounds.

Just drop by and say “hello”

Drop by our “virtual watercooler” on Fedora Discussion and join a conversation, share something interesting, and introduce yourself. We’re always glad to see new people!

Support for OpenSSL 4.0?

Posted by Peter Czanik on 2026-04-28 13:20:56 UTC

Although OpenSSL 4.0 released just two weeks ago, the syslog-ng project has already received a GitHub issue complaining that we do not support it. So, before we would allocate too much effort on it: what should we expect?

OpenSSL 4.0 was announced on April 14: https://openssl-library.org/post/2026-04-14-openssl-40-final-release/ However, this announcement mentions that it is NOT a long-term support (LTS) release.

This raises the question that if it is not an LTS release, then can we stay on version 3.x and skip 4.x altogether? When will Linux distributions start using it? Looking at Repology, there are already a few places where OpenSSL 4.0 is available. This includes Gentoo, the community where the GitHub issue originated from, and also various FreeBSD ports. The current list is available at: https://repology.org/project/openssl/versions

Fedora is planning to use OpenSSL 4.0 as default starting from the next release: https://fedoraproject.org/wiki/Changes/OpenSSL40 However, OpenSSL 3.x will most likely stay supported for backwards compatibility.

I am also curious if there are any other projects which have added support for OpenSSL 4.0. If so, then what are your experiences? Was porting your code to use OpenSSL 4.0 difficult?

I am all in for supporting the latest technologies, but currently, even if we have an open request for OpenSSL 4.0 support, I do not feel that I have enough information to prioritize its development.

Share your thoughts with us in this syslog-ng GitHub discussion: https://github.com/syslog-ng/syslog-ng/discussions/5685 or reach out to me on Twitter / Mastodon / LinkedIn.

syslog-ng logo

Originally published at https://www.syslog-ng.com/community/b/blog/posts/support-for-openssl-4-0

Throwing Random Arguments at System Binaries: Real Segfaults vs. Ticket Noise

Posted by Fedora Community Blog on 2026-04-28 12:00:00 UTC

Why Would Anyone Do This?

Two and half reasons:

  1. Smoke testing – You want to know if your system commands actually work, not just when you run them the way the docs say, but when users (or their scripts) feed them garbage.
  2. AI is excellent at generating potential edge cases, and tracking systems are already all too eager to collect new tickets. I’m being careful not to dump every AI finding into Bugzilla; I don’t want to clutter the backlog and mainly waste developer time on theoretical bugs. Or Should I?

Plus, segfaults don’t lie – either the system crashed or it didn’t, and those are the issues that actually deserve the ticket.

Throwing Random Arguments at System Binaries Until They Crash

Script to do the work:

A pretty straightforward bash script, vibing with AI-generated chaos.

  1. Grab all binaries from /usr/bin and /usr/sbin
  2. Parse --help for flags (--whatever, -x, you know the drill)
  3. Pick random combos of those flags (1-4 per run)
  4. Feed them garbage: broken JSON/XML, binary junk, path traversal attempts, format strings, absurdly long lines

Only logs actual crashes – SIGSEGV, SIGABRT, SIGILL, SIGBUS. Exit code 1 from bad args gets ignored.

Core logic looks like this:

# Extract flags from --help                                            
  flags=$(timeout 3s "$bin" --help 2>&1 |                   
      grep -aoE -e '--[a-zA-Z0-9_-]+' -e '-[a-zA-Z]' |                                                    
      grep -avE 'help|version|usage')                                                                     
                                                                                                          
  # Pick random flags (1-4 of them)                                                                       
  chosen=$(echo "$flags" | shuf -n $((1 + RANDOM % 4)))                                                   
                                                                                                          
  # Add a random test file                                                                                
  fuzz_file="$WORKSPACE/$(random_pick: bad.json, random.bin, longline.txt, ...)"                          
                                                                                                          
  # Run it                                                  
  timeout 5s "$bin" $chosen $fuzz_file

Script skips the obvious no go zones – package managers, rm, network tools, editors. I’m glad to see the script finish with the machine still answering.

Try It Yourself!

Source: run-them-all

Run via Testing Farm (how-to):

testing-farm-public request --test-type fmf \                                                
    --git-url https://forge.fedoraproject.org/quality/fmf-tests.git \                                     
    --git-ref main \
    --compose Fedora-Cloud-Base-AmazonEC2.x86_64-44-1.3 \                                                 
    --arch x86_64 \                                                                                       
    --test run-them-all \                                                                                 
    --context "force=yes" \                                                                               
    --plan /plans/all

Run locally: Just use the try-all.sh binary from the test, no requirement needed, run:

curl -sSLO https://forge.fedoraproject.org/quality/fmf-tests/raw/branch/main/system-in-use/run-them-all/try-all-binaries-help-options.sh && bash try-all-binaries-help-options.sh

My results: Testing Farm Artifacts (Fedora 44 RC compose 1.3, ~950 binaries tested)

What I Found

grub2-mkrescue (bootloader utilities), perl (half the system depends on it), eqn from groff (man pages break without it).

What coredumpctl caught:

TIME                           PID UID GID SIG     COREFILE EXE                      SIZE
  Mon 2026-04-20 12:08:09 UTC  52378   0   0 SIGABRT present  /usr/bin/edgepaint      80.7K               
  Mon 2026-04-20 12:08:22 UTC  58926   0   0 SIGSEGV present  /usr/bin/eqn            57.8K
  Mon 2026-04-20 12:08:41 UTC  77687   0   0 SIGSEGV present  /usr/bin/gdbm_dump      23.9K               
  Mon 2026-04-20 12:09:01 UTC  97901   0   0 SIGSEGV present  /usr/bin/grub2-mkrescue 64.7K
  Mon 2026-04-20 12:09:08 UTC 106904   0   0 SIGSEGV present  /usr/bin/gtshapprox     48.3K               
  Mon 2026-04-20 12:10:15 UTC 161697   0   0 SIGABRT present  /usr/bin/perl5.42.1       94K

Breakdown:

  • edgepaint (graphviz) – 4× SIGABRT
  • gtshapprox (graphviz) – 3× SIGSEGV
  • perl – 4× SIGABRT
  • eqn (groff) – 1× SIGSEGV
  • gdbm_dump (gdbm) – 1× SIGSEGV
  • grub2-mkrescue (grub2) – 1× SIGSEGV

Reproducers

Run it on your side to see the reproducers in action. I’m curious to hear your thoughts on these major findings.

MY CRASHES:
COMMAND: /usr/bin/edgepaint -s -o --random_seed --angle --lightness -v --accuracy --share_endpoint 
COMMAND: /usr/bin/edgepaint -v -s --accuracy --color_scheme -o  /root/fuzz_lab/empty.dat
COMMAND: /usr/bin/edgepaint --share_endpoint -o --angle -v -s --random_seed --accuracy --color_scheme  -
COMMAND: /usr/bin/edgepaint -s --lightness --share_endpoint -o -v --angle --random_seed 
COMMAND: /usr/bin/efibootdump --guid -g -f  /root/fuzz_lab/large.dat
COMMAND: /usr/bin/eqn -C -f -M -d -v -m -T -s  /root/fuzz_lab/fake.png
COMMAND: /usr/bin/gdbm_dump --format  -
COMMAND: /usr/bin/grub2-file --is-x86-knetbsd  /root/fuzz_lab/longline.txt
COMMAND: /usr/bin/grub2-file --is-x86-knetbsd  /root/fuzz_lab/bad.json
COMMAND: /usr/bin/gtshapprox --flat -c  /root/fuzz_lab/fake.jpg
COMMAND: /usr/bin/gtshapprox -v -f --verbose -c  /root/fuzz_lab/cmd.txt
COMMAND: /usr/bin/gtshapprox -n -h --flat -l --closed -v  /root/fuzz_lab/gzip.dat
COMMAND: /usr/bin/gtshapprox --flat --number --log --cost --closed  -
COMMAND: /usr/bin/gtshapprox --log -l -f --keep  -
COMMAND: /usr/bin/mkfs.xfs -q  /root/fuzz_lab/bad_utf8.txt
COMMAND: /usr/bin/mkfs.xfs -K -L -m  /root/fuzz_lab/paths.txt
COMMAND: /usr/bin/perl -V -F -T -S -u -p -f -E -W -I  /root/fuzz_lab/bad.json
COMMAND: /usr/bin/perl -F -e -n -a -l -u -c  -
COMMAND: /usr/bin/perl -S -u -s -E -I -l 
COMMAND: /usr/bin/perl -s -p -n -u -D -E -d 
COMMAND: /usr/bin/tree -P --filelimit --matchdirs --hyperlink -i  /root/fuzz_lab/paths.txt

Look, these are edge cases. Nobody’s actually running edgepaint --wtf malformed.json in prod. But segfaults are segfaults – the binary should bail with “invalid option” or “bad input”, not dump core.

Now What?

So I’ve got a pile of crashes. Some in critical components. All reproducible.

File bugs for all of them? That’s a lot of BZ tickets for “yes hm this crashes if you feed it random garbage with weird flags”. Developers have better things to do.

Ignore them? They’re real bugs. And some of these are in grub2 and perl – not exactly throwaway packages.

Still figuring that out.

My Dilemma During Testing on Fedora 44 RC compose 1.X

The post Throwing Random Arguments at System Binaries: Real Segfaults vs. Ticket Noise appeared first on Fedora Community Blog.

What’s new for Fedora Atomic Desktops in Fedora 44

Posted by Timothée Ravier on 2026-04-27 22:00:00 UTC

Fedora 44 has been released! 🎉 So let’s see what is included in this new release for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).

Note: You can also read this post on the Fedora Magazine.

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. They are listed 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.

See the tracking issue atomic-desktops#10.

Removal of FUSE version 2 libraries

FUSE version 2 has been deprecated and unmaintained for a while so we have removed it from the images. In practice, this means two things:

  • If you are using AppImages, some of them may not work anymore.
  • If you are using legacy backends with Plasma Vault on Kinoite, you need to migrate your data.

See the Fedora Change and the tracking issue atomic-desktops#50.

The implications are detailed below.

AppImages and the FUSE 2 libraries

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 recommend 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 44. If you have already updated to Fedora 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.

See the Fedora Change and the tracking issue atomic-desktops#102.

What’s new in Silverblue

GNOME 50

Fedora Silverblue comes with the latest GNOME 50 release.

For more details about the changes that alongside GNOME 50, see What’s new in Fedora Workstation 44 on the Fedora Magazine.

What’s new in Kinoite

KDE Plasma 6.6

Fedora Kinoite ships with Plasma 6.6, Frameworks 6.24 and Gear 25.12.

See also What’s new in Fedora KDE Plasma Desktop 44 on the Fedora Magazine.

KDE Plasma Login Manager replaces SDDM

The brand new Plasma Login Manager replaces SDDM to provide a more integrated experience with systemd and the KDE Plasma session.

See the Fedora Change.

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.

See the Fedora Change.

What’s new in Sway Atomic

Nothing specific for this release.

What’s new in Budgie Atomic

Fedora Budgie Atomic comes with the latest 10.10.2 Budgie release. This release brings Wayland support to Budgie Atomic. See the 10.10 release announcement for more details.

What’s new in COSMIC Atomic

Fedora COSMIC Atomic comes with the latest 1.0.8 release of the COSMIC desktop. This is now considered stable.

Universal Blue, Bluefin, Bazzite and Aurora

Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora 44. Look for upcoming announcements in their Discourse.

As always, I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra media codec, out of tree kernel drivers, etc.).

What’s next

Helping us with a few nasty bugs

If you are interested 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.

Sealed Fedora Atomic Desktop bootable container images

Sealed images are now ready for testing! See the other article for all the details.

Roadmap to Bootable Containers

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 roadmap for this transition at atomic-desktops#26.

One of the tasks is to move away from our unmaintained installation ISO building scripts to the new image-builder tooling. This is planned for Fedora 45 for the ostree variants and support for Bootable Container will follow right after.

Another task is to start building the Fedora Atomic Desktops Bootable Container images using the Fedora Konflux instance.

Where to reach us

We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.

Sealed Fedora Atomic Desktop bootable container images

Posted by Timothée Ravier on 2026-04-27 22:00:00 UTC

I’m happy to announce that we have sealed bootable container images ready for testing for the Fedora Atomic Desktops!

Note: You can also read this post on the Fedora Magazine.

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.

How do I test those images?

See the instructions at github.com/travier/fedora-atomic-desktops-sealed on how to give the pre-built container and disk images a try and how to build your own.

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 work?

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:

Thanks to all the contributors that made this possible, notably (but non exhaustively) from the following projects: bootc & bcvk, composefs & composefs-rs, chunkah, podman & buildah and systemd.

Announcing Sigrún (Run a command)

Posted by Andreas Schneider on 2026-04-27 12:15:56 UTC

Some time ago I used a feature in KDE called “Run a command” when an event triggered. It triggered for me when a calendar event fired and used Piper TTS to read the event to me out loud. A small popup and a pling don’t work for me.

I tried to get the feature back into KDE, but since the merge request isn’t going anywhere and people don’t give details how to implement it correctly I wrote Sigrun now. It is named after a Norse Valkyrie and is short for Signal Run.

It is a systemd service running as a user and listening on DBus signals. Once it finds a configured one, it runs its command. The desktop doesn’t matter.

Here is the rule that reads my calendar reminders aloud via kde-tts.py:

[[rule]]
name = "calendar-tts"

[rule.event]
type = "notification"

[rule.filter]
app_name = "kalendarac"
summary = "Meeting.*"

[rule.filter.hints]
"x-kde-eventId" = "reminder"

[rule.action]
command = "/usr/local/bin/kde-tts.py"
args = ["-t", "{summary}", "-d", "{body}"]

Overdue updates

Posted by Hatlas FDWG on 2026-04-27 08:00:00 UTC

I’ve not updated this space in quite some time as I am still discovering new opportunities and obstacles within the problem space. Plus, my priorities tend to shift based on whomever is around and offering to help, which is noise I try to avoid propagating.

However, I do generally try to produce weekly(-ish) status updates in the Matrix channel, and I’ve decided to start providing something similar here since I do see some hits against the RSS feed.

Personal note: I’m still unemployed #

Sorry for the interruption, but if you’re aware of any Sr. / Staff SRE or SWE roles, especially those with a focus on open data and/or open source, please reach out.

Alternatively, if you might be able to contribute to any of the hosting costs for Hatlas (roughly $100/mo), I have several options available:

Major changes since November #

Pause on the cutting edge of Iceberg #

Lakehouse architecture and specifically Iceberg is what drew me to launch this project in the first place. This data model is simultaneously far more flexible than the alternatives while also being at least one order of magnitude cheaper – likely several. The cost savings aspect is especially what drew me in this direction, because this puts medium- to large-scale analytics within the budget of a hobbyist or cost-conscious non-profit.

I still believe in this direction, but I’ve had to pause these efforts temporarily because Apache Polaris (which is not the only Iceberg REST solution, but certainly the most prominent and the most promising) only fully supported AWS S3, not any other “S3 compatible” storage. AWS S3 is terribly expensive compared to basically all other options, so non-AWS support was and continues to be critical to our story.

I launched the Hatlas lakehouse shortly after support for non-AWS S3 buckets landed on the Polaris main branch. This actually worked just fine with pyiceberg, which is what our POC Jupyter notebook used. However, I had perhaps gotten ahead of myself because I quickly realized that no other client / query engine knew how to handle this configuration. This meant that I had exactly one tool with which to manage the Lakehouse, including tasks such as data maintenance, which pyiceberg wasn’t really built for.

We now had the inverse of all of our design goals: we had a single working client, and our costs would quickly rise without a process to clean out stale data. Meanwhile, we had experienced analysts who were waiting in the wings and eager to get moving, and they couldn’t connect using their tools of choice.

I made the difficult (for me) decision to temporarily pull the plug on the Iceberg approach and adopt an interim solution which is far more traditional and will deliver more immediate value.

Postgres is dead, long live Postgres #

We had two experienced analysts who were basically sitting idle, both of whom knew Postgres well, and our source data is in Postgres anyway, albeit very poorly-optimized. I decided to accept the idea of doing traditional “everything in Postgres” analytics for now.

I granted trusted members of FDWG direct access to the Hatlas Datanommer replica, but first we needed to perform some optimizations in order to make this work feasible. Upstream has json blobs stored as text, which meant that every query had to json-parse every single row, which took basically forever. Additionally we have a “topic” column which fits very naturally with Postgres' ltree type, and almost every query includes a topic WHERE clause.

It took me a few weeks to figure out the best approach for this because A) I’m not a Postgres expert, and B) nothing with this dataset is easy. For example, some of our JSON blobs are larger than the hard-coded maximum size that Postgres can parse before it gives up. We also have blobs that contain JSON nulls, which Postgres blows up on. You have to handle these errors and others in several different ways in order to have a process that can work through the whole dataset, plus I wanted to ensure that our approach would continue to work as we ingest new data.

Once I had a process, I had to run it across the entire dataset. And this is where you become a Postgres expert, because getting this to run well required knowledge of most of the Postgres tunables plus btrfs optimizations. I was figuring this out as I went, so overall the full conversion for both data types took an entire calendar month! This is because the database is large enough that it doesn’t fit on any nvme or ssd storage available to me, and you need to really understand Postgres internals in order to optimize for HDD head seek times. I think that if I were to run this again it would take significantly less time with the tuning applied, and it would probably only take hours if I had a large nvme volume. I guess I can say I’m a DBA now though!

The optimizations turned out to be worth it: queries against json fields are now 36x faster, and queries against topic are now 2x faster! We finally have a database that is feasible for analytics! (Even though it’s far from optimal.)

This puts us into position to start considering how we want to transform this data, and we can start building these transformation pipelines with tools that will translate directly to Iceberg later e.g. SQLMesh.

Unfortunately, this work was completed just in time for both of our “rockstar” analysts to pull back from their Fedora contributions :(. One had a career change and the other had a major life change, all of which is totally understandable. Hopefully we’ll see their return as they settle into their new normal, and hopefully we’ll continue to see new curious onlookers joining our Matrix channel.

WIP: Shared foundations #

I continue to focus on building out the foundations that we need for a multi-tenant and open-infra analytics environment:

On the data side #

  • I’m working upstream with Fedora Infra on several critical aspects of this work. For example:

    • Upstream Datanommer (our main dataset) is now producing nightly exports so that our replica can stay in sync.
    • I’m also working to get ssh git access enabled on Fedora Forge, which is Fedora’s new ForgeJo-based home, as that is critical to my workflow and it is the only thing preventing me from moving the Hatlas code repos out of my personal Codeberg.

  • We finally have a simple and reliable path to produce a canonical dataset in Parquet (via pg_parquet). This is available for FDWG members.

    • Some test queries against a local dataset with DuckDB are astoundingly fast – sometimes 1000x faster than Postgres. To me, this further validates the Lakehouse path.

  • I’ve designed and implemented a PII-protection scheme (currently only implemented in Postgres but applicable elsewhere), whereby our transformations from “barely-queryable data” into “ideal analytical data” also separate out identifiers (PII) into privileged tables.

    • This means that as our transformation pipelines improve, we will be able to implement a very low bar for access to analytics work while retaining a high minimum level of trust for access to PII.
    • More details in a future update.

  • I’ve started creating a data dictionary to capture all of my / our accumulated knowledge about Datanommer’s data.

    • These facts exists elsewhere but are spread across many different repos and technologies, and even if we could somehow ingest them alll we would still have an incomplete understanding of our data.
    • Building this dictionary is laborious work, and slightly fragile since updates elsewhere will need to be manually propagated to the dictionary. The upshot is that we can build tools that fully understand our dataset, which is needed for:

  • I’ve started building some prototype data transformation pipelines in SQLMesh.

    • These accomplish the transformations I think we need, although the current pipelines were built by hand as a POC.
    • I’m WIP with building a data-driven SQLMesh pipeline generator, which will (re)build all pipelines from the data dictionary. It should then be trivial to orchestrate these pipelines based on the same dictionary.

  • The data dictionary includes a rudimentary taxonomy of user actions.

    • This is nothing short of an attempt to classify all human activity on Fedora, in part to ensure that all such activities are actually being captured.
    • I’m hoping to eventually run my version past the academic-types in this space such as those within CHAOSS, as any taxonomy will have a tendency towards being highly-subjective and localized to one’s personal view on the project.
    • I’m foolishly hopeful that that the collaboration necessary to get this formalized will actually act as a form of knowledge capture to help people see the Fedora project more holistically. (Including myself!)

  • We have many different use cases for analyzing http traffic: the docs team wants to know which docs are most- / least-popular, infra wants to know which ASNs are driving our DDOS traffic, etc.

    • I made a POC of ingesting apache logs into Clickhouse and enriching them with geospatial data while also pseudonymizing them, and then analyzing with Grafana.
    • The results were promising, but the data sets here are large enough that hosting hot data on Hatlas would potentially conflict with our other pursuits. I’ve dropped this for now, but I plan to return if/when we get our Lakehouse back on track.

On the infra side #

  • I’ve continued to flesh out our bare-metal Kubernetes deployment with an eye towards multi-tenant access.

    • Much of the tech debt from “this is my throwaway dev environment” has been cleaned up, and we now have basic security measures in place such as NetworkPolicies and SSO.

  • The cleaned-up infra code helped me migrate from OVHCloud to Hetzner to reduce costs by about 40%.

  • The Docker work to upgrade and run our Datanommer replica is now shared and documented.

  • I’m working on refactoring my infra-as-code (e.g. ArgoCD repos) further so that anyone in FDWG will be able to make a PR against our analytics tooling.

    • The goal is to fully open up all Hatlas infra code and throw open the gates to FDWG as a project bigger than myself.

  • Polaris is due for a revisit.

    • When I paused the Polaris POC, v1.3 was still unreleased. That version finally came out while I was still in the depths of the Postgres optimizations, and v1.4 just came out a few days ago. Time to try again!

On the policy side #

  • Since I’ve not received any traction from RedHat Legal, I’ve asked my favorite non-lawyer Claude Opus to review our GDPR stance.

    • In short, the broad strokes of what we’re doing are well within GDPR but we have some policy updates and technical controls which need to be freshened up since Fedora last made its big GDPR push in 2018.
    • These are WIP both upstream in coordination with Fedora leadership and within Hatlas.

  • The biggest user-visible portion of this is that we need to enact an access gate for FDWG analysts.

    • This is what I’m currently focused on, both at the policy and infra level, and I have not updated any of the data on Hatlas since receiving this advice.

This was … long. Sorry about that. I’m impressed that you actually read this! I will try to keep future updates much shorter. This means that they will be less concrete / more tentative in tone. I need to become ok with that :)

A git sign bug

Posted by Kushal Das on 2026-04-26 08:58:55 UTC

While working on the new git signing feature for tumpa-cli I noticed that some of the commits can not be verified. For a moment I freaked out and then thought it must be a problem in my code. But, I could not dig enough. Opus 4.7 helped me to find the eaxct commit in git's history and a reproducer. I reported the issue to the maintainers and they are working on a fix.

\xc2\xa7 aka § was the cause for me.

msg.txt bodysign stdin (tee'd)stored commit bodyverify
git 2.43 (host)... 20 a7 0a... 20 c2 a7 0a... 20 c2 a7 0aOK
git 2.53 (CI, docker)... 20 a7 0a... 20 a7 0a... 20 c2 a7 0aBAD

git 2.43 transcoded the message to UTF-8 BEFORE calling the signer; signer and storage saw the same bytes (c2 a7). git 2.53 hands the signer the RAW bytes (a7) and transcodes only on the way to the commit object (c2 a7). The invariant "bytes fed to gpg.program at sign time equal the bytes a verifier sees when it reads the commit back" is broken.

git config i18n.commitEncoding iso-8859-1 is supposed to be the configuration if we have non UTF-8 characters. But, I never knew about this configuration before I found the bug.

I want to thank my friends in Anthropic for letting me use the tools and techonology to keep building.

© 2016 Red Hat, Inc. and others. Please send any comments or corrections to the websites team.

The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content.

Your words are your own, duh. Nothing here represents Fedora™, Red Hat, Inc, or pretty much anything else. If you think it does then you are badly misled