Fedora People

Fedora Community Blog: Community Update – Week 20

2026-05-15T15:09:12+00:00

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

W2FM GitHub hook takeover [Followup]
chore(deps): update Fedora Minimal docker tags [Commit A] [Commit B]
Make a refreshed deployment to the production environment [Commit]
mdapi: fix image trigger annote order on deploy metadata [Commit]
Add Red Hat Summit 2026 badge artwork [Merged] [Followup] [Badge] [Auth]
Deal with s390x outage
Cleaning script for communishift
Critical error in IPA from ipa-healthcheck
Request for resources – large sized aws arm64 VM with public IP for Forge runners
Revert CVE-2026-31431 (“copy fail”) mitigations when EL 9 kernel is updated
Add jgroman to sysadmin-qa and hook sysadmin-qa up to appropriate things
Move OpenShift apps from deploymentconfig to deployment

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.

Incorrect commit display for some PRs [Triaged] [Followup A] [Followup B]
Ensure moving all commits in a pull request [Commit] [Followup]
[v15.0/forgejo] [pagure] ensure moving all commits in a pull request [Reviewed]
Fedora-infra tenant created on the new konflux cluster
Forge and Distgit Applications and Components onboarding to the Konflux tenant
Dirtyfrag exploit mitigated on all runnerhost VMs
Forge Staging updated to v15.0.1
[docs] We finally got a separate “archive” org so we’ll get it set up and start migrating the about 40 ancient repos there
Zabbix Proxy running inside openshift now has a playbook and role to deploy and configure.

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.

Fedora Magazine: How Fedora is responding to recent Kernel vulnerabilities

2026-05-15T14:40:13+00:00

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!

Kamil Páral: Heroes of Fedora Quality for Fedora 44

2026-05-15T08:46:46+00:00

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

Name	Test cases executed	Referenced bugs¹
derekenz	468	2365456 2438905 2444046 2448211 2456542 2458714 (6)
lruzicka	132	2442593 2442988 2444078 2458907 (4)
geraldosimiao	132	2444046 (1)
psklenar	112
kparal	106
nielsenb	81	2442689 2448757 (2)
aggraxis	70
jlinton	58	2183626 2402621 2444775 2444776 2457333 2457336 (6)
robatino	56
jcline	36
abhis3k	35
xariann	20
osalbahr	19
jgroman	15
pboy	15
ahmedalmeleh	9
korora	8
adamwill	5	2448283 2453216 (2)
supakeen	3

¹ 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

Name	Bug reports submitted¹	Excess reports²	Accepted blockers³
Lukas Ruzicka	20	9 (45%)	1
Petr Sklenar	16	1 (6%)	1
Adam Williamson	9	1 (11%)	2
Steven Hollingsworth	9	0 (0%)	0
Steve Cossette	7	0 (0%)	0
Kamil Páral	6	1 (17%)	0
Mr. Beedell, Jared Richard William	5	0 (0%)	0
Akira TAGOH	4	1 (25%)	0
Jeremy Linton	4	1 (25%)	0
lpavan at redhat.com	4	0 (0%)	0
Neal Gompa	4	0 (0%)	0
Adrian Vovk	3	0 (0%)	0
gav at gavworld.co.uk	3	0 (0%)	0
Laurențiu Nicola	3	0 (0%)	0
Matt Fagnani	3	0 (0%)	0
Osama Albahrani	3	0 (0%)	0
Than Ngo	3	0 (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

Name	Bug reports submitted¹	Excess reports²	Accepted blockers³
Davide Repetto	18	1 (6%)	0
Petr Sklenar	18	2 (11%)	0
Fabio Valentini	12	0 (0%)	0
Kamil Páral	11	5 (45%)	1
Adam Williamson	10	0 (0%)	3
Ricardo Ramos	7	0 (0%)	0
Lukas Ruzicka	6	1 (17%)	1
Matt Fagnani	6	0 (0%)	0
Calum Chisholm	5	0 (0%)	0
lray+redhatbugzilla at mailbox.org	5	0 (0%)	0
Andrey Motoshkov	4	0 (0%)	0
Artem S. Tashkinov	4	1 (25%)	0
Brian Morrison	4	0 (0%)	0
Chang Qian	4	0 (0%)	0
Derek Enz	4	2 (50%)	0
Dominic	4	0 (0%)	0
iltis at posteo.de	4	0 (0%)	0
Jan Macku	4	0 (0%)	0
Jeremy Nickurak	4	0 (0%)	0
kxra at riseup.net	4	0 (0%)	0
Luke	4	0 (0%)	0
Mr. Beedell, Jared Richard William	4	0 (0%)	0
Steven Hollingsworth	4	0 (0%)	0
tk2345_ at outlook.com	3	0 (0%)	1
Alan Altmann	3	1 (33%)	0
anotheruser	3	0 (0%)	0
Cristian Ciupitu	3	0 (0%)	0
Eugene Mah	3	0 (0%)	0
Jonathan S.	3	0 (0%)	0
speedlemma at gmail.com	3	2 (67%)	0
Steve Cossette	3	0 (0%)	0
…and also 221 other reporters who created less than 3 reports each, but 252 reports combined!

¹ 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.
² 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.
³ 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 commented¹: 1428

Name	Updates commented
Geraldo S. Simião Kutz (geraldosimiao)	307
Filipe Rosset (filiperosset)	185
Eugene Mah (imabug)	98
Derek Enz (derekenz)	88
anotheruser	78
bojan	71
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
ramot	24
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
markec	5
…and also 116 other testers who commented on less than 5 updates each, but 165 comments combined!

¹ If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.

Test days participation

Test Days are events which are partly focused on testing Changes planned for an upcoming Fedora release, but they also regularly test important areas of the Fedora distribution, like upgrades, internationalization, graphical drivers, desktop environments, kernel updates, and others. The upcoming and past events can be seen in our Testdays app.

Test period: Fedora 44 branch time – Fedora 44 Final release
Contributors: 98
Test cases executed: 698

Name	Test cases executed
lpavan	42
mcrha	36
adriend	34
tagoh	27
pnemade	23
16levels	23
lruzicka	17
stransky	16
michal odehnal	16
pschindl	15
jgrulich	15
alciregi	15
psklenar	12
dkricka	12
jpb21	12
romangherta	12
royboy626	11
twinkle28	11
vhumpa	11
alangm1001	11
pyadav	10
rduda	10
paolojr	10
dtunma	10
bittin	9
pauloheaven	9
jgroman	8
derekenz	8
gornikfan	8
tdawson	8
vsembiba	8
mkasik	8
clnetbox	8
mzink	8

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

We sincerely thank all contributors!

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

Ben Cotton: Every project has politics

2026-05-14T12:00:00+00:00

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.

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

2026-05-14T11:46:57+00:00

Fedora Community Blog: F44 election nominations now open

2026-05-13T20:38:01+00:00

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

Fedora Engineering Steering Committee (FESCo) (5 seats)
Fedora Council (2 seats)
Fedora Mindshare Commi t tee (4 seats)
EPEL Steering Committee (3 seats)

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.

Rénich Bon Ćirić: Gratamente sorprendido con gemini-3.1-flash-lite-preview

2026-05-13T16:00:00+00:00

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

Fedora Magazine: Log Detective in Packit

2026-05-13T08:00:00+00:00

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 Framew ork.

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 Magazine: Fedora Hummingbird: Taking the Hummingbird model to the full operating system

2026-05-12T12:00:00+00:00

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 Q u ay
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.

Fedora Infrastructure Status: Restart of database server @ Copr Frontend

2026-05-12T11:00:00+00:00

Michael Catanzaro: Flatpak Sandbox Escape via Yelp

2026-05-11T14:12:53+00:00

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.

Kevin Fenzi: misc fedora bits first week of may 2026

2026-05-09T17:30:29+00:00

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

Fedora Community Blog: Community Update – Week 19 2026

2026-05-08T10:00:00+00:00

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

OpenShift Allowing Project Creating Despite Missing Relevant Permissions
mirrormanager app no longer builds
Monitoring of Varnish in Zabbix
Decomission Ipsilon OpenID instance
Copyfail: updated and rebooted key Fedora hosts, applied kernel team recommended mitigation on key EL 9 hosts

CentOS Infra including CentOS CI

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker

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.

The prototype AI Developer Desktop has been rebased to Fedora 44, and the associated Remix kernel with NVIDIA OpenRM has been rebased to 6.18.

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.

Fedora QE Pagure -> Forge migration is now fully complete. The new version of Blockerbugs (that uses Forge instead of Pagure for blocker discussion tickets) is now deployed to production.
Caught an issue with kernel module signing in ELN
Ongoing openQA test development work
Kernel test week testing
Starting work on reviving the contribution statistics scripts and communications
Some communications around copyfail, reassuring folks that it was addressed day 0 in Fedora

Forgejo

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

Runnerhost zabbix agent updated with encryption
Forge v15 running on staging instance
Privileged and unprivileged aarch64 runners tested on staging, requested larger VM
Runnerhost VM’s kernel version updated to 6.19.14 to counter the CVE
Handful of new orgs added

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 FDWG: Hatlas News: 2026-05-08

2026-05-08T08:00:00+00:00

Remi Collet: 🛡️ PHP version 8.1.34, 8.2.30, 8.3.29, 8.4.16, and 8.5.1

2025-12-19T09:39:00+00:00

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:

Fedora Rawhide now has PHP version 8.5.1
Fedora 43 - PHP 8.4.16
Fedora 42 - PHP 8.4.16

⚠️ 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)

Remi Collet: ⚙️ PHP version 8.4.20 and 8.5.5

2026-04-10T05:48:00+00:00

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:

Fedora Rawhide now has PHP version 8.5.4
Fedora 44 - PHP 8.5.5
Fedora 43 - PHP 8.4.20
Fedora 42 - PHP 8.4.20

⚠️ 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)

Remi Collet: 🛡️ PHP version 8.2.31, 8.3.31, 8.4.21 and 8.5.6

2026-05-08T05:52:00+00:00

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:

Fedora Rawhide now has PHP version 8.5.6
Fedora 44 - PHP 8.5.6
Fedora 43 - PHP 8.4.21
Fedora 42 - PHP 8.4.21

⚠️ 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)

Fedora Badges: New badge: Red Hat Summit 2026 !

2026-05-08T02:54:50+00:00

Christof Damian: Friday Links 26-16

2026-05-07T22:00:00+00:00

Stephen Gallagher: Sausage Factory: Fedora ELN Rebuild Strategy (2026 Edition)

2026-05-07T18:03:40+00:00

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 most¹ 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 second² side-tag (call it the “errata tag”). EBS then tags all of the successful package builds from the batch into this new errata tag. This ensures that the tag contains only the new ELN builds and none of the Rawhide packages that were tagged into the build tag. From there, EBS talks to Bodhi via its public API and requests that a single Bodhi update erratum be created for all of the packages in this errata tag. This is done to reduce the load on Fedora QA, as the infrastructure there is far better equipped to deal with a single update of a few hundred packages than it is with a few hundred separate updates.

At this point, the batch is complete and EBS moves on to preparing another batch, if there are packages waiting.

History

In its first incarnation, ELNBuildSync (at the time known as DistroBuildSync) was very simplistic. It listened for tag events on Rawhide, checked them against its list and then triggered a build in the ELN target. Very quickly, the ELN SIG realized that this had significant limitations, particularly in the case of packages building in side-tags (which was becoming more common as the era of on-demand side-tags began). One of the main benefits of side-tags is the ability to rebuild packages that depend on one another in the proper order; this was lost in the BuildSync process and many times builds were happening out of order, resulting in packages with the same NVR as Rawhide but incorrectly built against older versions of their dependencies.

Initially, the ELN SIG tried to design a way to exactly mirror the build process in the side-tags, but that resulted in its own new set of problems. First of all, it would be very slow; the only way to guarantee that side-tags are built against the same version of their dependencies as the Rawhide version would be to perform all of those builds serially. Secondly, even determining the order of operations in a side-tag after it already happened turned out to be prohibitively difficult.

Instead, the ELN SIG recognized that the Fedora Rawhide packagers had already done the hardest part. Instead of trying to replicate their work in an overly-complicated manner, instead the tool would just take advantage of the existing builds. Now, prior to triggering a build for ELN, the tool would first tag the current Rawhide builds into ELN and wait for them to be added to the Koji buildroot. This solved about 90% of the problems in a generic manner without engineering an excessively complicated side-tag approach. Naturally, it wasn’t a perfect solution, but it got a lot further. (See below for “Why are some package not tagged into the batch side-tag?” for more details.

A more recent modification to this strategy came about as CentOS Stream 10 started to come into the picture. With the intent to bootstrap CS 10 initially from ELN, tagging Rawhide packages to the ELN tag suddenly became a problem, as CS 10 needs to use that tag event as its trigger. The solution here was not to tag Rawhide builds into Fedora ELN directly, but instead to create a new ELN side-tag target where we could tag them, build the ELN packages there and then tag the successful builds into ELN. As a result, CS 10 builds were only triggered on ELN successes.

In late 2025, Fedora QA came to the ELN SIG and requested that we find some way to reduce the number of individual errata we were generating, as when they attempted to turn on automated testing for ELN, the result was an overload and significant queuing around mass-rebuilds and other large batches. When it got to the point that the Standard Operating Procedure for mass-rebuilds included disabling all the tests for ELN, it became clear that changes were needed and EBS was modified to start directly requesting errata for all the builds in the batch instead.

Frequently Asked Questions

Why does it sometimes take a long time for my package to be rebuilt?

Not all batches are created equal. Sometimes, there will be an ongoing batch with one or more packages whose build takes a very long time to complete. (e.g. gcc, firefox, LibreOffice). This can lead to up to a day’s lag in even getting enqueued. Even if your package was part of the same batch, it will still wait for all packages in the batch to complete before the tag occurs.

As of this writing, we are currently investigating having certain extremely large packages built and tagged directly and without batching in order to shorten the average batch time.

Why do batches not run in parallel?

Simply put, until the previous batch is complete, there’s no way to know if a further batch relies on one or more changes from the previous batch. This is a problem we’re hoping might have a solution down the line, if it becomes possible to create “nested” side-tags (side-tags derived from another side-tag instead of a base tag). Today however, serialization is the only safe approach.

Why are some packages not tagged into the batch side-tag?

Some packages have known incompatibilities, such as libllvm and OCAML. The libraries produced in the ELN build and Rawhide build are API or ABI incompatible and therefore cannot be tagged in safely. We have to rely on the previous ELN version of the build in the buildroot.

Why do you not tag successes back into ELN immediately?

Despite the fact that we do not block ELN builds going to the stable repository based on test results, we do want to know about and address any issues revealed. Many packages are interdependent and it’s far simpler to test the result of all the builds collectively, once we know they have all been rebuilt.

There are certain packages that we exclude from this so that the Rawhide package is not used in the ELN buildroot; see the skip_tag section of the configuration file for the current set. ︎
In the case of very large batches (such as mass-rebuilds), the set of packages may be split into more than one Bodhi update, to avoid in overtaxing things. ︎

Fedora Community Blog: Community Update – Week 18, 2026

2026-05-06T14:37:01+00:00

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

Week: 27 April – 01 May 2026

Fedora Infrastructure

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

Put risc-v Koji behind anubis and tightened its robots.txt to mitigate a scraper flood
Somehow managed to keep the lights on with Kevin on PTO, teamwork win!
Status.fpo webpage does not pickup status changes merged into status github repo
Signing problem with the latest rawhide kernels
vmhost-x86-copr04 rebooting

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

ELNBuildSync is unable to connect to Fedora Messaging
Add GenericCloud images tests on testing.stream.centos.org
Please add ogajduse to ocp-cico-foreman
Fix openshift underlying issue (investigate) and upgrade
Replace sigs.centos.org infra with el10 host
Modernize centos mirror network CDN
Create an “ansible-init” tool or container

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker

Release of Fedora 44 and torrents.
Automation works for Mass Branching Bits.
Unretirement workflow is now being processed from the fedpkg command; I found one bit to solve, which is being worked on.
Samyak is trying to solve the dependency checker, which didn’t account for alternative providers and rich dependencies.

RISC-V

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

F44 rebuild update (community work): 60% of rebuild is done so far. (This is expected as we’re with reduced Koji builders for a little while.)
LLVM related debugging (this is slow-grind work)
- Started a local rebase of my Fedora LLVM patches in my fork. I still have to test it on P550 and submit for review. The builds are time-consuming; it’ll be a background task over the week.
- Resumed debugging ‘libomp’ test suite failures. Setup an environment on DP1000.
Explored what it takes to create a shadow Koji instance for RISC-V that tracks Rawhide. DavidA already tried several years ago and had to drop it due to deep-sync issues; there are some workarounds to deal with it today. (Half-baked ideas: we could write an updated koji-shadow but it’s time-intensive. Experiment with a local copy, we don’t want to mess with the active RISC-V Koji instance. (Also needs a capable “volunteer” with time to try this out.)
Investigated and ordered an eGPU (external GPU) docks; last time I looked the one we needed was out of stock. Luckily one came back in stock. This dock helps us drive Tenstorrent’s AI accelerator card.

QE

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

Executive summary: F44 signed off and released, LFNW, blockerbugs forgejo migration and test enablement work
Fedora 44 released, Lots of common issues notes written
awilliam attended LinuxFest Northwest (with brendan, carl and gordon), gave a well-attended talk on root-causing theory and practice – video, slides , did booth duty
PR to add openQA test of installing with a kickstart containing a non-existent package is blocked because anaconda handling of this is currently broken, anaconda team working on a fix
Blockerbugs port to Forgejo is merged, deployed to staging and undergoing testing
Kernel 7.0 Test Week now running (till May 1)
Provided testing support for Silverblue migration to image-builder
Various investigations and tweaks related to ELN moving to a new release package with several changes in behavior and bugs

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.

Fedora Infrastructure Status: s390 builder outage

2026-05-06T12:00:00+00:00

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

2026-05-06T11:28:09+00:00

Remi Collet: 🎲 PHP version 8.4.21RC1 and 8.5.6RC1

2026-04-24T04:58:00+00:00

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)

Fedora Community Blog: Join Us for Podman 6.0 Test Days – May 11-15, 2026

2026-05-05T11:56:11+00:00

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:

Visit Podman 6.0 Test Days wiki and find links to rawhide iso and test cases.
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.

Fedora Infrastructure Status: Restart of Copr servers

2026-05-05T10:00:00+00:00

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

2026-05-04T08:00:00+00:00

Marcin Juszkiewicz: New Fedora package: fedora-active-user

2026-05-04T06:37:00+00:00

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

Kevin Fenzi: misc fedora bits last of april 2026

2026-05-02T17:41:55+00:00

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

Akashdeep Dhar: Loadouts For Genshin Impact v0.1.16 Released

2026-05-01T18:30:56+00:00

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.

Linnea - Workspace and Results

Weapons

One weapon has debuted in this version release.

Golden Frostbound Oath - Workspace

Appeal

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

Disclaimer

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

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

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

Hatlas FDWG: Hatlas News: 2026-05-01

2026-05-01T08:00:00+00:00

Christof Damian: Friday Links 26-15

2026-04-30T22:00:00+00:00

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

2026-04-30T21:05:07+00:00

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

Vojtěch Trefný: Libblockdev 3.5.0 released

2026-04-29T09:25:00+00:00

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.

Brian (bex) Exelbierd: Things I Read: 16-29 April 2026

2026-04-29T07:40:00+00:00

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 Magazine: Fedora Asahi Remix 44 is now available

2026-04-28T14:05:33+00:00

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.

Fedora Magazine: What’s New in Fedora KDE Plasma Desktop 44

2026-04-28T14:04:00+00:00

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 R eady 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.

Fedora Magazine: Sealed Fedora Atomic Desktop bootable container images

2026-04-28T14:03:00+00:00

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.

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

2026-04-28T14:02:00+00:00

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 Ch ange.

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.

Atomic Desktops SIG: Organization on Fedora’s Forge, #atomic-desktops:fedoraproject.org
Silverblue: Workstation Working Group, #silverblue:fedoraproject.org
Kinoite: KDE SIG, #kinoite:fedoraproject.org
Sway Atomic: Sway SIG, #sway:fedoraproject.org
Budgie Atomic: Bud g ie SIG, #budgie:fedoraproject.org
COSMIC Atomic: COSMI C SIG, #cosmic:fedoraproject.org

Fedora Magazine: How to Rebase to Fedora Linux 44 on Silverblue

2026-04-28T14:01:00+00:00

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

Fedora Magazine: What’s New in Fedora Workstation 44

2026-04-28T14:00:00+00:00

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 n otes.

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!

Fedora Magazine: The Fedora Linux 44 Release is Here!

2026-04-28T13:59:00+00:00

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!

Peter Czanik: Support for OpenSSL 4.0?

2026-04-28T13:20:56+00:00

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

2026-04-28T12:00:00+00:00

Why Would Anyone Do This?

Two and half reasons:

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

Grab all binaries from /usr/bin and /usr/sbin
Parse --help for flags (--whatever, -x, you know the drill)
Pick random combos of those flags (1-4 per run)
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.

Timothée Ravier: What’s new for Fedora Atomic Desktops in Fedora 44

2026-04-27T22:00:00+00:00

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

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.

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)

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.

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.

Atomic Desktops SIG: Organization on Fedora’s Forge, #atomic-desktops:fedoraproject.org
Silverblue: Workstation Working Group, #silverblue:fedoraproject.org
Kinoite: KDE SIG, #kinoite:fedoraproject.org
Sway Atomic: Sway SIG, #sway:fedoraproject.org
Budgie Atomic: Budgie SIG, #budgie:fedoraproject.org
COSMIC Atomic: COSMIC SIG, #cosmic:fedoraproject.org

Timothée Ravier: Sealed Fedora Atomic Desktop bootable container images

2026-04-27T22:00:00+00:00

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?

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.

Where can I get more details about how this work?

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.

Andreas Schneider: Announcing Sigrún (Run a command)

2026-04-27T12:15:56+00:00

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}"]

Hatlas FDWG: Overdue updates

2026-04-27T08:00:00+00:00

Kushal Das: A git sign bug

2026-04-26T08:58:55+00:00

Michael Catanzaro: git config am.threeWay

2026-04-24T22:57:22+00:00

If you work with patches and git am, then you’re probably used to seeing patches fail to apply. For example:

$ git am CVE-2025-14512.patch
Applying: gfileattribute: Fix integer overflow calculating escaping for byte strings
error: patch failed: gio/gfileattribute.c:166
error: gio/gfileattribute.c: patch does not apply
Patch failed at 0001 gfileattribute: Fix integer overflow calculating escaping for byte strings
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

This is sad and frustrating because the entire patch has failed, and now you have to apply the entire thing manually. That is no good.

Here is the solution, which I wish I had learned long ago:

$ git config --global am.threeWay true

This enables three-way merge conflict resolution, same as if you were using git cherry-pick or git merge. For example:

$ git am CVE-2025-14512.patch
Applying: gfileattribute: Fix integer overflow calculating escaping for byte strings
Using index info to reconstruct a base tree...
M	gio/gfileattribute.c
Falling back to patching base and 3-way merge...
Auto-merging gio/gfileattribute.c
CONFLICT (content): Merge conflict in gio/gfileattribute.c
error: Failed to merge in the changes.
Patch failed at 0001 gfileattribute: Fix integer overflow calculating escaping for byte strings
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

Now you have merge conflicts, which you can handle as usual. This seems like a better default for pretty much everybody, so if you use git am, you should probably enable it.

I’ve no doubt that many readers will have known about this already, but it’s new to me, and it makes me happy, so I wanted to share. You’re welcome, Internet!