/rss20.xml">
fedora

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

The Future of GNOME Boxes

Posted by Felipe Borges on 2026-08-03 11:28:49 UTC

GNOME Boxes new logo

I have spent the last two years rebuilding GNOME Boxes from the ground up, driven by three main factors. I spoke extensively about this effort in my recent Linux App Summit, GUADEC 2025 and 2026 talks, but today I am excited to share the result for general testing.

First, shifting to a Flatpak-first (and only) model. As a solo developer, maintaining code paths for countless distributions isn’t sustainable. Since Boxes acts as a frontend for libvirt/qemu, its functionality relies heavily on the backend configuration. Flatpak lets me bundle the entire virtualization stack, giving me the control I need to fine-tune it for our specific use cases.

Second, migrating Boxes to GTK4 and Libadwaita. Beyond the obvious benefits (a modern UI, better responsiveness, and tighter desktop integration) this makes the codebase significantly easier to maintain. This transition required moving away from the GTK3-based SPICE display widget, which was too tightly coupled to older input and drawing methods. We’ve replaced it with Libmks, which has proven to be a solid alternative.

Lastly, modernizing the codebase to make it sustainable for new contributors. That meant adopting modern GNOME app design patterns and rethinking our underlying architecture.

I am now ready to share this work with a wider audience. However, please keep in mind that this is a Beta release meant for testing, not for production environments. If you plan to try it out, make sure to back up any important data in your virtual machines first.

If you want to test this new implementation of GNOME Boxes, you can set up the GNOME Nightly Flatpak Repository and install it with:

flatpak install org.gnome.Boxes.Devel

This new version already covers most of what the classic Boxes could do: creating virtual machines from ISO media and disk images (qcow2), configuring VM resources, sharing clipboard content, sending files to the guest, and more.

It can install Windows 11 without any manual workarounds. Boxes configures Secure Boot and a virtual TPM device automatically. Everything required to pass the Windows 11 hardware compatibility checks out of the box. This was the most requested feature for the classic version, so I am particularly glad it is fully functional in this rewrite.

Screenshot of the new GNOME Boxes running Windows 11

As distributions shift toward image-based OSes, this Flatpak-only approach becomes even more valuable. Most other virtual machine managers rely on host services or privileged daemons that are difficult to configure on immutable systems. While hardware and host combinations vary, bundling the backend stack directly inside the Flatpak gives us a controlled baseline that we can actively support, configure, and refine over time.

Accessing VM contents used to be tricky due to Flatpak sandboxing. This version addresses that by introducing a VSOCK device to the box, allowing guests with systemd v256 or newer to be accessed directly over SSH. It also adds initial support for port forwarding, letting you reach services running inside the VM from your host.

Screenshot of a host terminal SSHing into the guest VM through VSOCK
Screenshot of a host terminal SSHing into the guest VM through VSOCK

All of this and more is detailed on our new website, nightly.gnomeboxes.org, where you can also learn how to help by testing and reporting issues.

Please keep in mind that I am working on this in my free time alongside maintaining GNOME Settings and my day-job responsibilities at Red Hat. I ask for your patience with issue responses, but I will do my best to address bugs and keep pushing feature development forward as time allows.

I love building GNOME Boxes, and I am constantly motivated by the positive feedback from our community. People appreciate Boxes because it lets them set up a VM quickly and get straight to work without needing deep knowledge of virtualization or operating system internals. That remains the core mission, and that is the user experience I want to continue building for.

A lot of this implementation will still change as I gather feedback and it matures. I have also drafted a series of follow-up blog posts to this one, which will describe and elaborate a bit more on the new features, explaining how to use them and how they have been implemented. Stay tuned!

Comments

Things I Read: 15 Jul – 03 Aug 2026

Posted by Brian (bex) Exelbierd on 2026-08-03 08:20:00 UTC

This one is a bit light. I think that reflects the craziness of the summer and how I have worked through the backlog of my Instapaper. I’ve also been reading actual books (see below) so maybe you should too :D.

People

  • Chasing life goals is a recipe for disaster – so try these tiny experiments instead

    Becoming the kind of parent you didn’t have a model for.

    These are amazing words and regardless of our actual lived experience, I think we all feel this way when we have children.

  • Communities are not fungible

    Not only are communities not fungible, but JA makes it crystal clear how they differ from person to person inside the community because they are overlapping Dunbar circles. Before I left Twitter, I remember thinking that I must be using a different Twitter from everyone else because my experience was nothing like what I was hearing about. The same is now true for me on Mastodon.

Machines and Politics

  • Opinion | The Environmental Case Against Data Centers Is Misguided

    Data centers should be held to the same environmental standards as any other project.

    Why is this even controversial? I also believe we should price consumables at the correct cost reflecting our view on their impact as well as their production. I realize this will increase costs for many, including low-income members of our society, so instead we should surface the subsidy as a real subsidy line item. People should understand what things cost and what they have received as support.

    For bonus points we can make the subsidy refundable to encourage people to conserve.

  • Hyperrealist Datacenters And Potemkin McRibs | blarg

    I like it when an article finally acknowledges the power of smaller models for many uses when talking about the LLM Data Center bubble. If you choose to use LLMs start running some experiments with non-frontier models, whether cloud hosted or local, I think you’ll be pleasantly surprised.

    While you’re reading this article, stay for the bonus McDonalds anecdotes. Per my daughter, as I am sad to admit, it has the best chicken nuggets a pork-market arbitraging real estate company can make.

  • Opinion | Is France poorer than America? You don’t have to ‘walk around’ to know.

    This is such an American question. It’s like a reverse Tucker Carlson in a Russian grocery store. You know it is hard to toe the line when the best polish you can put on this turd of a proposition is, “[rural france is also] humdrum highways rather than picturesque public transit. The European endowment of beautiful architecture feels much richer than American acreage when you’re, well, walking around. That effect is magnified by lower crime and public disorder in Europe.” But yeah, let’s talk about raw dollars baby.

Recently Finished Books

I’ve been tracking my book reading on my blog, but it never gets surfaced anywhere. I’ve decided to start including them here. Head to my reading page to find detailed notes or reactions for each book, similar in style to this post.

And finally

  • A pan that won’t let me rush dinner - Down the Road

    I’m learning that turning the burner higher doesn’t actually make dinner happen appreciably sooner. It just makes it easier to burn dinner. So I’m going to learn to go low and slow.

    I remember reading somewhere that you should almost never set a burner above medium. These days when I cook, I’m using gas :( - but low and slow has paid off. The other day I was cooking a chicken breast in our go-to nonstick IKEA skillet. I’d done basically no prep due to a child who hates flavor and hadn’t even tried to make it a similar thickness throughout. I wound up putting my skillet on too small of a burner, setting it to low, and hanging the pan half off the burner. This put the chicken on the off side recreating the indirect heat of a grill. I had juicy AF chicken. Suck it George Foreman!

Developing with Fedora, first flock, and not the last!

Posted by Fedora Magazine on 2026-08-03 08:00:00 UTC

Flock 2026 was my first Fedora conference, and it won’t be my last. I came home with new ideas, new friendships, and even a new project to work on for next year.

Appreciation

I want to start by appreciating the Flock organizers and volunteers. Putting together an event like this takes a lot of quiet, unglamorous work, and it showed in how smoothly everything ran. Thanks for that!

I’d also like to thank the event sponsors. Their support makes it possible for contributors from all over the world to come together, learn from one another, and strengthen the Fedora community.

I also want to appreciate my mentor, Jona, for pushing and supporting me until I finally made it. And a big thank you to Fedora for the sponsorship that got me there.

This year I also got to be part of the Mentor Summit organizing team myself and helped put together the very sessions I used to just attend as a newcomer. Full circle moment here 🙂

It has always felt rewarding to contribute to something I love, and Fedora has always been one of my favorite communities. Along the way, I’ve made great friends and met many wonderful people.

Finally, I’d like to thank the Nairobi GNU/Linux Users Group for supporting Fedora’s Recognition Program this year by sponsoring the trophies and keychains. It was great to see our local community play a part in recognizing Fedora contributors, and I hope it’s the beginning of a lasting tradition.

Our winners this time were; Fabio Valentini, Justin Forbes and Ankur Sinha in that order. Congratulations to you, and keep going🎉 You might want to hear from them in our podcast Fedora Contributor Recognition Program 056.

Fedora recognition winners

Diversity, Equity and Inclusion

Cornelius with Matt, Jona, and Akash, celebrating time together at Flock 2026.
Cornelius with Matt, Jona, and Akash, celebrating time together at Flock 2026.

I love how Fedora is so supportive of people from under-represented groups. Being at Flock felt like a reward for the work I’ve been doing with the community too – I had been organizing and mentoring from home. Being there in person and seeing that my work was appreciated meant a lot.

This is what I love about Fedora: it’s welcoming, and it lives by the Four Foundations every day.

I also believe the in-person inclusive checklist I worked on last year helped make this year’s event a success. I loved the venue – I guess that’s why we went back to the same place as last year. 

Honestly, I’d say everything was perfect. So hey, Flock organizers – the venue was perfect. 🙂

View of the Flock 2026 venue, which hosted the conference sessions and community activities.
View of the Flock 2026 venue, which hosted the conference sessions

The talks

There was so much to take in: design, the mentor summit, docs and the docs initiative, lessons from FOSDEM and SCaLE, and so much more.

There was also the fbrnch workshop, Fedora data and analytics, and honestly too many good sessions to list them all here.

If there’s one thing I keep learning about this community, it’s that nothing happens unless you ask. People, or I would say, I personally don’t wait to be picked here, I just find ways to engage, go deep, and just ask, ask, ask. I wanted to help with speaker logistics this year for Fedora Linux 44 release party, so while I was checking open tickets, I found it and asked if I could manage it. And I did it. I know some people might hesitate to just raise their hand like that, but Fedora is always welcoming, and honestly, we can always use the support. Get involved, it feels good to contribute to something you love.

Funny enough, a friend paid me a compliment (I think?) that I know how to navigate open-source communities and always find something to do. I’m still not sure if that’s just a “community person” thing, or if it’s because I genuinely like understanding people and learning new things. Maybe both.

Candy Swap

The candy swap – I totally loved this! Super awesome idea. Sorry to disappoint that I couldn’t find time to bring anything, but I promise I will next time.

Candies at the table.

Mentor Summit

This was the 5th edition of the Fedora Mentor Summit, and it packed a lot into a few days. Lunch & Learn sessions ran across all three days, the informal, team-themed gatherings where you could step out of your usual circle and sit with people from Docs, Infra, Marketing, Packaging, Design, wherever you wanted to learn something new. No pressure, just conversation over food.

There was also a sticker-matching icebreaker, and everyone got a Fedora mascot sticker at registration, and the game was to go find your match and have a chat with them about anything open source.

Being on the organizing side of this for the first time gave me a whole new appreciation for how much quiet coordination goes into making something feel effortless for the people attending. Read more about how Mentor Summit came together here.

Jona, Cornelius, Kevin and Peter pose for a photo during the Mentor Summit Lunch hour time.

The hallway track

This is where the real magic happens. Daniel gave a brief, informal talk about eBPF, and honestly, that conversation ended up being one of the best parts of the whole trip.

I got to connect and meet team members, make new friends, and it was exciting just to sit and learn from them in a way a formal talk doesn’t always allow.

And out of that hallway conversation, I actually found another thing to do within Fedora. I have a project I’m hoping to finish and present at the next Flock – mentored by Daniel on eBPF. (Putting this here for accountability, so you can hold me to it. 😅)

I keep meeting super kind, good Fedora friends who are willing to mentor and give their time. It says a lot about how welcoming this community really is.

Everyone I met was kind, and always down to talk about their experiences and their love for open source – and how they hope more people get to know it, try free software, and enjoy it wherever they are, in their own languages. That last part is thanks to the i18n and translation teams across open source communities, doing work that often goes unnoticed.

Being early in my career, of course I had to ask people how they got in. I won’t turn this into a rant, but if I had to summarize the advice: be a problem solver, and contribute to what you believe in – something you enjoy or find genuinely interesting.

*Thanks for reading this far. What’s below isn’t a big deal – just the city.*

The city

I extended my stay by 3 days to explore Prague. I took so many pictures my phone storage nearly gave up on me – I found almost everything lovely and fantastic. I’ll link one of my best shots of the museum and the city below.

Thanks to my friend MatH for being my tour guide! 🙂

I totally loved it. It says something that the organizers knew just how magnificent this city is, and believed we’d love it again – and they were right.

Museum ceiling
Wall painted leaves
A view framed through glass and reflection from the top of the museum
A view framed through glass and reflection from the museum rooftop in Prague.
Gothic twin spires over the old town square in Prague.
Stone statues against a blue sky with clouds in Prague.

I wish I could include every beautiful photo I took, but for now, these few will have to tell the story.

Take away

Every day with Fedora, I get to know more about open source, and I get to give back to my community back home.

I am Fedora❤

If any of this made you curious, here’s where to start: come join us in Fedora Join SIG, or if you’re just getting started, the Beginner’s Guide is the friendliest place to land.

Your Friend in Open Source, and Open-Source Freedom Fighter.

From July 27 to August 02

Posted by Aurélien Bompard on 2026-08-03 06:41:00 UTC

Across the various Fedora teams, a major shared focus is the ongoing infrastructure migration to Fedora Forge (Forgejo) and the formalization of its usage policies, a coordinated effort involving the Council, Infrastructure, Release Engineering, and Security groups. Quality assurance and release readiness for Fedora 45 also dominate the updates, highlighted by approaching testable deadlines, mass branching preparations, and FESCo's system-wide approval of gating all stable release updates using the rmdepcheck dependency checker. Meanwhile, user-facing and quality teams are heavily collaborating to troubleshoot critical system issues—most notably a Fedora 44 Workstation login lockout bug—while language-specific SIGs (Go, Perl, Ruby, Rust) are addressing routine maintenance, unannounced soname bumps, and evolving packaging standards. Finally, community outreach and organization remain highly active, with teams like Mindshare and Ambassadors rallying volunteers for upcoming events like FrOSCon 2026, and multiple working groups actively streamlining their documentation and meeting structures to improve contributor onboarding and combat maintainer burnout.

Announcements

Important deadlines and policy updates are approaching for Fedora contributors. First, the Fedora 45 Changes TESTABLE deadline is set for August 11, 2026, requiring all change owners to verify their tracker bugs are in a testable state. Additionally, maintainers should review the list of long-term FTBFS packages scheduled for retirement from Fedora 45 around August 5. On the infrastructure side, the Fedora Council has opened the proposed Fedora Forge Usage Policy for community feedback until August 13, establishing clear scopes and guidelines for the project's internal Forgejo instance. Finally, the long-running CLE "Community update" is officially retiring and being replaced by this new "This Week in Fedora" report to keep contributors informed.

In broader community news, a recent article highlights Peter Boy's work with the Docs Team to explain why Fedora needs more than just technical contributors. For those who missed the recent contributor conference in Prague, a new Flock 2026 Afterburn retrospective shares insights and survey results from the successful event. The project's multimedia outreach continues to see steady audience growth across platforms according to the Fedora Podcast 2026-Q2 metrics report. As part of that ongoing output, the team has just released Episode 057 diving into the history and mechanics of EPEL with Red Hat's Carl George, exploring a tool relied upon across the entire enterprise Linux ecosystem.

Council

The Council focused heavily on policy formalization and infrastructure migration this week. During their bi-weekly meeting, they agreed on edits to the Fedora Forge Usage Policy, settling debates on automated repository archiving by favoring manual oversight, and initiated the official community feedback phase. They also debated a draft Conflict of Interest Policy to handle sensitive governance decisions, and officially closed outdated requests to abolish the Fedora Contributor Agreement. Furthermore, discussions opened regarding the transition of the Digital Public Goods Alliance representative role following the FCA transition.

The Council also handled several operational and community requests. They approved an exception for FreeIPA to be hosted on Fedora Forge and decided to migrate the Fedora Budget repository while explicitly purging old private financial issues. Finally, the Council addressed trademark and organizational queries, declining a suspicious SIG creation request, signaling support for a trademark request for community stickers in Slovakia, and clarifying rebranding requirements for Fedora Remixes.

Decisions

  • Approved an edit to the Fedora Forge Usage Policy regarding repository archiving, removing the automated 6-month rule, and initiated the official policy change process.
  • Closed tickets #410 and #460 (Abolish Fedora Contributor Agreement / Re-license fedora-logos) as deferred/wont-fix due to a lack of capacity and legal constraints.
  • Agreed to migrate the Fedora Budget repository to the Council space on Fedora Forge and delete all of its old private issues containing personal data.
  • Approved an exception request (Ticket #575) allowing the FreeIPA organization to be hosted on Fedora Forge.
  • Denied a suspicious Forge organization request for a new "Software Engineering SIG" (Ticket #573) because it did not follow the documented process.

Learn more about the Council team.

FESCo

This week, FESCo approved several significant system-wide changes, most notably retargeting the Enable Shadow Stack by Default on x86_64 change to Fedora 46 to ensure ample time to fix PyPI and Nvidia driver compatibility. Other major approvals include ODBC Stack Modernization, Native Butane Config Support in Ignition, and the libxml2 2.15 update which officially deprecates Python bindings and requires a mass rebuild. FESCo also fast-tracked and approved a proposal to gate all stable release updates on rmdepcheck to enhance update stability.

In contributor and project news, FESCo granted Proven Packager status to mschorm, merged an adjusted mid-term election policy, and sent final reminders for the upcoming 2FA requirement for all provenpackagers. Ongoing discussions are exploring the Forgejo distgit migration, a Bugzilla replacement tracker, and handling prohibited pre-built binary executables in node_modules. Furthermore, proposals to enable systemd-oomd and zram swap for CoreOS and use Sequoia's OpenPGP implementation are currently under active vote.

Decisions

  • Approved the 'Enable Shadow Stack by Default on x86_64' Change, retargeting it for Fedora 46.
  • Approved the 'libxml215' Change for Fedora 45.
  • Approved the FastTrack proposal to gate all stable release updates on rmdepcheck.
  • Approved the 'Native Butane Config Support in Ignition' Change.
  • Approved the 'ODBC Stack Modernization' Change.
  • Approved the 'LibreOffice Dictionaries' Change.
  • Approved the 'LibreOffice html help' Change.
  • Approved allowing the ELNBuildSync (EBS) service to use draft builds in Koji sidetags inherited from eln-build.
  • Approved an adjustment to the election policy regarding seats filled after a member steps down mid-term.
  • Approved a one-off slightly incompatible update request for rust-routinator.
  • Approved the Request to become Proven Packager for mschorm.

Learn more about the FESCo team.

Mindshare

This week, Mindshare welcomed a new contributor who expressed interest in joining the CommOps team, pointing them to the Matrix chat and Forgejo issue tracker for immediate engagement opportunities. Additionally, preparations are actively underway for FrOSCon 2026, a free FOSS conference happening August 15-16 near Bonn, Germany. The team has secured a booth and is calling on community members to volunteer, create A4 project teasers to spark conversations, and join the pre-event hike to Drachenfels castle.

Decisions

  • Confirmed that a Fedora project booth will be hosted at FrOSCon 2026.

Learn more about the Mindshare team.

Ambassadors

The Ambassadors group is calling for all hands on deck to prepare for FrOSCon 2026, scheduled for August 15-16 near Bonn, Germany. A Fedora booth is confirmed, and contributors are highly encouraged to engage by joining the Matrix room, adding their names to the event Wiki, or creating A4 teaser pages to spark conversations about their Fedora projects at the booth. Additional community-building activities include a planned Friday evening hike to Drachenfels castle, while work on the official event badge is currently pending.

Decisions

  • Confirmed Fedora's booth presence and participation at FrOSCon 2026.

Learn more about the Ambassadors team.

Diversity & Inclusion

Justin Wheeler proposed putting DEI Team meetings on hiatus to protect the mental health of the chairs and prevent burnout. The team agreed that regular meetings had become stagnant and decided to shift their focus toward ad-hoc, event-specific teams with concrete goals and timelines, such as the Fedora Mentor Summit or Fedora Week of Diversity. General discussions will continue in the team chat room as needed.

Decisions

  • Put regular DEI Team meetings on hiatus and transition to an ad-hoc, event-specific meeting model.
  • Delete the regular DEI Team meeting entries from both the Fedora and Google Calendars.
  • Open a volunteer call for Fedora Week of Diversity to evaluate if there is enough interest to execute the event later this year.

Learn more about the Diversity & Inclusion team.

Workstation / GNOME

This week, the Workstation/GNOME team discussed a login bug in the Fedora 44 Workstation ISO where users are occasionally locked out after setting their credentials. Contributors are working to gather logs and pinpoint the exact cause within gnome-initial-setup. Additionally, a new implementation restoring Google Drive integration in GNOME is currently under review by upstream maintainers, presenting a great opportunity for community testers to provide feedback.

In networking discussions, the team explored IPv6 prefix delegation issues involving routers that fail to invalidate old prefixes after rebooting, which leads to dropped connectivity. It was noted that router manufacturers like Mikrotik are currently working on firmware updates to align with RIPE recommendations, circumventing the need for immediate workarounds in Fedora's default network behavior.

Decisions

  • Determined that the Fedora 44 Workstation login bug is related to user creation during first boot (gnome-initial-setup or shadow-utils) rather than Anaconda, which does not handle user creation on the Workstation Live image.

Learn more about the Workstation / GNOME team.

KDE

A user reported experiencing system freezes under Plasma (Wayland) after upgrading to Fedora 44, specifically noting that the nvidia-modeset/kthread_q process was consuming 100% CPU. The issue occurred on a hybrid graphics setup utilizing an AMD CPU and a discrete NVIDIA GPU running the proprietary NVIDIA drivers (610.43.03).

In the ensuing discussion, a community member advised checking the system and user journals via SSH before performing a forced reboot to isolate the root cause. The user was also directed to seek further assistance on the Fedora Discussion forum, which hosts a larger pool of contributors experienced with NVIDIA troubleshooting.

Learn more about the KDE team.

Server

During this week, the Server Working Group held a meeting to coordinate Fedora 45 release testing, Ansible support, and the Home Server spin-off. Contributors are encouraged to help test Brett's newly finalized Kiwi development environment for the Home Server project. On the automation front, the group is exploring the "AnsibleByExample" standard project layout and GitLab workflows for their upcoming Ansible roles, and an initial post-install role PR is being merged for member testing. For F45 testing, Emmanuel Seyman will review the upstream release changes for potential Server Edition impacts, and interested contributors were directed to the QA SIG to assist with openQA test automation.

Outside of the meeting, a forum discussion regarding IPv6 preferred_lft address routing issues with non-persistent prefixes concluded. A user shared a temporary workaround using Unique Local Unicast (ULA) and NAT while awaiting an upcoming patch from router manufacturer Mikrotik.

Decisions

  • Emmanuel Seyman will review the Fedora 45 change list to identify potential issues for the Server Edition.
  • The group will evaluate the 'AnsibleByExample' playbook structure and GitLab workflows to standardize their Ansible support repositories.
  • John Himpel will merge Emmanuel Seyman's draft post-install Ansible PR to enable wider testing among members.
  • The working group will begin testing and providing feedback on Brett's newly established virtualized Kiwi development environment for the Home Server spin-off.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team focused heavily on resolving post-migration issues following the upgrade of the IPA cluster to RHEL 10. Efforts were directed at stabilizing authentication services, addressing sporadic login errors on accounts.fedoraproject.org, fixing Ipsilon auth failures caused by browser tracking protection, and correcting LDAP schema replication errors. In the forums, a proposal was introduced to place an HAProxy load balancer in front of the IPA cluster to bypass ongoing DNS TTL caching problems. Work also continued on restoring the Koji staging database and migrating miscellaneous infrastructure hosts to RHEL 10.

Other notable discussions included optimizing Zabbix monitoring by implementing service-level layers, re-notifying on critical alerts, and exploring read-only guest access. The team also reviewed a proposal for a "test assets server" designed to drastically reduce network traffic by caching update repositories for Fedora CI and openQA. In parallel, Forgejo integration saw substantial updates, with new monitoring templates and continued progress on the highly requested private issues feature.

Decisions

  • Set ipsilon02 as a backup server in HAProxy to mitigate authentication transaction failures caused by browser tracking protection.
  • Completely disable (ensure absent) the mod_mime_magic Apache module on proxies and package servers to fix dist-git lookaside cache HTTP header issues.
  • Add DNA range variables directly to the IPA Ansible playbook to automatically set them per host.
  • Implement a 🔥 keyword highlight in Matrix clients to help administrators quickly spot Disaster-level Zabbix alerts.
  • Patrikp will act as the chair for the August 13th Infrastructure meeting.

Learn more about the Infrastructure team.

Release Engineering

The Release Engineering team focused heavily on the final steps for migrating fedora-scm-requests from Pagure to Forgejo. To minimize disruption for contributors, the team agreed to coordinate the fedpkg tooling updates with a firm "flag day", ensuring developers receive appropriate upgrade warnings before the legacy Pagure API is fully disabled. Meanwhile, preparations are underway for the upcoming mass branching tentatively scheduled for August 11th, which includes updates to related Ansible tooling.

On the operations side, the group processed a dozen tickets, yielding several updates relevant to the broader Linux community. The F47 Release Signing Keys have been generated, a new eln-bootc repository was created on Quay to host bootc images for ELN composes, and the f45-perl side tag was successfully merged into Rawhide. Contributors are also reminded that package unretirements (for packages retired less than 8 weeks ago) can now be handled directly via the fedpkg request-unretirement command without needing to open a manual releng ticket.

Decisions

  • Coordinate the fedora-scm-requests Forgejo migration using a synchronized 'flag day' to safely transition users to the updated fedpkg CLI, rather than attempting to maintain dual APIs.
  • Provide access to staging compose hosts for Pungi PR testing by adding the requesting users to the sysadmin-releng staging group.
  • Merge the f45-perl side tag into Rawhide following successful openQA testing.
  • Direct package maintainers to use the fedpkg request-unretirement CLI command for recent unretirements rather than processing manual infrastructure tickets.

Learn more about the Release Engineering team.

Quality

This week, the Quality team saw a major workflow change as FESCo approved gating all stable release updates on the rmdepcheck tool, a rule that has already taken effect for in-flight updates. In the forums, contributors highlighted a critical login lockout bug on the Fedora 44 Workstation ISO and issued an important call for testers to evaluate a new Google Drive integration implementation for GNOME.

Additionally, quality engineering efforts successfully pushed a large Python rebuild update through testing and identified issues with Fedora 45 backgrounds via openQA. The team is actively preparing for upcoming Test Days and making numerous infrastructure updates to tools like Issuebot, Testdays-web, and Fedora Easy Karma ahead of the upcoming Fedora branches.

Decisions

  • FESCo approved gating all stable release updates on the rmdepcheck reverse dependency static checker. This rule was implemented in production immediately and applies retrospectively to in-flight updates.

Learn more about the Quality team.

Websites and Apps

This week, the Websites and Apps group discussed a proposal to add a warning banner to the Fedora 44 download page regarding a login-blocking bug that reportedly prevents users from logging in after a fresh Workstation install. While the initial request suggested pointing users to a Respins SIG image with a patched Anaconda, QA representatives clarified that user creation is handled during first boot (gnome-initial-setup or plasma-setup), not by Anaconda. Consequently, the discussion pivoted to accurately reproducing the issue, presenting an opportunity for contributors to help collect diagnostic logs for first-boot login failures before any website changes are considered.

Decisions

  • No changes or warning banners will be added to the download page until the reported login issue is properly reproduced and the root cause is correctly identified.

Learn more about the Websites and Apps team.

Design

The Design team saw a community member propose a custom wallpaper set for future Fedora releases, though it was noted it may not fit the current Fedora 46 theme. In ticket discussions, progress continued on the Contributor Onboarding Video Series, with the team agreeing on specific public-domain music tracks and moving forward with generating video previews.

Additionally, new UX/UI design requests were opened for a Fedora website credits page and a Project Resistor site redesign, prompting the team to propose a discovery call for the latter. Finally, the team discussed modernizing the outdated "What can I do for Fedora" site, ultimately closing the ticket with the decision to contact the upstream infrastructure maintainers before committing to new mockups, while also dropping the broken link from a new contributor poster.

Decisions

  • Proceed with the chosen public-domain music tracks ("Jupiter" and "Never Speak of the Devil") for the Contributor Onboarding Video Series.
  • Schedule a discovery call with the Project Resistor team to clarify whether they need mockups or full web development.
  • Close the "What can I do for Fedora" redesign ticket to first check with the upstream repository maintainers before doing any design work.
  • Remove the outdated "What can I do for Fedora" link from the new contributor poster.

Learn more about the Design team.

Docs

During the July 28 meeting, the Docs team discussed information architecture updates for the site's frontpage. Visual redesigns are delayed for 2-3 months while the Design team is busy, but a new staging landing page (docs.stg.fedoraproject.org) is currently live to test structural changes. The team also evaluated technical challenges regarding Antora repository module splits, noting that future structural updates might require significant URL redirects to maintain links. In broader community news, attendees were informed that a Flock 2026 recap and session videos will soon be available on Fedora Magazine and YouTube.

To improve contributor engagement, the staging site now features a dedicated section for new contributors, and the team is actively seeking collaboration with the Join SIG to refine it. There are also immediate, bite-sized opportunities for community members to get involved: volunteers are highly encouraged to help clean up obsolete Wiki pages in the Docs_Project category by applying a simple redirect macro, and anyone with CSS experience is welcome to help style the new frontpage.

Decisions

  • Postpone major visual and CSS updates to the frontpage until the Design team has availability in 2-3 months, focusing entirely on content and information architecture in the meantime.
  • Restrict the ongoing wiki deprecation and cleanup efforts strictly to the Docs_Project category to prevent scope creep.

Learn more about the Docs team.

This week, the Legal team addressed questions regarding firmware distribution and open-source license text anomalies. In a discussion about the foo2zjs printer driver, contributors asked if Fedora could package scripts that download necessary HP printer firmware. Legal clarified that scripts downloading from unofficial third-party mirrors (getweb) are not permitted, but a script fetching from the official OpenPrinting website (getweb-hpplugin) could be acceptable, pending a formal license review of the firmware to ensure it meets Fedora's technical criteria.

Additionally, in a thread concerning "All rights reserved" clauses appearing alongside FOSS licenses like BSD-3-Clause, the team concluded that this phrase is largely a redundant "cargo-cult" addition. Contributors are advised not to worry about it, as it can be safely ignored provided it is associated with a clear, acceptable open-source license grant.

Decisions

  • Scripts downloading firmware from unofficial, third-party mirrors are not permitted in Fedora.
  • Scripts downloading firmware from official sources (like OpenPrinting) may be acceptable, but the specific firmware license must first undergo a formal legal review against Fedora's technical firmware requirements.
  • The phrase "All rights reserved" found alongside upstream FOSS licenses is considered redundant and can be safely ignored as long as it is paired with an acceptable open-source license grant.

Learn more about the Legal team.

EPEL

This week, the EPEL team focused heavily on the EPEL 11 and EPEL 10 directory naming scheme proposal to address feedback from enterprise rebuild communities (such as AlmaLinux and Rocky Linux) regarding private mirrors and repository redirection. During their weekly meeting, the team laid out a timeline to evaluate and implement these changes before the RHEL 10.3 branching to avoid disrupting early adopters. Additionally, on the mailing list, it was announced that FESCo has approved gating all Fedora stable release updates using the rmdepcheck reverse dependency static checker, a policy that will soon be evaluated for EPEL as well.

In broader contributor and community news, routine package maintenance and quality assurance continued, including the introduction of new EPEL 10 packages and efforts to resolve failing-to-install (FTI) and policy-breaking packages in EPEL 9. Community engagement was also highlighted, with an upcoming Fedora Podcast interview featuring Carl George to discuss the EPEL 11 proposal and raise broader Linux community awareness.

Decisions

  • The team agreed to schedule a vote on the EPEL 11 portion of the naming scheme proposal for August 5th, and a vote on the EPEL 10 portion for August 12th.

Learn more about the EPEL team.

ELN

During the July 28 ELN meeting, the team announced that ELN bootc images are now building regularly on Konflux. Contributors are currently resolving minor early-testing issues and working to establish an automated pipeline to the production registry (quay.io/fedora/eln-bootc). Additionally, qcow2 and ec2 images are now being successfully built using image-builder and have been validated on AWS, with pull requests open to integrate Azure and GCE support.

Looking ahead to RHEL 11, the group also debated whether to drop hardware firmware (such as linux-firmware) from cloud images. Acknowledging that hardware passthrough is still utilized on some hyperscalers, the group opted to move this conversation to a dedicated issue to carefully evaluate how closely ELN should mirror future RHEL decisions without disrupting existing use cases.

Decisions

  • Tasked Simon de Vlieger with investigating how to properly upload and publish Konflux bootc builds to the quay.io/fedora/eln-bootc registry.
  • Decided to move the discussion regarding the removal of hardware firmware from ELN cloud images to a separate issue tracker.

Learn more about the ELN team.

Atomic

In the weekly meeting, the team highlighted continued progress on ELN and Konflux integration, specifically regarding plans to migrate base images from GitLab. A blocker regarding a Konflux service account is currently being addressed by the infrastructure team, which is expected to unblock development shortly. Leadership also noted pending action items to formalize the SIG's setup process and establish a dedicated Fedocal calendar for contributors.

Meanwhile, an ongoing forum discussion regarding the proposed systemd-sysexts SIG focused on the administrative steps for launching the group. To navigate confusing documentation rules, contributors agreed to initially outline the new SIG's scope on a standard Fedora Wiki page before requesting a dedicated Forge organization and Matrix channel.

Learn more about the Atomic team.

CoreOS

This week, the CoreOS group focused on upcoming release testing, tentatively scheduling the Fedora CoreOS 45 Test Day and live video meeting for September 21st. Technical discussions highlighted the Ignition Native Butane Support proposal, which will remove the need for an external conversion step during provisioning; the team plans to gather feedback on this from the Flatcar community. Additionally, contributors addressed issues with the CodeRabbit PR bot leaving unprofessional comments in the Afterburn repository, planning to establish a dedicated repository to manage global configuration defaults.

In the forums, progress continued on establishing the systemd-sysexts SIG. Contributors discussed the optimal way to host the SIG's initial documentation, ultimately recommending starting with a Fedora Wiki page before requesting a dedicated Forge organization to bypass current procedural documentation challenges.

Decisions

  • Tentatively schedule the Fedora CoreOS 45 Test Day and live video meeting for 2026-09-21, pending the final Beta Release schedule.
  • Address inappropriate CodeRabbit PR bot comments by disabling them in affected repositories and creating a central coreos/coderabbit repository for global default configurations.

Learn more about the CoreOS team.

AI & ML

This week, the AI & ML group announced that GPU CI testing is now operational and available for contributors in the AI/ML SIG. Furthermore, the AI Developer Desktop has achieved its initial integration with OpenShell, marking an exciting step forward for the project.

In administrative updates, a contributor requested to be removed from the SIG due to time constraints and burnout. The group processed this request, removing the member from the SIG-related GitLab groups and the pytorch-sig membership to ensure an accurate representation of active contributors.

Learn more about the AI & ML team.

Security

During their weekly meeting, the Security SIG focused on formalizing internal vulnerability management processes and establishing documentation standards. A primary initiative is preparing for Fedora's representation on the private linux-distros mailing list to safely handle embargoed pre-disclosure vulnerabilities. To support this, the team is defining clear policies, establishing a secure Bugzilla workflow, and setting up dedicated access groups. In news relevant to the broader Linux ecosystem, the group is defining and documenting Fedora's role as a CVE Numbering Authority (CNA) and auditing existing documentation to align with the EU Cyber Resilience Act (CRA) requirements.

To improve contributor engagement opportunities, the team successfully migrated the Defensive Coding Guide from Pagure to Forgejo, opening the door for new community contributions. Discussions are also underway on the forum to review Fedora-maintained hardening guidelines and on the tracker to explore creating a vulnerability reporting badge as a non-monetary bug bounty alternative.

Decisions

  • Draft comprehensive documentation detailing Fedora's scope and guidelines as a CVE Numbering Authority (CNA).
  • Create a new FAS group named sec-bugzappers to manage access for Fedora representatives handling the linux-distros pre-disclosure mailing list.
  • Establish a dedicated, private Bugzilla component (proposed as distribution-private or fedora-security) to track embargoed vulnerability reports.
  • Draft a platform-neutral policy for handling pre-disclosure vulnerabilities and submit it as a PR to the Security team's documentation.
  • Grant all Security SIG members the privilege to create new repositories within the Forge group to remove documentation bottlenecks.
  • Close the Pagure repository and officially migrate the Defensive Coding Guide to the Security SIG's Forge namespace.

Learn more about the Security team.

Go

During the Go SIG meeting, the team discussed standardizing CGO_CFLAGS and related compiler flags across Fedora by introducing a new %go_set_cgo_flags macro, which will undergo mass prebuild testing to avoid disrupting existing packages. The group also approved a new SIG membership policy that will be appended to the project README, clarifying the justification required for elevated package privileges. For contributors looking to get involved, assistance is needed to patch downstream packages broken by recent Go 1.27 updates, specifically those affected by changes to json v2, compress/flate, and grpc.

In broader Linux ecosystem news, the unmaintained license-scanning tool askalono has been forked into a newly maintained project named scallion. Fedora's Go packaging stack will pivot to use scallion as its default license detector. Additionally, efforts are underway to provide a minimal go-vendor-tools package for RHEL 11 by stripping optional build-time dependencies, an initiative that presents immediate opportunities for contributors to write tmt-based integration tests.

Decisions

  • Approved the new Go SIG membership policy, which will be formalized via a PR to the project repository.
  • Agreed to introduce scallion as the replacement for the unmaintained askalono license scanner, with upcoming changes planned for both go-vendor-tools and go2rpm.
  • Decided to release go2rpm v2 with the default configuration set to the vendor profile.
  • Agreed to support go-vendor-tools in RHEL 11 by isolating the RHEL-specific changes in a separate GitLab branch and developing new tmt-based integration tests.

Learn more about the Go team.

Perl

This week, the Perl group focused heavily on package maintenance, compatibility updates, and version bumps. Several pull requests were merged, including conditionalizing dependencies for perl-Module-Build-Tiny, disabling optional dependencies for perl-Compress-Raw-Lzma in RHEL, and addressing Wx 3.2.9 compatibility in perl-Wx. A patch for OpenSSL 4 ASN.1 strings was integrated into perl-Crypt-SMIME. Additionally, routine version bumps were applied to perl-LWP-Protocol-https (6.17), perl-HTTP-Message (7.04), and perl-ExtUtils-XSpp (0.19).

Other ongoing discussions involved resolving an expected installability failure during the bootstrap of perl-SQL-Abstract and addressing MySQL 9.7 rebuilds for perl-DBD-MySQL, though the latter's PR was closed as the fix was committed directly to the rawhide branch.

Decisions

  • Merge pull request to conditionalize CPAN::Requirements::Dynamic dependency in perl-Module-Build-Tiny.
  • Merge pull request to disable optional dependencies for perl-Compress-Raw-Lzma in RHEL.
  • Merge pull request applying a compatibility patch for Wx 3.2.9 in perl-Wx.
  • Merge pull request containing an OpenSSL 4 ASN.1 string patch for perl-Crypt-SMIME.
  • Close the perl-DBD-MySQL PR for the MySQL 9.7 rebuild without merging, as it was fixed directly in the rawhide branch.
  • Merge version bump pull requests for perl-LWP-Protocol-https (6.17), perl-HTTP-Message (7.04), and perl-ExtUtils-XSpp (0.19).

Learn more about the Perl team.

Python

A contributor raised a packaging question regarding the dupeguru package (Bugzilla 2497737), which is currently waiting for review. The upstream code uses generic top-level modules (core, hscommon, qt), which could cause namespace conflicts with other applications. The main subject of inquiry was whether reorganizing the source tree to place these folders under a specific dupeguru namespace is the recommended approach for Fedora packaging.

Learn more about the Python team.

Ruby

Vít Ondruch announced that the upgrade to Ruby on Rails 8.1 (specifically version 8.1.2) has officially landed in Fedora. An update to the recently released version 8.1.3.1 is planned for the near future, as it was temporarily delayed to meet the change deadline. From a packaging perspective, there were no major structural changes, with the notable exception of Trix being extracted into a separate new package. Contributors and users are highly encouraged to test the new release and report any issues.

Decisions

  • Upgrade the Ruby on Rails package to version 8.1.2.
  • Extract Trix into a new, separate package.
  • Delay the update to Rails 8.1.3.1 temporarily to ensure the 8.1.2 update meets the change deadline.

Learn more about the Ruby team.

Rust

Frank Dana proposed a new packaging method for Rust and Python that would replace feature-specific subpackages with a conditional Requires: ... for syntax in RPM. He argued that the current glut of subpackages creates excessive metadata, bloats dnf search results, and clutters local systems.

During the discussion, Fabio Valentini pointed out that Rust packaging tooling must maintain backward compatibility with RHEL 9, making this unfeasible to implement in the near future, and suggested using fedpkg mockbuild instead of local builds to avoid cluttering personal environments. Carl George noted that since some Python extra subpackages contain actual files (like CLI commands or man pages), the proposed mechanism could not fully replace subpackages, though both systems could potentially coexist.

Learn more about the Rust team.

Other Discussions

Orphaning packages

Package updates

New contributor introductions

  • Phoebe Harris: An embedded software developer aiming to package the SSH connection manager clifton and Typst.
  • Dawid Wrobel: A KMyMoney developer returning to Linux who wants to adopt outdated GNOME extensions and package Betterbird.
  • Myriade: A young Rust developer intending to adopt and maintain the orphaned supercollider package.
  • Nikolay: A software engineer developing qTox who is interested in deep neural networks and machine learning.
  • Vivek Denny: A backend/cloud developer with an interest in low-level systems and networks wanting to give back to open source.

I Violated the Geneva Conventions by Implementing Kerberos in TypeScript

Posted by Neil Hanlon on 2026-08-02 00:40:00 UTC

A couple weeks ago I shipped a swamp workflow that tells me what Fedora wants from me on a given day. Three models fan out in parallel, pull bugs and builds and package state, and one command writes a markdown snapshot I can diff against last week’s. It’s the workflow I wanted, and it runs every time I have the spoons for it.

Two of the three models are pure fetch, and carry no external dependencies. The third isn’t. The FASJSON service speaks only Kerberos/GSSAPI: every endpoint requires WWW-Authenticate: Negotiate, and there’s no password or token fallback of any kind. The standard answer (the one every integration I’ve ever seen uses) is to shell out: kinit, then curl --negotiate, and now your model depends on a subprocess, an ambient credential cache, and whether the machine happens to have krb5-workstation installed.

📝 Redis version 8.10

Posted by Remi Collet on 2026-07-31 07:27:00 UTC

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

1. Installation

Packages are available in the redis:remi-8.8 module stream.

1.1. Using dnf4 on Enterprise Linux

# dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %rhel).rpm
# dnf module switch-to redis:remi-8.10/common

1.2. Using dnf5 on Fedora

# dnf install https://rpms.remirepo.net/fedora/remi-release-$(rpm -E %fedora).rpm
# dnf module reset  redis
# dnf module enable redis:remi-8.10
# dnf install redis --allowerasing

You may have to remove the valkey-compat-redis compatibility package.

2. Modules

Some optional modules are also available:

These packages are weak dependencies of Redis, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).

The modules are automatically loaded after installation and service (re)start.

The modules are not available for Enterprise Linux 8.

3. Statistics

redis

redis-bloom

redis-json

redis-timeseries

📝 Redis version 8.8

Posted by Remi Collet on 2026-05-23 14:38:00 UTC

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

1. Installation

Packages are available in the redis:remi-8.8 module stream.

1.1. Using dnf4 on Enterprise Linux

# dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %rhel).rpm
# dnf module switch-to redis:remi-8.8/common

1.2. Using dnf5 on Fedora

# dnf install https://rpms.remirepo.net/fedora/remi-release-$(rpm -E %fedora).rpm
# dnf module reset  redis
# dnf module enable redis:remi-8.8
# dnf install redis --allowerasing

You may have to remove the valkey-compat-redis compatibility package.

2. Modules

Some optional modules are also available:

These packages are weak dependencies of Redis, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).

The modules are automatically loaded after installation and service (re)start.

The modules are not available for Enterprise Linux 8.

3. Statistics

redis

redis-bloom

redis-json

redis-timeseries

🛡️ PHP version 8.2.33, 8.3.33, 8.4.24, and 8.5.9

Posted by Remi Collet on 2026-07-31 05:05:00 UTC

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

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

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

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

⚠️ PHP version 8.1 has reached its end of life and is no longer maintained by the PHP project.

🛡️ These Versions fix 3 security bugs (CVE-2026-7260, CVE-2026-17543, CVE-2026-17544), so the update is strongly recommended.

Version announcements:

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

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.5 as Software Collection

yum install php85

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

⚠️ To be noticed :

  • EL-10 RPMs are built using RHEL-10.2
  • EL-9 RPMs are built using RHEL-9.8
  • 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)

My CPU died

Posted by Jonathan McDowell on 2026-07-31 00:28:00 UTC

I built my current house server back in 2019. It had an upgrade from the original Ryzen 2700 to a 5700G in late 2021, but otherwise is still running with the original setup. Back in November it developed some erratic behaviour (initially manifesting as problems with the TPM, which is ironic as I’ve spent a bunch of time at my day job trying to improve TPM reliability), culminating in unreliable reboots. I had a limited amount of ability to swap parts out, but ultimately decided it was a motherboard issue (thinking perhaps VRM problems), found a replacement locally, and everything seemed fine.

Until May.

At that point I rebooted the machine for a Debian point release, and it failed to come back. Fans would spin, but there was no sign of actual life. I ended up pressing a temporary machine into service (that could at least run the Home Assistant container, and a few other critical bits) while I tried to work out what was wrong. I’d kept the previous motherboard, and still had the Ryzen 2700, so I did a bunch of swaps (and obtained a motherboard buzzer to try and get some indication about whether there were useful beep codes being emitted), and ultimately came to the conclusion that the CPU had died.

I’m not quite clear what happened here. I played it safe and replaced the PSU at the same time, in case that was the original cause back in November and ultimately damaged the CPU, but both old + new motherboards worked just fine with the 2700.

That left a decision about what to do. This previous server was from 2013, so this machine has now lasted longer than that and I could justifiably upgrade. However when I went to look at what the equivalent modern machine would be it’s only a couple of generations later (Zen 5 vs Zen 3), and 64GB RAM alone would have set me back ~ £1k. For not a lot of gain. So I ended up buying a replacement Ryzen 5700G, hopefully allowing me to put off thinking about an upgrade until Zen 6 is out, and RAM prices are saner (though I understand that might take a couple of years).

It’s not the first time I’ve had a faulty PSU be the cause of a dead machine, but it was a pretty frustrating experience.

Friday Links 26-24

Posted by Christof Damian on 2026-07-30 22:00:00 UTC
The Amiga Juggler demo: a raytraced figure juggling three mirrored spheres above a yellow-and-green checkerboard floor

I liked the “Border Collie” post today, the podcast about air conditioning in Europe, and the interview with Mike D.

Quote of the Week
[…] the eco-philosopher Derrick Jensen, who says: ‘The good thing about everything being so fucked up is that no matter where you look, there is great work to be done.’
Meditations for Mortals
Oliver Burkeman

Leadership

TBM 433: The Border Collie Faustian Bargain - fun model. I think this applies to other ways of buy-in too.

Fedora Forge Usage Policy

Posted by Fedora Community Blog on 2026-07-30 12:11:59 UTC

After extensive review and discussion on the ticket request and in recent council meetings (see meetbot for 29 July and 15 July 2026), the Fedora Council would like to initiate the policy change policy process for ratifying the Fedora Forge Usage policy. This document is open to public feedback (if any) for a minimum of two weeks. If there are no significant changes to be made to the policy based on community feedback after Thursday, 13 August 2026, this policy will go to a formal ticket vote for Council to approve or reject.
If there are significant changes to be made to the document, Council will review the policy and, if necessary, extend the feedback period before calling for an official vote. Please provide feedback on the discussion post.

The policy can be found on the Council wiki page in Fedora Forge, posted on discourse, and pasted below here for convenience.

Thank you everyone for your contributions to this policy so far, and on behalf of the Council, we look forward to working with you all to ratify this policy soon.

Fedora Forge Usage Policy

Welcome to the Fedora Forge. This Forgejo instance is provided by the Fedora Infrastructure team to support the daily operations, development, and collaboration of the Fedora Project.

To ensure this service remains reliable, secure, and useful for everyone in the Fedora community, all users must adhere to the following usage policy.

1. Scope, Criteria, and Exceptions

The Fedora Forge is a dedicated workspace for the Fedora Project. Historically, the Fedora Project utilized pagure.io, which operated as a general-use public forge where Fedora repositories coexisted alongside personal projects, unrelated upstream software, and individual portfolios.

The Fedora Forge (powered by Forgejo) intentionally adopts a narrower scope. It is not a public, general-use Git hosting provider. It is an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.

Criteria for “Fedora Project Related”

To qualify for hosting on the Fedora Forge, a repository must meet at least one of the following criteria:

  • Infrastructure and Operations: Configuration management, deployment scripts, or tooling used by the Fedora Infrastructure team to run the project.
  • Release Engineering and Packaging: Tools, scripts, and templates used to build, compose, and distribute Fedora releases, editions, and spins.
  • Governance and Team Organization: Trackers, documentation, and collaborative spaces for official Fedora Teams, Special Interest Groups (SIGs), Working Groups, and Fedora Council initiatives.
  • Fedora-Specific Software: Software projects conceptualized and developed primarily to serve the Fedora community (e.g., Fedora Badges, Bodhi, fedmsg).

Exceptions and Special Cases (Ecosystem Upstreams)

While general upstream development should happen on public forges (like GitHub, GitLab, or Codeberg), the Fedora Project recognizes that certain large-scale upstream projects are so deeply intertwined with Fedora’s infrastructure and history that they qualify as exceptions.

Recognized Exceptions:

  • Foundational infrastructure tools heavily maintained by Fedora and Red Hat ecosystem contributors (e.g., Koji, FreeIPA).
  • Core system components where the primary development team is historically rooted in the Fedora community and relies on Fedora Infrastructure for their workflow.

Note: Being packaged in the Fedora repository does not automatically grant a project exception status to use the Fedora Forge as its upstream host.

Decision Process for Edge Cases

If a community member is unsure whether their project fits the scope or qualifies as an ecosystem exception, the following process applies:

  1. Request Submission: The requester must open a ticket on the Fedora Infrastructure tracker, detailing the project’s purpose, its connection to Fedora, and why it should be hosted on the Fedora Forge rather than a public alternative.
  2. Infrastructure Review: The Fedora Infrastructure team will conduct an initial review against the established criteria to assess technical feasibility and resource impact.
  3. Steering Committee Consultation: If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) or the Fedora Council for a policy ruling.
  4. Final Resolution: The decision will be documented in the ticket. If denied, the requester will be encouraged to host the project on a public forge and mirror specific components if strictly required for internal Fedora builds.

2. Access and Authentication

Access to the Fedora Forge is integrated with our central identity systems to ensure secure and accountable access.

  • Account Creation and Login: All authentication is handled via the Fedora Account System (FAS). You cannot create a local account directly on the Forgejo instance. To log in, use the Single Sign-On (SSO) integration with your active FAS credentials.
  • Personal Namespaces: Upon your first login, a personal namespace (e.g., forge.fedoraproject.org/your-fas-username) is automatically provisioned for you. You can only fork repositories into this space, creation of new repositories is allowed only under Organization.
  • Organizations and Teams: To prevent organizational sprawl, the creation of top-level Organizations (e.g., /infra or /quality) is restricted. If your Fedora team or SIG needs a dedicated Organization space, please open a ticket with the Forge team. Organization owners are responsible for managing team access within their assigned space.
  • Account Deactivation: If your FAS account is suspended, disabled, or marked as inactive, your access to the Fedora Forge will be automatically revoked. Repositories hosted in your personal namespace may be archived or removed if your account remains inactive for an extended period. If you are leaving the project, please transfer ownership of any critical tools to a Fedora Organization or an active co-maintainer before your departure.

3. Code of Conduct and Community Behavior

The Fedora Forge is a collaborative space. All activity on this platform is strictly governed by the Fedora Code of Conduct.

4. Prohibited Activities

To ensure the Fedora Forge remains performant, secure, and legally compliant, the following activities and content are strictly prohibited:

  • Non-Fedora Projects: As stated in the scope, this Forge is not a general-purpose Git host. Personal portfolios, dotfiles, or hobby projects not directly tied to Fedora are prohibited.
  • Malicious Content: Hosting malware, exploits, botnet command-and-control infrastructure, or phishing materials. (Note: Security-related tools strictly used for Fedora infrastructure testing must be explicitly approved).
  • Proprietary and Copyrighted Material: Uploading copyrighted materials you do not have the right to distribute, or hosting proprietary, closed-source binary blobs. All code should be open source and compliant with Fedora’s licensing guidelines.
  • Exposing Secrets: Committing sensitive information such as passwords, API tokens, private SSH keys, or Personally Identifiable Information (PII).
  • System Abuse: Engaging in activities that degrade the performance of the Forgejo instance or its runners, such as aggressive network scraping, DDoS attacks, or intentionally triggering infinite CI loops.
  • Cryptocurrency Mining: Using the Forge or its CI/CD runners to mine cryptocurrency is strictly forbidden and will result in an immediate, permanent ban.

5. Resource Limits and CI/CD

We want to empower Fedora teams with the tools they need, but we must also manage our infrastructure costs and storage effectively.

  • Repository Size: Git is not a backup system. Please keep repositories focused on source code and text-based documentation.
    • Repositories should ideally remain under 500MB.
    • If your project requires large assets (e.g., design files, test datasets), you must use Git LFS (Large File Storage).
  • Forgejo Actions and CI Runners:
    • Shared Infrastructure: The default CI runners provided by Fedora Infrastructure are a shared community resource. Jobs should be optimized to run efficiently and are subject to a maximum timeout of 10 minutes per job.
    • Community-Owned Runners (Bring Your Own): We highly encourage larger teams, SIGs, and Working Groups with extensive testing or specific architectural requirements (e.g., heavily utilizing ARM, RISCV, or requiring long build times) to provision and register their own runners. Dedicated runners can be attached directly to your Organization or specific repositories.
    • Compliance for Custom Runners: Even if your team provides the compute resources, any runner connected to the Fedora Forge is an extension of our infrastructure. All workflows and actions executed on community-owned runners must strictly comply with Section 4 (Prohibited Activities). You may not use custom runners to bypass policy (e.g., no cryptocurrency mining, no building unrelated non-Fedora upstream projects, and no malicious network scraping).
    • Registration Process: To register a dedicated runner for your team, please review our Runner Registration Docs and ensure your runner is secured according to Fedora Infrastructure standards.
  • API Usage: Automated scripts and bots interacting with the Forgejo API must respect rate limits and include descriptive user-agent strings identifying the tool and its maintainer.

6. Repository Lifecycle and Organization

  • Naming Conventions: We have a general naming convention, there should be tickets repository in your Organisation to have a single point of opening tickets relevant to your group. The docs repo in you organization should point to your groups official sources for docs.fedoraproject.org namespace. In other cases please use clear, descriptive names for repositories so other community members can easily understand their purpose.
  • Archiving: Projects that are no longer actively maintained should be archived (marked as read-only) to signal their status to the community. Active Forge organization owners should archive repos as necessary. If needed (e.g., in the case of an inactive organization), the Infrastructure team reserves the right to archive repositories that have seen no activity after trying to contact the organization owners.**.
  • Deletion: If you need an Organization or repository completely deleted, please open a ticket with the Forge team. The Infrastructure team also reserves the right to delete abandoned, non-compliant, or empty repositories to maintain a clean workspace.

7. Support and Abuse Reporting

  • Getting Help: For technical issues with the Fedora Forge (e.g., CI runner failures, login issues, requesting an Organization), please open a ticket on the Forge team tracker or ask in the #fedora-admin Matrix channel.
  • Reporting Code of Conduct Violations: To report a CoC violation occurring on the Forge, please contact the Fedora Code of Conduct Committee.
  • Reporting Security/Legal Issues: To report a security vulnerability on the platform, exposed secrets, or a DMCA/copyright violation, please immediately send an email to Fedora Infrastructure team.

The post Fedora Forge Usage Policy appeared first on Fedora Community Blog.

Announcing the next Fedora Community Architect

Posted by Fedora Magazine on 2026-07-30 08:00:00 UTC
Two men sit behind laptops at a booth with large overlaid text reading, "Meet the next Community Architect". The background consists of black drapes and a partial event banner.

Evolution, change, and innovation are important parts of Fedora. This applies both to our open source technology and in how we sustain the community that builds it. As Fedora changes with the world around us, so too must the roles that support it. This includes the Fedora Community Architect role. Today, we (Justin & Shaun) are excited to share a strategic transition in how Red Hat supports Fedora’s community operations.

Effective as of time of publication, we are beginning a transition period for the Fedora Community Architect (FCA) role. To continue our commitments to Fedora and CentOS, the Red Hat Open Source & AI Program Office is splitting the current, wide-reaching FCA responsibilities into two distinct, focused roles.

The Transition

We (being Justin & Shaun) will work in a transitional phase together from now until the release month of Fedora Linux 45, currently planned for October 2026. During this time, we will shift our focuses to ensure a smooth handoff for key community operations, including event logistics, budget management, and both Fedora Council and CentOS board representation.

Shaun McCance will step into the role of Fedora Community Architect. Many may already know Shaun as a longtime person in our community, bringing experience and context from GNOME, a major Fedora upstream project. He also brings significant experience in community event execution, budget management, and existing expertise as the CentOS Community Architect. He will take over the permanent FCA seat on the Fedora Council and Fedora Mindshare Committee, chair the Code of Conduct Committee, lead the annual planning of the Flock to Fedora conference, and continue the financial stewardship of our project resources.

Simultaneously, Justin Wheeler will transition into a new position: AI Alignment Community Architect. This role allows for a dedicated focus to align Fedora’s existing and future AI adoption with Fedora community values and norms. This gives more time and attention for him to participate in Fedora community discussions that explore a future with AI builder downstreams, this role will focus on formalizing community AI services, mentoring contributors, and ensuring that major AI-related initiatives in the default Fedora Linux experience align with Fedora’s Four Foundations: Freedom, Friends, Features, First.

What stays the same

While our day-to-day focuses are shifting, the biggest constant remains our shared commitment to Fedora and CentOS. We are both remaining deeply involved in our current communities through our work at Red Hat, and we are committed to ensuring this transition maintains the health and momentum of our ongoing community work.

This transition marks a strategic expansion of Red Hat’s investment in Fedora, rather than a departure. We are excited about this next chapter and the ability to dedicate more specific focus to both our foundational community operations and our emerging technical horizons.

We look forward to continuing this work with all of you through the Fedora Linux 45 release cycle and beyond. Thank you for your patience as we work through the transition.

El Protocolo Crisol: Refactorización Red-Team/Blue-Team con IA

Posted by Rénich Bon Ćirić on 2026-07-30 08:00:00 UTC

Hace ya varios meses se me ocurrió una idea para resolver una de las broncas más frustrantes cuando programas con inteligencia artificial. Llevo un buen rato probándola, puliéndola y echándole coco en proyectos reales de infraestructura y desarrollo core y, la neta, los resultados están bien perros. Hoy te quiero compartir exactamente cómo funciona The Crucible Protocol (El Protocolo Crisol) para que tú también lo puedas aplicar en tus flujos de trabajo.

Ya sabes cómo se pone el asunto cuando le pides a un agente de IA que te refactorice un módulo o te arregle un bug complejo: el bato se pone a tapar el sol con un dedo. Para salir del paso rápido, te mete un //nolint:, se traga las excepciones en silencio, o se inventa abstracciones raras que ni al caso. Y si pones a un solo agente a revisar su propio código, el sesgo de confirmación hace que no vea sus mermas. De hecho, hasta creo que los agentes se aburren de tu proyecto y empiezan como niños de 5 años; a hacerse weyes. ;D

Para acabar de una vez por todas con esas alucinaciones y mañas, diseñé este loop iterativo, estricto y de cero confianza (zero-trust) que combina agentes de ataque Red-Team en parejas con auditoría Blue-Team hasta lograr un código 100% puro.

Note

El nombre le queda al putazo: un crisol es ese recipiente donde se funden los metales a temperaturas extremas para separar la escoria del oro puro. Eso mismito le hacemos al código aquí, compa.

La Revelación: Por qué Necesitaba una Pareja de Adversarios

En mis primeros experimentos hace meses, intenté usar un solo agente "revisor estricto". Pero me topé con dos extremos igual de malos:

El sesgo de confirmación del creador:
El agente que escribió la solución siempre defenderá su postura. Si cometió una falla de diseño, buscará el parche más superficial nomás para que pase la prueba rápido.
La pedantería hiperbólica del revisor único:
Si creas un agente súper mamón para revisar, empieza a alucinar problemas inexistentes, quejándose de patrones perfectamente válidos o exigiendo reescrituras masivas que nomás rompen todo.
La trampa del "último chequeo" (flojera del orquestador):
Otro problema bien común que detecté en la práctica es que, aunque le digas explícitamente al agente que revise en loop hasta que todo esté bien, el vato termina dándole instrucciones mañosas al sub-agente de QA de que "haga una última revisión rápida" para ya dar por terminado el jale, saltándose la verdadera convergencia.

La solución que descubrí tras meses de afinar el jale fue dividir la revisión de ataque en dos roles secuenciales: un atacante sin freno (extreme_adversary) seguido inmediatamente por un juez pragmático (measured_adversary), imponiendo reglas de parada estrictas donde el orquestador no puede decretar el cierre por su cuenta.

El Flujo de Desarrollo: TDD e Implementación a Ciegas

Es fundamental entender dónde encaja este protocolo dentro de todo el ciclo de ingeniería. El Protocolo Crisol no trabaja en el vacío; depende de una disciplina estricta de Desarrollo Guiado por Pruebas (TDD):

  1. Paso 1: Especificaciones y Hojas de Ruta: Primero se crean las especificaciones (técnicas, funcionales y de negocios) junto con el roadmap por fases.
  2. Paso 2: Generación de Pruebas (TDD Estricto): Se escriben las pruebas automatizadas (unitarias y de integración) directamente desde las especificaciones. Estas pruebas deben fallar al inicio.
  3. Paso 3: Implementación a Ciegas: El desarrollador construye el código guiándose únicamente por las especificaciones, sin leer las pruebas. Al implementar "a ciegas", se evita que el modelo haga trampa o maquille la lógica para complacer al test.
  4. Paso 4: El Protocolo Crisol: Una vez creada la implementación inicial, se desata el enjambre Red-Team/Blue-Team para refactorizar, auditar y pulir el código hasta alcanzar convergencia total.

El Enjambre: La Arquitectura del Protocolo Crisol

Dividimos la responsabilidad en cinco etapas bien delimitadas usando sub-agentes especializados:

┌─────────────────────────────────────────────────────────┐
│ 1a. EXTREME ADVERSARY (Ataque Hiper-Pedante)            │
│ Busca hasta el mínimo olor a código y fallas de diseño  │
└────────────────────────────┬────────────────────────────┘
                             │ (Pasa reporte de ataque)
                             ▼
┌─────────────────────────────────────────────────────────┐
│ 1b. MEASURED ADVERSARY (Adjudicación y Auditoría)       │
│ Filtra alucinaciones y crea lista definitiva de tareas  │
└────────────────────────────┬────────────────────────────┘
                             │ (Entrega lista verificada)
                             ▼
┌─────────────────────────────────────────────────────────┐
│ 2. DEVELOPER AGENT (Refactorización y Corrección)       │
│ Aplica correcciones de raíz (Sin Expansión de Alcance)  │
└────────────────────────────┬────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│ 3. SECURITY QA (Verificación Blue-Team)                 │
│ Corre linter, pruebas automáticas y audita diffs        │
└────────────────────────────┬────────────────────────────┘
                             │
                             ├─── [Fallas en QA] ──► 4. Corregir y Re-verificar
                             │
                             ▼ [Pasada Limpia]
┌─────────────────────────────────────────────────────────┐
│ 5. CONVERGENCE GATE (Loop Iterativo de Red-Team)        │
│ Re-inicia la cadena de ataque hasta obtener 0 hallazgos │
└─────────────────────────────────────────────────────────┘

Las 5 Etapas Explicadas Paso a Paso

Etapa 1a: Ataque Encarnizado con extreme_adversary:
Lanzamos primero al extreme_adversary (sin permisos de modificación de archivos). Su única misión es destrozar el código buscando violaciones a SOLID, acoplamiento lechozo, manejo deficiente de errores, falta de propagación de contextos y casos de borde no contemplados. Es súper pedante a propósito.
Etapa 1b: Adjudicación Pragmática con measured_adversary:
Aquí está la verdadera magia. Le entregamos el reporte de ataque al measured_adversary. Este agente entiende perfectamente que el adversario extremo es extraordinariamente hábil y capaz de detectar fallas sutiles que a cualquiera se le pasan, pero también sabe que la presión brutal que le impone su prompt extremo (que lo obliga a encontrar defectos a como dé lugar) a veces lo hace alucinar problemas inexistentes o exagerar nimiedades. El measured_adversary contrasta cuidadosamente cada reclamo contra el código real, filtra las alucinaciones provocadas por la presión del prompt, valida los defectos genuinos y emite la lista definitiva y verificada de tareas.
Etapa 2: Refactorización por el Agente Desarrollador:

El desarrollador recibe únicamente la lista verificada y aplica las correcciones de raíz.

Important

Aquí rige la Directiva de No Expansión de Alcance: el desarrollador tiene estrictamente prohibido andar inventando características nuevas nomás porque sí. El loop es primordialmente para limpiar, refactorizar y reparar.

Sin embargo, existe una excepción de último recurso: si para resolver un problema de diseño grave o una falla estructural no queda más remedio que desarrollar una nueva implementación o un componente de soporte totalmente nuevo, esto se permite únicamente como medida excepcional de último recurso con el fin de sanar la arquitectura de raíz.

Etapa 3: Verificación Blue-Team con security_qa:
Una vez hechos los cambios, entra security_qa a ejecutar linters en seco (como golangci-lint run), correr la suite de pruebas unitarias y verificar que los diffs no introduzcan vulnerabilidades de seguridad ni regresiones.
Etapa 4: Convergencia de QA:
Si security_qa detecta el menor detalle o advertencia de compilación, el desarrollador lo corrige de inmediato y se vuelve a auditar hasta obtener un pase 100% impecable.
Etapa 5: Gate de Convergencia Final:
Una vez que QA aprueba, volvemos a lanzar la cadena de ataque Red-Team completa (Etapas 1a y 1b). El protocolo termina ÚNICAMENTE cuando ambos adversarios declaran 0 hallazgos (VERDICT: APPROVE - 0 ISSUES FOUND).

Cómo Implementar las Personas de los Sub-Agentes

Para que esto te jale al cien en tu entorno (ya sea con Antigravity, Opencode o la herramienta de agentes que utilices), te comparto las definiciones clave de los prompts que uso:

Prompts del Red-Team:

{
  "extreme_adversary": {
    "role": "Extreme Adversarial Code Reviewer",
    "prompt": "Inspect code brutally and pedantically. Hunt for architectural smells, coupling leaks, SOLID violations, error swallowing, missing context propagation, and unhandled edge cases.",
    "enable_write_tools": false
  },
  "measured_adversary": {
    "role": "Measured Adversarial Auditor",
    "prompt": "Evaluate extreme_adversary's report against the codebase. Understand that extreme_adversary is highly skilled at finding subtle bugs but prone to hallucinating or exaggerating due to extreme prompt pressure. Filter out hyper-pedantic noise, exaggerations, or hallucinations. Validate genuine defects and deliver the definitive task list.",
    "enable_write_tools": false
  }
}

El Límite de Pasos y la Estrategia por Pasadas

Un detalle técnico crítico que descubrí en la práctica es que los agentes no deben intentar revisar todo el proyecto de un solo jalón. Si pretendes que un adversario audite un repositorio entero en una sola ejecución monolítica, el modelo se satura, se brinca archivos o termina haciendo una revisión superficial nomás por pura fatiga.

La clave está en fijar límites de pasos acotados y trabajar mediante múltiples pasadas enfocadas:

  1. Acotamiento por Dominio: En lugar de lanzar una auditoría global masiva, cada pasada del extreme_adversary se delimita a un módulo o paquete de dominio específico.
  2. Pasadas Progresivas: El agente procesa un conjunto acotado de archivos en cada iteración. Al limitar el presupuesto de pasos, fuerzas al modelo a profundizar de verdad en la arquitectura de ese bloque en lugar de andar explorando por encima.
  3. Convergencia Acumulativa: El loop del protocolo se repite haciendo varias pasadas secuenciales. Conforme se aprueba un módulo, la cadena avanza al siguiente hasta que todo el proyecto alcanza la convergencia total con cero hallazgos.

Reglas de Oro Aprendidas en el Campo de Batalla

  1. Cero Tolerancia a Parches Superficiales: Prohibido usar directivas para ocultar errores como //nolint: o bloques try/except: pass. Si el linter chilló, el código se reestructura bien.
  2. Manejo Explicito de Errores: Todo error debe ser capturado, logueado estructuradamente y envuelto (wrapping con %w en Go o el estándar equivalente en tu lenguaje).
  3. Bitácora Obligatoria de Sesión con mi protocolo PJP: Registra cada iteración completada en la bitácora del proyecto usando la CLI de mi protocolo PJP (Project Journaling Protocol) mediante ajourn log para mantener trazabilidad inalterable de las decisiones de diseño.

Tip

Llevo meses usando este protocolo en módulos críticos donde un fallo en producción sale muy caro. La neta, el tiempo extra que toma la convergencia se paga solo con la tranquilidad de tener un código impecable.

Note

Para que el Protocolo Crisol brille en todo su esplendor, se complementa de maravilla con mi estructura de especificaciones (specs) y roadmaps por fases. Mis especificaciones no son cualquier borrador rápido; abarcan tres niveles clave: técnicos, funcionales y de negocios, lo que le da a los agentes los límites exactos de la arquitectura y la visión del proyecto. Ese tema de la metodología de especificaciones y roadmaps está tan chingón que merece su propio espacio, así que te lo platicaré a detalle en un próximo artículo.

Conclusión

El Protocolo Crisol demuestra que la mejor forma de trabajar con IA no es pedirle que haga todo a la primera, sino poner a competir a agentes especializados dentro de una estructura de cero confianza. La separación entre ataque y adjudicación es lo que marca la diferencia entre un código parcheado y una arquitectura sólida como roca.

Pruébalo en tu próximo refactor complejo y verás cómo cambia la jugada. ¿Qué te parece este enfoque? ¡A poco no está perrísimo, no?!

🎲 PHP version 8.4.24RC1 and 8.5.9RC1

Posted by Remi Collet on 2026-07-17 04:07:00 UTC

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

RPMs of PHP version 8.5.9RC1 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.24RC1 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.9RC1 is in Fedora rawhide for QA
  • version 8.6.0alpha3 is also available in the repository
  • EL-10 packages are built using RHEL-10.2 and EPEL-10.2
  • EL-9 packages are built using RHEL-9.8 and EPEL-9
  • EL-8 packages are built using RHEL-8.10 and EPEL-8
  • oci8 extension uses the RPM of the Oracle Instant Client version 23.26 on x86_64 and aarch64
  • intl extension uses libicu 74.2
  • RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
  • versions 8.4.19 and 8.5.4 are planed for March 12th, in 2 weeks.

Software Collections (php84, php85)

Base packages (php)

🛡️ PHP version 8.2.32, 8.3.32, 8.4.23, and 8.5.8

Posted by Remi Collet on 2026-07-03 04:31:00 UTC

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

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

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

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

⚠️ PHP version 8.1 has reached its end of life and is no longer maintained by the PHP project.

🛡️ These Versions fix 3 security bugs (CVE-2026-12184, CVE-2026-14355), so the update is strongly recommended.

Version announcements:

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

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.5 as Software Collection

yum install php85

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

⚠️ To be noticed :

  • EL-10 RPMs are built using RHEL-10.2
  • EL-9 RPMs are built using RHEL-9.8
  • 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)

You can now opt in to share your blog posts on GNOME’s Discourse

Posted by Felipe Borges on 2026-07-29 11:45:27 UTC

We’ve just rolled out a new feature on Planet GNOME to bring our community discussions together! You can now opt in to automatically create a topic on discourse.gnome.org whenever you publish a new blog post.

Having comments centralized on Discourse makes it much easier for readers to discuss your posts, while also ensuring that all interactions are moderated under the GNOME Code of Conduct for a safer, healthier space. It is also a great way to give your content a bit more visibility with the active Discourse community without any extra manual work.

This is especially handy if you run a statically generated blog without an existing comment section, giving your readers a dedicated space to share feedback.

This feature is completely opt-in, so nothing will change for your feed unless you choose to turn it on. To get started, simply send a merge-request to Planet GNOME adding discourse_comments=1 to your blog entry in our config.ini file.

For this to work, I got the Planet’s static generator to produce a custom RSS feed for the blogs that flag the discourse_comments property. Then, Emmanuele Bassi configured our Discourse instance with the RSS Polling plugin, which creates a topic for each RSS feed entry.

Since this is brand new, there might still be a few rough edges. If anything breaks or acts weird when you try it out, let us know and we’ll get it fixed as soon as we can.

Happy blogging!

Syslog-ng hardening using Tor

Posted by Peter Czanik on 2026-07-29 11:37:05 UTC

For many years, I didn’t think that Tor could be useful for me. However, I’ve recently found a Gist on GitHub that describes how you can use it to harden your central syslog-ng server. And while I have yet to try it, at least now I have a reason to actually test Tor.

The Tor website describes the project as follows: “Protect yourself against tracking, surveillance, and censorship.” I live in a country where thankfully I do not need these, nor do I perform any activities for which Tor would be useful. However, sometimes I hear from syslog-ng users that they want to hide their logging infrastructure with something more than what mutual TLS authentication makes possible. This is where this short how-to might be useful for you:

https://gist.github.com/hashgh0st/19bcfa4bfc96fbf0bbd2897b66c77db7/

The Gist is about how to install / configure syslog-ng and Tor on a FreeBSD client and server. I have a couple of FreeBSD boxes lying around, so I will test the instructions there. However, with minimal changes, the procedure should work on any Linux distribution as well.

syslog-ng logo

Originally published at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-hardening-using-tor

Flock 2026 Afterburn: a retrospective

Posted by Fedora Magazine on 2026-07-28 08:00:00 UTC
A graphic reads "RECAP flock, Prague, Czech Republic, June 14 - 16, 2026" alongside an illustration of a colorful pigeon holding a megaphone.

When I heard that Flock was the most awaited event every year for the Fedora community, and that I was going to be a part of it, I was genuinely excited. Gradually, I found myself involved right in the middle of Flock 2026 planning. Months of planning. Dozens of meetings. Meeting notes referenced and re-referenced every single week. New ideas, new proposals, sponsor packages, food logistics, team gifts, a candy swap, a games night, a Foundations Wall made of sticky notes and community feelings all of it building toward one event. Three days in Prague. That’s what Flock to Fedora is. And this year, Flock 2026 delivered.

This article is a brief summary and recap of what happened at Flock 2026 this year in Prague, Czechia. It covers my perspective as an intern in the Fedora community, working in the middle of all the action. Read on to know more about what happened at this year’s annual contributor conference!

Why this one stood out

Flock to Fedora 2026 ran from June 14–16 in Prague, Czechia, in the same city for the second time in a row. Sponsorship hit record numbers this year, with more unique sponsors committing to Flock than any past edition. A huge thank you to AlmaLinux, Arm, AWS, CentOS, Fleet, Framework Computers, Meta, Microsoft Azure, openSUSE, Red Hat, Rocky Enterprise Software Foundation, and Zabbix for making it possible.

The schedule this year was planned starting with “Day 0” (Sunday, June 14) with workshops and team meetups. Day 1 and Day 2 were about keynotes and streamed sessions built around Flock’s four themes: 

  • Freedom (open hardware, AI, and open standards)
  • Friends (mentorship, onboarding, and community stories)
  • Features (packaging, infrastructure, and engineering excellence)
  • First (the road to Fedora Linux 45 and 46, which lay the groundwork for CentOS Stream 11 and EPEL 11)

Behind the execution of Flock, there was an incredible organizing team which handled everything from CfP logistics and on-site execution to design, travel coordination, website improvements, and a Matrix virtual experience that brought the conference to people who couldn’t make it to Prague in person (one like me). Planning kicked off months before the event, with weekly meet-ups, shared meeting notes, and sprint-by-sprint coordination across time zones and contributors. Flock doesn’t happen without these people.

Two community-driven additions gave Flock 2026 its own identity. The #CommitHistory interview campaign brought eight Flock speakers to Fedora Magazine, before the event even started, to share their first commit stories, contributor journeys, the very human reasons people keep showing up for this project, and why it really matters in this community. Also the Foundations Wall, a new interactive installation at the registration desk, asked attendees to share what Fedora’s Four Foundations mean to them on a whiteboard.

What the community said

The post-event survey closed on 8th July with 117 responses and a 57.35% response rate. The results told a clear story. Nearly every single respondent said they felt more connected to the Fedora community after attending Flock in-person. In a community that does most of its work asynchronously across time zones, mailing lists, and Matrix channels, that response is everything.

The hallway track rated highest of all. Above the keynotes, above the workshops, above the sessions. The informal conversations, that’s what people came for. One respondent put it perfectly:

“Flock is starting to feel like a family gathering, but a good one.”

Sessions were rated valuable or extremely valuable by 92% of respondents. The venue and organization scored Excellent or Good from 97% of respondents. The reception night, the candy swap, the games night on Day 0, all of it landed warmly in the open responses.

The constructive feedback? Noise levels made hallway conversations harder than they needed to be. People wanted more unstructured hacking space. Virtual attendees wanted clearer navigation instructions for the online experience. As the organizing team begins to review the data and compare against our own feedback, we hope to take these ideas for improvements into the next edition of Flock.

What happened after Prague

The real measure of Flock is never the event alone. Another big part is what contributors do once they get home.

In the 30 days since Prague, the conversations that started in corridors have continued in Fedora Discussion threads. A fuller picture of survey responses and feedback will be part of a future Fedora Council town hall video meeting later this summer.

See you in 2027!

Survey respondents have spoken on what comes next. The organizing team is processing the feedback as we begin setting our sights on the next edition.

Flock 2027 is coming. And honestly? This time I’m hoping to be there in person. Fingers crossed.

Mount virtual media on Supermicro IPMI with less java

Posted by Major Hayden on 2026-07-28 00:00:00 UTC

It’s been a while since I rented a dedicated server for my own personal infrastructure, but with the prices I’ve seen lately on cloud and virtual infrastructure, getting my own server seemed like a better detal. I prefer to do my own custom installation of Fedora Linux on my servers and this meant another deep dive into the world of Supermicro’s IPMI interface, horribly old versions of Java, and lots of frustration.

With some help from Claude, I found a better way to mount virtual media! ✨

Old BMC without HTML5

It turns out I rented a machine with a fairly old ATEN-based BMC without any support for Redfish and that means no HTML5 console access. The Java console was the only remaining option.

Next, I downloaded Supermicro’s standalone IPMIView client. It launched and connected without an issue. Once I tried to mount an ISO, I ended up with a crash:

SIGSEGV (0xb), JRE 11.0.25 (bundled)
Problematic frame: V [libjvm.so] jni_CallObjectMethodV+0x83
C [libSharedLibrary64.so] AppendDataIntegrity(unsigned char*, int)+0xc6
C [libSharedLibrary64.so] MtMethod_Media+0x105
C [libSharedLibrary64.so] MtVM_Engine+0xba
C [libSharedLibrary64.so] Core_Mount_VM+0x45
C [libSharedLibrary64.so] UI_Mount_VM+0x227
C [libSharedLibrary64.so] Java_tw_com_aten_vstorage_VirtualStorage_VUSPlugIn+0x146
j tw.com.aten.vstorage.VirtualStorage.VUSPlugIn(...)

I tried bumping the java heap size and it didn’t help. Downgrading IPMIView didn’t help either. I even loaded up a Windows virtual machine with IPMIView and it crashed there, too.

What actually worked: SMCIPMITool

Supermicro ships another utility called SMCIPMITool that talks to the BMC in a different way than the GUI does. I always prefer a command line tool over a Java GUI. 😉

  1. Download SMCIPMITool from Supermicro: https://www.supermicro.com/wdl/utility/SMCIPMItool/

  2. Extract it:

    $ tar xzf SMCIPMITool_<version>_bundleJRE_Linux_x64.tar.gz
$ cd SMCIPMITool_<version>_bundleJRE_Linux_x64

  3. Confirm that the basic IPMI auth works before touching virtual media. If your account isn’t a full ADMINISTRATOR, specify the privilege level explicitly:

    $ ipmitool -I lanplus -L OPERATOR -H <bmc-ip> -U <user> -P '<password>' chassis status

    If this fails with a cipher suite error, try -C 1, -C 2, or -C 3.

  4. Launch SMCIPMITool in interactive shell mode. This is required — the vmwa subcommands don’t work as one-shot CLI arguments:

    $ ./SMCIPMITool <bmc-ip> <user> '<password>' shell

    Ignore any Cannot login to <bmc-ip> banner printed at startup. That’s an unrelated SNMP trap-receiver warning, not an auth failure.

  5. List the vmwa subcommands at the shell prompt to confirm the tool is talking to the BMC correctly:

    vmwa

  6. Mount the ISO on virtual device 2 (device 2 is CD/DVD/ISO; device 1 is HDD/USB/floppy):

    vmwa dev2iso /full/path/to/your.iso

    You may see a com.supermicro.ipmi.IPMIException stack trace print first — that’s a non-fatal internal retry. Look for the actual result right after it:

    Mounting ISO file: /full/path/to/your.iso
Device 2 :VM Plug-In OK!!

  7. Verify the mount:

    vmwa status

    You should see something like this:

    Device 2: ISO File [/full/path/to/your.iso]

  8. Keep the shell session open. On this firmware, the mount is torn down the instant the shell exits — there’s no detached or background mount mode. For an unattended mount-and-install, script it end-to-end instead of typing interactively:

    ( echo "vmwa dev2iso /full/path/to/your.iso"
 echo "vmwa status"
 sleep 3600 # keep mounted for up to an hour — adjust to your install time
 echo "vmwa dev2stop" ) | ./SMCIPMITool <bmc-ip> <user> '<password>' shell

  9. While that session is running, set the next boot target to USB CDROM in the IPMIView tool. Then reboot the server.

  10. The server should boot into the ISO that you mounted. The BMC network interface isn’t very fast and you’re also limited by your upload bandwidth, so be patient.

  11. When you’re done, either let the sleep in step 8 expire (it auto-unmounts via vmwa dev2stop), or run vmwa dev2stop manually in an active shell session to unmount immediately.

Here’s the actual command I used, end to end:

$ D=~/Downloads/SMCIPMITool_2.27.2_build.230221_bundleJRE_Linux_x64
$ cd "$D"
$ ( echo "vmwa dev2iso /home/major/Downloads/Fedora-Server-netinst-x86_64-44-1.7.iso"
 echo "vmwa status"
 sleep 3600
 echo "vmwa dev2stop" ) | ./SMCIPMITool <bmc-ip> operator '<password>' shell

Authentication degraded

Posted by Fedora Infrastructure Status on 2026-07-27 22:00:00 UTC

Our ipa cluster is all reinstalled, but some issues remain:

  • https://accounts.fedoraproject.org is sometimes not allowing people to login. It gives a 'Unauthorized: bad credentials'. This seems sporadic and unclear how many people it effects.

  • fasjson is working, but slow to respond. This can result in things like …

From July 20 to July 26

Posted by Aurélien Bompard on 2026-07-27 16:51:00 UTC

Across the various Fedora working groups, the primary shared focus this week was the successful completion and subsequent fallout management of the Fedora 45 Mass Rebuild, which required extensive coordination from Release Engineering, Quality, and language-specific SIGs (like Python and Perl) to triage build failures and ABI changes. Another major cross-team initiative is the ongoing infrastructure migration to Forgejo, with the Docs, Infrastructure, Design, and Release Engineering teams actively working to transition repositories away from Pagure ahead of strict deadlines. Security, cryptography, and compliance also emerged as a prominent theme, highlighted by FESCo's new two-factor authentication (2FA) mandate for packagers, the Security SIG's efforts to align with the EU Cyber Resilience Act (CRA), and system-wide cryptography updates like the transition to Sequoia. Finally, teams are heavily engaged in Fedora 45 feature stabilization and policy refinement, actively addressing cross-desktop bugs—such as the memory-crashing default wallpaper in KDE—while updating governance and packaging guidelines to reduce contributor burnout and streamline community workflows.

Announcements

For Fedora contributors, the Fedora 45 Mass Rebuild has officially completed, and a reminder was issued that the F45 Self-Contained Change proposal deadline has closed. To reduce contributor burnout and avoid split-brain conversations, an F46 Change Proposal aims to move all future Change discussions exclusively to the devel mailing list, ending simultaneous threads on Discourse. In other community news, the long-running Community weekly updates are being replaced by "This Week in Fedora". Developers looking to test new tools can engage with a proposed F45 Change to introduce encapsule, a new CLI utility for safely running untrusted internet scripts in isolated containers, which pairs nicely with a recent Fedora Magazine guide on sandboxing AI coding agents with microVMs.

Numerous technical Change Proposals were announced this week, notably for Fedora Atomic Desktops, which are slated to adopt the new Anaconda WebUI and gain web-based remote installation support. On the security and cryptography front, Fedora plans to transition RPM signature verification to Sequoia via a new %openpgpverify macro to support Post-Quantum Cryptography, and will begin phasing out the deprecated in-kernel Crypto Userspace API. System-level updates include deprecating the low-memory-monitor package in favor of native GLib handling, enabling systemd-oomd and zram swap by default on CoreOS, and updating authselect to both hardcode nss-altfiles and remove the outdated NIS profile. Finally, desktop users will benefit from an update to IBus 1.5.35, which improves XKB keymap handling across Wayland environments.

Council

The Fedora Council is currently seeking community feedback on a draft Conflict of Interest Policy intended to guide governance groups. Following initial discussions, the draft will be revised to ensure it only applies to governance bodies, removes overly strict recusal requirements (such as preventing FESCo members from voting on their own changes), and protects contributor privacy under GDPR by not requiring the disclosure of the specific nature of a conflict. In infrastructure news, the Council advanced the Fedora Forge usage policy after reaching a compromise to mandate a "tickets" repository for all organizations as a unified contact method, rather than automatically archiving inactive repositories after 12 months.

Additionally, the Council addressed a few administrative requests. They investigated suspicious Forge organization requests originating from newly created accounts; while a vague Software Engineering SIG request was rejected, the situation successfully led to the revitalization of the Java SIG by an established contributor. The Council also reviewed a trademark permission request to sell Fedora community stickers on a Slovak open-source web shop, and granted an exception for FreeIPA to host an organization on the Fedora Forge due to its foundational role in Fedora Infrastructure.

Decisions

Learn more about the Council team.

FESCo

FESCo had a highly active week reviewing numerous Fedora 45 Change Proposals and discussing project policies. Major technical discussions included the Forgejo dist-git migration planning, a proposal to restrict Change Proposal discussions to the devel mailing list to prevent "split-brain" conversations, and a fast-track proposal to gate all stable release updates on rmdepcheck. The Enable Shadow Stack by Default on x86_64 proposal was deferred pending a clarified mitigation plan for affected software like Rust, Python extensions, and NVIDIA drivers.

On the security and contributor front, FESCo is officially requiring two-factor authentication (2FA) for all provenpackager group members, with a three-month grace period for existing members before their access is temporarily downgraded. A broader proposal to require 2FA for all packagers is also currently in the works. Additionally, the FESCo election policy was adjusted so that replacements for members stepping down mid-term will serve a full year if only one person drops out.

Decisions

Learn more about the FESCo team.

Packaging Committee

During their 2026-07-23 meeting, the Packaging Committee addressed broken links in the DefaultServices guidelines (FPC#1556), agreeing that linking directly to the fedora-release source tree is too fragile and difficult to maintain. They also reviewed a draft update for NPM packaging guidelines (FPC PR#1553). Contributors noted concerns with the draft's example spec file—specifically regarding how bundled libraries are handled as separate source tarballs and the disabling of automatic requirements. The committee will wait for the Node.js SIG to finalize the draft and address these concerns before conducting a deeper review.

Additionally, the committee discussed the need for clearer versioning guidelines for pre-release snapshots. A pull request is currently being drafted to explicitly define the use of the ~^ syntax, ensuring that untagged snapshots sort correctly before tagged pre-releases (e.g., beta1). This clarification will be proposed for gradual adoption to avoid disrupting existing packages and to help maintainers avoid sorting errors.

Decisions

  • The committee agreed to remove the fragile source tree links in the DefaultServices guidelines and replace them with a general text instruction directing packagers to check the fedora-release package directly.
  • Formal review of the new NPM packaging guidelines is paused until the Node.js SIG removes the work-in-progress status and addresses initial feedback.

Learn more about the Packaging Committee team.

Mindshare

In their July 23 meeting, the Mindshare committee discussed shifting their social media strategy to rely on "Digital Ambassadors" rather than a dedicated Marketing team, proposing the use of Buffer to securely manage account access. This new direction will be tracked in a fresh ticket, replacing the outdated issue #26. The team also addressed regional support by reviewing a swag request for the French community (issue #126) and noted the need to update the Meetbot documentation to reflect Matrix-native commands.

On the contributor engagement front, the CommOps team is actively seeking new members and a committee representative, prompting the reopening of CommOps issue #145. Highlighting this opportunity, a new contributor with a communications background recently introduced themselves on the forum to join CommOps. Meanwhile, the committee continues to seek asynchronous votes to finalize the Mindshare representative for the Fedora Council.

Decisions

  • Approved approximately $500 in swag for the French community to cover a year of local and regional distribution.
  • Decided to close the three-year-old social media access ticket and open a new one focused on testing Buffer for Digital Ambassadors.
  • Reopened the ticket for the vacant CommOps representative seat to encourage volunteer engagement.
  • Extended the vote for the Mindshare Council representative by one week to allow for asynchronous participation due to a lack of meeting quorum.

Learn more about the Mindshare team.

Workstation / GNOME

The f45-backgrounds package is now available in Rawhide, introducing wide-gamut color support for the default Fedora 45 wallpaper. To provide a cleaner Appearance menu, the "Time of Day" animated wallpapers have been separated into optional, dedicated sub-packages for GNOME and MATE. Shortly after the release, testers reported that the default wallpaper was rendering as solid grey in KDE due to memory allocation limits being exceeded by the massive 12800x12800 .jxl image file (mailing list thread). The design team will shrink the image to 8K in the next update to resolve this.

On the networking side, a forum discussion highlighted an issue with Fedora's IPv6 behavior on networks with non-persistent prefixes. When a router reboots and fails to invalidate old prefixes, Fedora attempts to route through older IPv6 addresses instead of defaulting to the newest one, causing connectivity drops until the old lease expires. Contributors are looking into a proper NetworkManager or kernel-level fix, but in the meantime, users can employ NetworkManager dispatcher scripts listening for dhcp6-change events as a temporary workaround.

Decisions

  • The "Time of Day" animated wallpapers have been split out of the main background packages into dedicated sub-packages (f45-backgrounds-gnome-time-of-day and f45-backgrounds-mate-time-of-day).
  • The default Fedora 45 wallpaper resolution will be reduced to 8K to fix memory allocation failures in KDE Plasma.

Learn more about the Workstation / GNOME team.

KDE

This week, the KDE group discussed a multi-monitor window management behavior where connecting an HDMI display automatically moves all open windows to the external screen, even if the laptop screen remains the primary display. Participants identified that KDE remembers window layouts and specific monitor hardware identities from previous sessions, which is likely a side-effect of the desktop environment's new "session restore" feature. While some users appreciate this persistent layout, others find it disruptive, particularly when applications do not open on the currently active desktop.

Contributors noted that this is an upstream KDE matter rather than a Fedora-specific bug. The behavior has been reported to the KDE bug tracker, and users clarified that it persists even when virtual desktops are configured to switch independently for each screen. Developers and contributors interested in refining session restore logic, multi-monitor window placement, or adding options to clear saved monitor layouts are encouraged to engage with the upstream KDE community to help improve this functionality.

Learn more about the KDE team.

Server

During the weekly Server WG meeting, contributors advanced the Fedora home server spin-off by outlining a minimal KIWI development environment using libvirt, which will be documented in the home-server repository README. The group also discussed standardizing documentation styling, with a strong preference emerging for using backticks for CLI commands and file paths; a formal proposal will be added to the open pull request. In community news, voting to officially add Brett and Ro as working group members remains open until July 31, and contributors are encouraged to participate in manual installation testing for the upcoming Fedora 45 release.

In a forum discussion about Fedora's handling of non-persistent IPv6 prefixes, a community member provided a workaround for routers that fail to invalidate old prefixes after a reboot. Users experiencing connectivity drops can use NetworkManager's dispatcher.d to run a cleanup script on dhcp6-change, as there is currently no native kernel or NetworkManager option to force the system to exclusively use the newest IPv6 address.

Decisions

  • For Fedora 45 release testing, the links in the tracking tickets will be updated to point to the newest test build, and the tickets will be left in their current status columns to restart the manual testing cycle.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team made significant progress on the RHEL10 migration, successfully transitioning the batcave Ansible control host and IPA (FAS) systems, which caused some expected temporary monitoring alerts. Preparations for the Fedora 45 Mass Rebuild are also underway, including the removal of the F45 autosign config to prevent unnecessary re-signing by robosignatory, aligning with the recent F45 self-contained change deadline. On the Forgejo front, the team packaged Forgejo 15.0.5, deployed a new CI runner for the Marketing team, and began prototyping ForgeFiler—a Flask web application designed to securely handle sensitive reports like Code of Conduct violations and GDPR requests in private repositories.

There are several excellent opportunities for contributor engagement this week. The team is actively looking for help investigating broken image links on older MediaWiki pages, resolving grokmirror missing repository issues, and improving Zabbix monitoring by investigating SLA structures to reduce alert fatigue. Additionally, work continues on a Grafana proof-of-concept for the Fedora Data Working Group and the deployment of the new siguldry signing bridge in the staging environment.

Decisions

  • The team decided to set up a staging instance of public-inbox for SCM commits, utilizing yearly archives and placing it behind Anubis to evaluate its performance and manageability before a potential production rollout.

Learn more about the Infrastructure team.

Release Engineering

The Fedora 45 Mass Rebuild has successfully concluded, utilizing new retry logic scripts and updated, beginner-friendly documentation. Following the rebuild, Release Engineering ran the mass tagging script and filed FTBFS bugs for failing packages. To stabilize the buildroot and unblock Rawhide composes, several problematic builds—including desktop-backgrounds, jsoncpp, and openssl-pkcs11—were untagged. In other release news, F47 keys have been added to fedora-repos and are now available in updates-testing, and the f45-perl side tag was successfully merged to Rawhide.

Infrastructure migrations are progressing, with toddlers changes prepared for moving scm-requests from Pagure to Forgejo; a coordinated "flag day" will be scheduled once fedpkg updates land. For contributors looking to get involved, there are active efforts to consolidate mass rebuild script configurations and fix false positives in the need_rebuild.py tracker. Finally, maintainers are reminded to use the fedpkg request-unretirement command for automatic package unretirements rather than opening manual Releng tickets.

Decisions

  • The process to re-sign F44 content with the F45 key will be separated into its own Standard Operating Procedure (SOP) document to improve the mass branching workflow.
  • The legacy Pagure fedora-scm-requests repository will be archived only after the new Forgejo repository and related fedpkg changes are fully deployed and verified to prevent synchronization issues.

Learn more about the Release Engineering team.

Quality

The Fedora 45 mass rebuild is now complete, with the next major milestone—the branch point and first change completion deadline—scheduled for August 11th. During their weekly meeting, the Quality team reviewed upcoming F45 Changes to plan community Test Days, highlighting features like RPM 6.1, Podman 6, and DrmPanicFrontend. In news relevant to the broader Linux ecosystem, the team investigated unexpected font changes caused by freetype 2.18 that may also impact CentOS and RHEL. Additionally, it was noted that the mcelog package is currently unmaintained, prompting discussions about finding a new maintainer or replacing it with rasdaemon by default.

For contributors looking to get involved, nightly composes for Fedora 45 Rawhide are actively seeking release validation testing. Testers can also evaluate the new f45-backgrounds package, which separates the "Time of Day" animated wallpapers into optional sub-packages, though an update is pending to fix a bug where the massive 12K image size breaks KDE Plasma. The team also made a major revision to the Fedora CI documentation, added new KDE start/stop tests to openQA, and welcomed a new young contributor looking for a QA sponsor.

Decisions

  • The team decided to group several major Fedora 45 Changes into dedicated test day tickets and initiated coordination with the respective package maintainers to organize these events.

Learn more about the Quality team.

Design

The Fedora 45 backgrounds are now available in Rawhide, introducing wide-gamut color support and splitting the "Time of Day" animated wallpapers into dedicated sub-packages. Following reports that the initial 12800x12800 resolution caused memory crashes in KDE and GIMP, the wallpapers are being scaled down to 8K. Looking ahead, the Fedora 46 wallpaper inspiration poll is live until July 31st, asking the community to choose between four STEM figures whose names start with "U". In infrastructure updates, the team successfully migrated the upstream fedora-logos repository from Pagure to the Design team's Forgejo space, alongside updates to the fedora-remix-logos package.

For contributors looking to get involved, new UX and web design opportunities are available. The Fedora Websites and Apps team is seeking a design for a new credits page to showcase project contributors. Additionally, Project Resistor, a Fedora Remix, needs UX assistance to improve its Jekyll-based website. The team also finalized the YouTube thumbnails for Flock 2026 and continues iterating on a community onboarding flyer and an onboarding video series.

Decisions

  • The upstream fedora-logos and fedora-remix-logos repositories have been officially adopted by the Design team and migrated to Forgejo.
  • The F45 default wallpapers will be resized to 8K to resolve memory allocation issues.
  • The "Time of Day" animated wallpapers for F45 have been separated into dedicated GNOME and MATE sub-packages for a cleaner appearance settings experience.

Learn more about the Design team.

Docs

The Docs team's primary theme this week was platform migration and content consolidation. A major focus remains the Forgejo migration tracker, driven by the strict July 31, 2026, deadline to move all active documentation repositories off Pagure.io. While the majority of Pagure repositories have been successfully migrated, contributors are finalizing the last few pending moves, including the Defensive Coding Guide and the i3 SIG docs. To further streamline information, the team also opened a new ticket to coordinate with Commops to resolve duplicate Special Interest Group (SIG) documentation that is currently split between the legacy Fedora Wiki and the official docs site.

Contributors looking to get involved can assist with the next phase of the Forgejo migration. With the Pagure deadline approaching, the team needs help opening separate planning tickets for remaining GitLab repositories (which involve more complex CI pipeline migrations) and reaching out directly to the owners of various GitLab and GitHub repositories to coordinate their moves.

Decisions

  • The team operationally resolved to formally trigger Commops to complete the SIG wiki page migration to eliminate duplicate content.
  • Remaining GitLab repository migrations will be handled via separate, dedicated planning tickets rather than the main tracker.

Learn more about the Docs team.

Internationalization

During the Internationalization meeting, the team reviewed upcoming Fedora 45 changes, noting that proposals for fontconfig (System Wide Change) and LibreOffice Dictionaries (Self Contained Change) are currently moving through the approval process. The F45 mass rebuild has also finished with under 1,000 failures, and package maintainers are urged to check the failure logs for their packages. Specific rebuild failures with ibus-table and ibus-typing-booster were noted and are actively being investigated.

To help prepare for upcoming releases, contributors are encouraged to assist with Fedora 43 bug triaging by fixing outstanding issues or deferring them to a later release. The team also reviewed the upcoming schedule, highlighting the July 21 deadline for Self Contained Change proposals and the August 11 deadline for both branching Fedora Linux 45 from Rawhide and the testable completion checkpoint.

Learn more about the Internationalization team.

EPEL

This week, EPEL focused on infrastructure improvements and package maintenance, prominently featuring a proposal for EPEL 11's minor version design that was also discussed in the weekly meeting. To prevent private mirroring errors, the proposal suggests keying URLs off the CentOS $stream variable rather than the RHEL $releasever_minor variable, though this first requires RHEL derivatives to stop improperly defining $stream. In package news, an accidental soname change in ImageMagick broke dependencies in EPEL-8 and EPEL-9, but patched builds have been published and are awaiting testing karma. Additionally, a slightly incompatible update replacing p7zip with 7zip is pending further discussion in upcoming meetings.

For contributors, feedback is requested on a planned migration to libgit2 v1.9 for EPEL 9 and 10 to resolve multiple CVEs; the maintainer plans to submit pull requests to affected packages soon. Other notable updates include CVE fixes for ntfs-3g and a contributed fix to fedpkg that enables feature branch workflows directly from EPEL minor version branches.

Learn more about the EPEL team.

ELN

During the July 21st meeting, the SIG announced that image-builder is now successfully building ELN qcow2 images, with hyperscaler images up next. The ELN mass rebuild is currently in progress following the F45 mass rebuild, presenting an engagement opportunity for contributors to help fix over 40 packages currently failing to build (F45FTBFS). Another contribution opportunity involves providing a ppc64le VM to the upstream retsnoop developer to fix architecture-specific bugs. In broader news, LXQt has been added to Extras in preparation for EPEL 10, python-wheel was dropped from ELN proper, and progress continues on bootc with a Konflux tenant merged and plans to explore composefs native images in the future.

Decisions

  • To prevent disruptive surprises, future image change requests (such as altering default partition layouts or dropping firmware) will be filed in the ELN bug tracker and discussed during meetings.
  • boot.iso images will now only be created for BaseOS to match CentOS Stream and RHEL, which saves disk space and speeds up composes by over 30 minutes.

Learn more about the ELN team.

Atomic

This week, the Atomic group saw a brief but helpful update regarding system recovery. In a forum discussion on how to reset the root password in Silverblue, a community member highlighted that official documentation is now available for resetting passwords via rescue mode on Atomic Desktops. This provides a standardized and reliable resource for the broader Linux community when troubleshooting locked atomic systems.

Learn more about the Atomic team.

CoreOS

During the CoreOS meeting on 2026-07-22, the team highlighted that the proposal to merge Butane into Ignition has officially entered the FESCo voting phase. As part of this transition, Butane will undergo a procedural freeze to shift active development directly into the Ignition repository, a move expected to greatly improve configuration composability for users. Additionally, the group reviewed the Fedora 45 release schedule, noting that the proposal submission deadline for Self-Contained Changes has passed, with the next checkpoint for retiring orphaned packages scheduled for August 4th.

A significant portion of the meeting focused on a potentially disruptive proposal to increase the default /boot partition size for new installs. Developers raised concerns that older nodes retaining the smaller partition might eventually lose the ability to upgrade, forcing users to reprovision. To prevent users from accidentally clobbering custom data partitions during this process, an action item was created to form a small working group. This group will brainstorm failure scenarios and design safeguards against inadvertent data destruction, presenting an excellent opportunity for contributors to get involved in shaping safe upgrade paths and documentation.

Learn more about the CoreOS team.

AI & ML

This week, the AI & ML SIG focused on team roster management and establishing infrastructure for AI agent skills development. A notable change in membership occurred as a contributor requested to step down from the SIG due to time constraints and LLM-related burnout (Issue #36). On a broader scale, the group is actively working on standardizing AI capabilities using the Agent Skills specification, which allows guided, agent-neutral skill definitions to be shared, improved, and used by any model.

To support this growing initiative, the SIG successfully established a new "Skills Reviewers" sub-team to create, review, and curate shared AI skills in the skills-library repository (Issue #31). The necessary infrastructure, including a new FAS group and a linked Forgejo team, has been fully deployed and seeded with initial volunteers. For contributors looking to get involved, there is an immediate opportunity to provide feedback on the initial draft of the human reviewer guidelines, which has just been submitted as a pull request.

Decisions

  • Establishment of the Skills Reviewers Team: The SIG officially created the skills-reviewers sub-team in FAS and Forgejo, granting them write access to the ai-ml/skills-library repository. A lightweight review process was instituted, requiring at least one reviewer approval before merging skill PRs (Issue #31).
  • Membership Update: Proceeded with the removal of salimma from all AI/ML SIG access control lists (FAS, Forgejo, and Discourse) per their request to step away from the group (Issue #36).

Learn more about the AI & ML team.

RISC-V

The Fedora 45 mass rebuild is actively underway, with core components like binutils and annobin completed, and GCC 16 and Python 3.14 currently in progress. The team is managing build times across 19 RISC-V builders, noting intermittent build failures on RVA23 hardware and system hangs on P550 boards during Rust builds—though a recent SiFive firmware update resolves the latter. To improve build infrastructure, new high-RAM Titan boards from Arace are arriving, and contributors can help optimize Koji builder profiles to automatically route heavy packages to these faster nodes. Meanwhile, the transition from the K3 vendor kernel to Fedora RISC-V "omni" kernels continues, supported by updated documentation for K3 bootstrap and Milk-V Jupiter.

In broader ecosystem news discussed during the July 21 SIG meeting, PR 778 was merged into upstream rhboot/shim, paving the way for proper signed shim packaging in future releases. Additionally, the team is conducting virtualization testing on remote K3 hardware (including OVMF firmware tests) and engaging in technical discussions with Qualcomm engineers regarding a hardware-probing syscall to detect RISC-V extensions.

Decisions

  • The team will delay switching the mass rebuild tracker over to F45 until the GCC 16 rebuild is fully complete.
  • Despite upstream progress on shim, the SIG will continue using the current standalone shim-unsigned-riscv64 package for the time being to ensure boot stability while the official Fedora packaging is sorted out.

Learn more about the RISC-V team.

Security

This week, the Security SIG focused heavily on aligning Fedora's security documentation with the EU Cyber Resilience Act (CRA) requirements (Ticket #14). During their weekly meeting, the team discussed creating a unified SECURITY.md file that designates Red Hat as the formal CRA steward while maintaining Fedora's community security processes. To improve visibility, contributors proposed surfacing these new policies and a standard security.txt file on Fedora's main marketing sites once completed (Ticket #16).

The group is also working on formalizing private vulnerability reporting channels and embargo processes. Ongoing discussions include setting up a secure Bugzilla component for incoming package and platform reports (Ticket #17), establishing Fedora representation on the private linux-distros mailing list alongside a pre-disclosure agreement (Ticket #13), and potentially creating a Fedora Badge to act as a "hall of fame" reward for external security researchers who submit valid reports (Ticket #18).

Decisions

  • The SIG will use Ticket #14 to document the overarching CRA compliance plan and spin off individual Forgejo tickets for each of the six specific CRA guideline items to allow for parallel work.
  • New security documentation will temporarily be hosted in the forge/security/docs repository to prevent bureaucratic delays while drafting the content.

Learn more about the Security team.

Go

This week, the Go packaging community discussed the introduction of docker-credential-helpers to Fedora. In a thread about packaging the application, contributors shared guidance on handling empty vendor archives and properly configuring CGO_CFLAGS and GO_LDFLAGS using macros to correctly build the pass and secretservice helpers. Additionally, an excellent contributor engagement opportunity has arisen: a call for reviewers and sponsors was made for a new contributor who has successfully recreated the SRPM to adopt the orphaned fx package and is currently awaiting a package review.

Decisions

  • When packaging Go applications with empty vendor archives, spec files should retain the standard vendor macros to ensure consistency across Go packages and future-proof against new dependencies.
  • An empty modules.txt warning from rpmlint (caused by a lack of vendored modules) is not considered a blocker for package approval.

Learn more about the Go team.

Perl

The major focus this week is the Perl 5.44 upgrade, which has been approved by FESCo. A dedicated f44-perl build-root has been created for the delicate process of bootstrapping core modules. To avoid disruptions, contributors are explicitly instructed not to build anything into this new build-root, though they may freely continue pushing upgrades to Rawhide in parallel. In other ecosystem news, a rebuild for MySQL 9.7 was initiated for perl-DBD-MySQL, and perl-Coro-Multicore was manually patched to resolve an atfork_child naming collision with Perl 5.43.2+. Several routine version bumps were also merged for packages like perl-HTTP-Message and perl-ExtUtils-MakeMaker-CPANfile.

Decisions

  • A pull request to build perl-HTTP-Daemon with Module::Build on RHEL was rejected and closed. Maintainers decided against carrying custom, untested patches in the repository, opting instead to strictly follow upstream development.

Learn more about the Perl team.

Python

Due to an incompatible ABI change in the Python 3.15.0b4 release, the team initiated a targeted rebuild of approximately 750 Python packages with extension modules in Rawhide. The rebuild took place in a dedicated side tag and experienced some delays due to slow s390x builders, culminating in a massive Bodhi update. The rebuild was officially completed on July 25, and normal Rawhide package builds have now resumed.

Maintainers of the roughly 30 packages that failed to rebuild during this process are asked to investigate and fix their builds in the side tag. The remaining failing packages are being tracked in a dedicated Bugzilla ticket (PYTHON3.15b4), presenting a clear opportunity for contributors to help get the remaining packages updated for the new Python 3.15 ABI.

Decisions

  • Contributors were instructed to temporarily halt building Python packages with extension modules in Rawhide to avoid disrupting the side-tag rebuild and testing process.
  • As of July 25, the side tag was successfully merged, and the temporary freeze on Rawhide builds for these packages was lifted.

Learn more about the Python team.

Other Discussions

Orphaning packages

Package updates

New contributor introductions

GUADEC 2026 Trip Report

Posted by Felipe Borges on 2026-07-27 09:39:04 UTC
GUADEC 2026 Group photo
GUADEC 2026 Group Photo (by Jakub Steiner)

Last week I attended GUADEC in A Coruña, Spain. While I attend the conference every year, this one was extra special because 14 years ago we held the conference at the same location, and it was my first GUADEC ever. Great memories!

Back in 2012, I was an intern in the Google Summer of Code program, traveling abroad for the first time. Now I feel privileged to have spent all the years since then working on the GNOME project as a professional developer. It turned out to be everything (and more) that my younger self had dreamed of.

Now, living in the Czech Republic, my travel this time was quite smooth compared to my first trip to A Coruña. Vienna  -> Madrid -> A Coruña. I managed to leave early in the morning and arrive at the accommodation just in time for the conference’s pre-registration party. Other than the nostalgia of being back in the same Rialta cafeteria, I was super happy to meet some of my long time GNOME friends.

While I stuck to all the talks in the first room, I have now caught up with the room 2 talks via the YouTube recordings. The conference was packed with great desktop content, as always.

On day 1, I would highlight Jakub’s “Symbolic Achievements” regarding the future of our UI icons and Matthias’ recent SVG work. The icon animation work opens up a universe of possibilities for building more polished UIs. At the end of day 1, I went on stage for the “Community Update” session, where I represented the GNOME Settings and the Internship Committee teams.

On day 2, Emmanuele Bassi continued his effort to establish more governance in our project. This inspired me (representing GNOME Settings) and some of the GNOME Shell team to sit down and discuss putting together a Core-Components/System Team. This way, we can collaborate and support each other more effectively across components. As we progress on vertically integrating our desktop experience, our projects become more and more entangled. This requires more and more collaboration and shared responsibilities. We will probably announce this team soon.

Continuing on day 2, Joan presented his progress on passwordless authentication in GDM and Carlos presented an interesting initiative for using Mutter as an application test framework. This could complement other testing methods (such as OpenQA) and help us move away from heavily using the accessibility API for some of our current dogtail-type of UI tests. Additionally, Adrian presented his challenges and ideas for session Save/Restore. This work looks promising and is highly desired by the general audience. This has already been reported on by LWN.

At the end of day 2 I had the chance to present “The Future of Boxes”. A demo of the work I have been doing on the side for the past couple of years to refactor and rewrite Boxes to use a new display widget (libmks), GTK4/libadwaita, and to be a Flatpak-first app. I have a blog post version of this talk coming out in a few days. I’m super excited about the progress I made on this project and how close I feel we are to making it useful for a general audience, just as the “old” Boxes served plenty of users and their workflows.

To wrap up day 2, I hosted our traditional “Intern Lightning Talks” session, where we highlighted the work of our Google Summer of Code interns this season. Two interns managed to attend GUADEC in person, while the other four sent pre-recorded presentations.

Day 3, Saturday, started with a morning-long AGM (the Foundation’s Annual General Meeting). The new format was much more engaging than the ones before. I also would like to praise Allan for doing an excellent job explaining the GNOME Foundation’s processes, finances, and initiatives. After lunch, we watched the traditional “State of the Shell” update from Carlos, Florian, Jonas and Michel. I was also happy to watch Andrea Veri’s update on the state of GNOME Infrastructure, and to learn that our project’s infra is in very good hands during these difficult times.

The local GUADEC organizers put together a lovely dinner experience for everyone. Besides the delicious food and drinks, I spent the night catching up with multiple GNOME friends. This was the same location where we held one of our social events back in 2012. The night sky view of the sea, the fresh air, and the memories were great.

With the three talk days finished, we spent two more days of BoFs/Hackfests. Sunday morning started with my “GNOME Settings BoF”. The session was attended by some well known contributors and also by a few newcomers interested in getting involved or getting answers about the future of our settings. We discussed various topics ranging from the maintenance of some subsystems, AI policy ideas, documentation, and plans for GNOME 51 and 52. I demoed some of my own work-in-progress branches and highlighted what others are working on. I was glad that we received some positive feedback on our recent changes and contributors committed to help review and test some of the work.

At the end of Sunday, I hosted a “GNOME Internship Committee Meetup,” where current and former interns joined Aryan, Maria, and me to discuss how we can improve our internship experience in GNOME. Topics ranged from onboarding and community bonding activities to feedback, etc…

On Sunday evening I went to the Plaza de Maria Pita, the main square in town, to watch the World Cup final between Spain and Argentina. As a football fan, I felt privileged to celebrate this game in the home country of the winning team.

On Monday morning I attended the Design Team BoF, where we discussed various topics, from a transparent topbar in the Shell, to action buttons on dialogs. I started prototyping changes to action dialog buttons for some GNOME Settings dialogs so that the team has something tangible to experiment with. At the end of Monday, my farewell from the conference was participating in the “Engagement Team” BoF. I was happy to see the team getting back in shape again, and how enthusiastic they are. Since I work on Planet GNOME and a couple of other websites, I was happy to help them discuss and develop some ideas for promoting more of our development work through engagement channels (social media accounts, blogs, news reporting, etc…).

On Tuesday, July 21, I flew back home through Barcelona and then Vienna (which is a couple of hours drive from where I live in the Czech countryside).

All in all, I would like to thank the GUADEC organizers for another unforgettable conference, the GNOME community for always raising the bar on the conference’s content, and Red Hat for funding my trip and accommodation in Spain.

I am looking forward to seeing you all next year!

misc fedora bits: 4th week of july 2026

Posted by Kevin Fenzi on 2026-07-26 15:55:10 UTC
Scrye into the crystal ball

Another busy week, another saturday... oh wait, a bit of a delay there. Read on for why.

Fedora 45 mass rebuild over

The lass rebuild last week finished last sunday, and was merged in on monday. Overall it was pretty uneventfull from my perspective. No builders dropped out or had any problems, the upgrade on my rawhide laptop went fine and nothing really broke, some other folks stepped up and fixed some reporting problems and all the bugs for failing to build from source got filed.

There were 2 other smaller mass rebuilds that also landed this week:

  • python had to rebuild a bunch of packages due to a last minute bug This resulted in a bodhi update with 700+ packages in it, which was caused a few loading and bw issues, but worked pretty well in the end.

  • perl had their mass rebuild that was done and merged in. No particular issues from it.

batcave migration

Our ansible control host/general admin server got moved to rhel10 this week. Took a fair bit of tweaking. I installed a new batcave02, got it all setup and data synced to it and then on thursday swapped it in. Overall I think it went smoothly, and now we have a newer ansible version along with most everything else.

DMARC mitigation patch deployed

This has been a long standing annoyance for some folks, but I finally carved out some time to backport a patch and test and deploy things so that we now (at least on devel, users, devel-announce) are always doing DMARC mitigation for redhat.com email addresses.

The problem was that externally, redhat.com uses DMARC to indicate valid senders of the domain, but internally to us, they do not. So, our mailman instance doesn't think their posts need anything and sends them out as normal. That results in some users who have providers that check and reject on that reject those posts.

The patch adds a new admin field to set regex for domains that should alway be mitigated (that is the email shows as coming from the list itself instead of the sender email).

https://forge.fedoraproject.org/infra/tickets/issues/12487 has the nitty gritty

IPA reinstalls/move to RHEL10

So, now we come to why my saturday was so busy sadly. We are moving our ipa clusters to rhel10. This worked very normally in staging and there were not any problems.

Production has prooved different. However late this week Michal, who had been doing the migration got 2 out of the 3 cluster members moved to rhel10. The last one was ipa01, and it wasn't syncing right. No problem right? We have 2 more servers?

Well, it turns out that ipa01 is 'special' in a lot of places. We had places where ansible just used the first server, where a list of servers was given, but 01 was always tried first, etc.

This resulted in a bunch of instability in various things and was a big pain to track down and fix up.

So, I poked at this friday some (and then a lot more saturday) and got everything using 02/03. As part of that though, I noticed what might be the core problem that we were having getting them moved: we had them using 8GB of ram each, and that was just not enough. I doubled all of them to 16GB and hopefully that makes syncing 01 work as expected on monday.

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

Modernisation du tooling dev sur SeedboxSync : Just, pnpm, uv & Ruff

Posted by Guillaume Kulakowski on 2026-07-26 12:35:15 UTC
SeedboxSync fait peau neuve côté tooling ! Retour sur la modernisation de mon environnement de dev : abandon du bon vieux Makefile au profit de Just, transition vers pnpm pour un gain de temps spectaculaire côté frontend, et adoption de uv et Ruff pour booster l'écosystème Python. Moins de friction, plus de vitesse : découvrez le détail de cette mise à jour.

accounts.fedoraproject.org degraded

Posted by Fedora Infrastructure Status on 2026-07-24 22:00:00 UTC

Due to an ongoing upgrade of our IPA cluster, users may not be able to login to the accounts.fedoraproject.org interface. Already authenticated users may whiteness problems like not being able to see people in groups and search not functioning correctly.

Authentication to apps using id.fedoraproject.org and …

End of Community update

Posted by Fedora Community Blog on 2026-07-24 12:00:00 UTC

Last few years a small team of people in the CLE Team were working each week to prepare a Community update for you. First one published on October 21st 2021. We were starting with only Infrastructure and Release Engineering teams (+ initiatives we did in CPE Team at the time), but later added more teams to our weekly reports to bring people a better picture what is being worked on. We thank to everyone who read our updates and found some value in them.

But as life is going forward even this updates are evolving. Last few weeks @abompard worked together with us to improve his weekly report to include the sources we are using for this weekly reports. So I introduce to you This Week in Fedora as a replacement for Community weekly updates. I’m glad that this initiative I started few years ago was able to live for that long and hopefully helped a few people to find information they were looking for.

I would like to thank people who helped me working on Community weekly updates:

  • @lenkaseg
  • @jnsamyak
  • @c4rt0
  • @jskladan
  • @t0xic0der
  • @siddharthvipul1
  • @patrikp

The post End of Community update appeared first on Fedora Community Blog.

The Fedora 45 Sausage Factory

Posted by Simon de Vlieger on 2026-07-24 06:00:00 UTC
The Fedora 45 Sausage Factory This is a walkthrough of how Fedora turns source code and packages into the artifacts you download and install. It follows the a package from a packager’s git push to a composed release: ISOs, cloud images, container images, and OSTree deployments. The walkthrough describes how the Fedora ‘sausage’ is created as of Fedora 45, things change all the time; I hope to have time to update this document every cycle or every few cycles of Fedora releases so there’s both history and people can find up to date information.

Friday Links 26-23

Posted by Christof Damian on 2026-07-23 22:00:00 UTC
A skateboarder popping a trick off a stone ledge at Plaça de Catalunya in Barcelona while a filmer crouches to capture it

I have been on vacations, which means today is a bit longer than usual. AI stuff is taking over, so there is a new section. I’ll keep it balanced, as I bounce between loving and hating it.

If you are looking for something good, check out the videos about Spike Jonze’s skate video and about Belle and locations.

How AI Is Changing Open Source

Posted by Jiri Eischmann on 2026-07-23 15:13:26 UTC

AI entered software development at full speed this year, and it is significantly impacting open-source projects as well. In this article, I discuss several trends I have recently observed in open source in connection with AI, and how these trends are changing the world of open-source software.

This article was originally published on my Czech blog, but it received such an overhelming response that I decided to translate it into English and publish it here as well.

Project Inflation

One of the trends that AI brings in general is an explosion of content. Search results are filled with generated websites, and social networks are inundated with generated images and videos. Source code is no exception. Today, GitHub is drowning in an ever-increasing number of repositories.

However, it is not as if a larger number of high-quality projects are being created. On the contrary, these are projects where you have no idea whether you can rely on them or not. In the past, if you stumbled upon a more extensive project with thousands of lines of code, there was a certain assumption that if someone went to the trouble of creating something like that, they would have some knowledge of the problem, a personal connection to their creation, and some willingness to maintain it going forward.

You can no longer rely on this at all. Today, you can generate a project with several thousand lines of code in a matter of moments. It could be complete nonsense or even something dangerous; it could be something functional that someone generated for their own immediate needs and posted to GitHub, but with no interest in turning it into an open-source project. Because a repository with code doesn’t make an open-source project. The difference between a piece of code on GitHub and an open-source project is that an open-source project solves problems and use cases for its users, not just the author’s one-off need. And most authors of such quick-and-dirty code simply aren’t interested in doing that.

This is clearly visible in projects like MeshCore, for instance. There are dozens of forks of everything imaginable. Missing a feature in the official MeshCore firmware? You just fork it, vibe-code the missing piece, and dump it on GitHub as MeshCore-UltimateEdition. The problem is that it was created with minimal effort, the author usually has no relationship to it, gets bored after a month, and it becomes abandonware before it even has a chance to age.

About ten years ago, people started saying that the concept of Linux repositories had run its course. In the 2000s, they were practically the only source of Linux software. If a project didn’t make it into distribution repositories, it had a problem. But then the number of open-source projects grew at such a rate that distributions couldn’t keep up. Users had to start getting their software elsewhere, and software authors learned to do without distributions. Just a few years ago, the “everything I need, I find in Debian” approach seemed definitively dead.

However, it is possible that curated software sources – like Linux distribution repositories – will make a comeback. The open-source software world is becoming so chaotic that users will once again start appreciating sources containing curated software that someone has vetted for them and that they can rely on six months down the road.

Review Overwhelm

Another trend that AI has triggered in open source is ‘review overwhelm’. Previously, writing code acted as a natural filter because it required a non-trivial amount of effort and time investment. That is now gone, making code creation fast and easy. But someone still has to review this code before it goes into serious production. The review processes that worked in open-source projects for years are now at their capacity limits.

In GNOME 50, support for Google Drive was removed because nobody had been maintaining it for a long time. Users were naturally unhappy about it, and eventually, one user stepped up, re-added the support, and submitted it upstream to the gvfs project.

A colleague responsible for maintaining that project lamented that it was a change involving 4,000 lines of code. Even though it seems to work at a basic level, it was clearly generated using AI. He will still have to go through it line by line to verify that it actually works as intended and meets the code quality standards required to commit to maintaining it long-term.

Most of the effort has thus shifted from code creation to code review, which is typical for AI. The problem in open source, however, is that developers experienced enough to review and merge code were already a bottleneck before AI. Now, the problem has deepened significantly. And in the example above, my colleague can count himself lucky that the contributor is responsive and has shown long-term interest in the issue.

Today, that is more of a rare exception. Common contributions consist of someone wildly vibe-coding something without any deeper interest or understanding of the subject, and throwing it over the wall to the maintainers.

I have a fairly recent experience with this in Meshy. Someone submitted a pull request with 9,000 lines of changed code, which was supposed to add support for macOS. I spent an hour one evening doing a very quick review, and even during that short time, I ran into numerous issues: the code was blatantly AI-generated, several thousand lines were just completely useless replacements of single quotes with double quotes, parts of the code unrelated to the problem were modified, and it overwrote all the changes I had made in the main branch over the last few weeks.

The author never responded to my comments and I never heard from him again. My takeaway was that even that one hour was too big of a time investment for contributions like that, and next time I will reject them much faster.

Some projects are responding to this situation by tightening basic contribution requirements. For example, Flathub’s decision to reject AI-generated apps caused quite a stir. Many people criticized it as shooting themselves in the foot, but you have to look at their reality.

Flathub currently hosts several thousand apps, with more added every day. Only three people handle the reviews. Although their review process is highly automated, they do it very thoroughly, and a lot of manual input is still required. It’s clear their goal isn’t just to spot the worst slop, but to maintain a relatively high standard of code hygiene. In the last six months, I submitted two apps to Flathub, and the review process ultimately contributed to improving the quality of the apps themselves.

However, this has now clashed with the reality of people submitting completely vibe-coded apps without a shred of personal effort. The ticket template for requesting inclusion asks a few questions, including a requirement to upload a short video showing how the app works. It really isn’t demanding, and anyone can put it together in 15 minutes. Yet even that is too much effort for creators of AI slop.

Instead of fulfilling these minimal requirements, some labeled it an attack on Linux’s freedom and immediately vibe-coded an alternative to Flathub that was supposed to be open to everyone. Unsurprisingly, it barely lasted a month.

Not only do open-source maintainers lack the capacity to satisfy this demand for code review, but they are also losing the motivation to do it. Often, it would be faster for them to write the feature themselves, but the review process was historically how they cultivated new long-term contributors and potential successors. When someone sends you a vibe-coded contribution that cost them zero effort and which they likely don’t even understand, how do you expect to mentor them into a contributor who will help the project in the long run?

Open-source software was never just about the end result; it was also about the process – where contributors build a relationship with the project and grow into someone who will eventually pass that on to others. This stands in sharp contrast to the world of AI, where it’s all about the result. As fast as possible, with as little effort as possible.

Declining Motivation to Publish Code

In the 1990s, Francis Fukuyama declared democracy and liberal economics to be the ultimate victors in the arrangement of the world order. Today, as democracy erodes globally and the existing economic order crumbles, that looks like a prematurely bold statement to say the least. Similarly, just a few years ago, impressed by the developments of the last few decades, some hailed open source as the ultimate winner among software development models. Are we about to face a sobering reality check similar to Fukuyama’s thesis?

Lately, I’ve been observing a subtle, yet present trend of stepping back from open-source development. One argument against open development I hear concerns the aforementioned review overload. For some projects, the costs associated with being overwhelmed by AI slop can outweigh the benefits of useful community contributions. They might still publish the source code for transparency’s sake, but they transform from an open-development project into an open-source, closed-development project. And those who don’t care as much about transparency may close off the source code entirely.

Another argument against making source code public is the fear of license circumvention. Today’s LLMs train on source code regardless of its license and can then easily generate a similar solution that you can publish under whatever license you choose.

This isn’t an issue for permissive licenses, as the author has already accepted that anyone can do practically whatever they want with the code. However, AI poses a direct threat to copyleft licenses like the GNU GPL. Authors usually choose these to ensure their work remains open forever and that anyone who uses it shares their improvements back with the community. If an LLM trains on a project you’ve worked on for years and then generates a very similar solution published under a proprietary license, it effectively bypasses this principle.

Take MeshCore again as an example: the protocol itself and the firmware are open-source, but the clients are closed. Recently, it came to light in the community that a core team member secretly applied for the MeshCore trademark and started vibe-coding his own closed-source solutions based on the available code. MeshCore founder Scott Powell cited this as something that reaffirmed his decision to keep the client source code private. Specifically, he wrote:

So, I see open source, in the age of AI, as offering up your blood, sweat and tears for others to rip-off, but in innumerable ways.

We may disagree with Powell’s perspective, but it represents a legitimate stance that I see more and more often around me. I see lifelong open-source advocates – people who used to publish every last helper script because they wanted to share – who now keep those things to themselves, offering them to others only upon request. They have reasons similar to Powell’s.

Open source also grew out of the need to share. Writing code was hard; maintaining it was even harder. Why should everyone implement the same thing independently? Let’s join forces in an open-source project, write a shared library, and everyone can benefit from the results. The infrastructure powering the Internet today was built on this foundation. But AI is suppressing this need.

For instance, I encounter opinions that WordPress is dead because “I can just easily generate my own CMS.” In my view, that severely underestimates what an open-source project actually provides. It is so much more than just writing code, and this strategy of swapping a dependency on an open-source project for a dependency on an LLM might not pay off in the long run.

Nevertheless, the reliance on shared open-source components has indeed decreased to some extent. AI might not replace everything, but why depend on a large external library when you don’t even need 10% of its functionality, if AI can quickly rip off that 10% for you after learning from the original library? And once you have your own implementation, why would you contribute improvements back to a shared open-source project?

The final argument against publishing source code that I’ve been hearing lately is security. Granted, I’ve heard this argument throughout the two decades I’ve been involved in open source, but it has never been this loud. For years, critics have claimed that open source is insecure because it allows attackers to study the code and hunt for vulnerabilities. In response, open-source advocates argue that security through obscurity is not real security and that open-source software is safer because “given enough eyeballs, all bugs are shallow.”

Today, however, open-source projects are literally flooded with security vulnerability reports generated by AI. The volume is so unprecedented that it is genuinely easy to fall into the trap of believing closed code is safer. It’s interesting to note that while news headlines cover how many bugs AI has found, they rarely mention how many security bugs AI has fixed. Fixing them still requires a deep understanding of the codebase and is still done by human programmers. And just like reviewing pull requests, it is overwhelming their capacity.

In this case, though, I believe it’s just a temporary trend. Open-source projects will eventually wade through these security reports, the general security of maintained open-source software will improve, and the ecosystem will benefit in the end. As for the other trends mentioned in this article, it’s hard to say. I’m not quite as unconditionally optimistic there.

On Planet GNOME and personal opinions

Posted by Felipe Borges on 2026-07-23 07:01:18 UTC

Putting on my Planet GNOME editor hat for a quick PSA!

Planet GNOME is a convenient aggregator for personal blogs by members of our community. While all content must follow our Code of Conduct, the views expressed in these posts are solely those of the individual authors.

They don’t represent or reflect the opinions of the GNOME Project as an entity or community.

To help highlight this, we’ve added a “Voices of the community” tagline to the website header. It links directly to our “Add feed” section, which also emphasizes that Planet collects the latest posts from personal blogs.

Enjoy the personal insights and variety of perspectives!

How to close issues

Posted by Ben Cotton on 2026-07-22 12:00:00 UTC

If you want to start a fight, bring up the topic of closing unresolved issues. People have strong opinions on this topic, and for good reason. To maintainers, open issues can be overwhelming. They represent a backlog of work that will never get done. To users, issues represent a real pain point. If bug reports reports are contributions — and they are — then opening an issue is often the first (or only) contribution a particular person will make to the project. A bad bug reporting experience is a bad contributor experience, and it may chase someone away for good.

Just about everyone would agree that there are some cases where closing an unfixed issue makes sense. Not everyone will agree on where to draw the line, though. In general, the best approach is to have a clear, well-communicated policy and to close issues with respect for the time that people put into filing them. The rest of this post has my suggestions for how to approach closing issues. You, of course, can set whatever policy you want for your project.

Types of issues and how to close them

  • Spam. Close these immediately, no comment necessary. If your issue tracker supports hiding or removing issues, make these go away. They add no value except as something you might want to track.
  • Duplicate. close these immediately. If your issue tracker supports linking it to the original issue, do that. Otherwise, comment with a link to the original issue.
  • Invalid reports
    • Upstream bug. Leave these open with a link to the upstream bug report until a fix reaches your project. Some projects will ask the reporter to file upstream bugs themselves, but I prefer to do it myself so that I can provide project context the user might not know and because I’ll want to be informed when it’s fixed anyway.
    • Downstream bug. This is rarer than the upstream bug case, but it happens somewhat frequently in the case of distro-packaged software. In this case, directing the reporter to the downstream issue tracker in a closure message is sufficient.
    • Unsupported version. If your project has a defined support policy, you can close reports filed against an unsupported version. You can choose to close these immediately with a reference to the supported versions, but it’s friendlier to leave it open to give the reporter a chance to test a supported version.
    • Not a bug. If the issue describes intended behavior, you can close it immediately. Consider whether or not this is actually a bug in your documentation.
  • Out of scope. This generally applies to feature requests more than bugs. If someone asks for something that’s not what you intend for the project, close the issue.
  • Not reproducible. If neither you nor the reporter can reproduce an issue, close it. In this case, I recommend leaving it open for a period of time (say 30 days or so) in order to give other people a chance to find a reproduction case.
  • Unresponsive reporter. If you lack the information necessary to address an issue and the reporter doesn’t reply to your questions, you can close the issue. As with the “not reproducible” case, you should give people a reasonable amount of time to answer. 30 days is a good starting point. Ideally, people would answer within a day or two, but they have lives just like you do.
  • Stale. This is a distinct category from “unresponsive reporter” and the one most likely to make people upset. If there’s a valid report with sufficient information but no one has touched it, leave it open. Autoclosing these is not only user-hostile, but it encourages noisy behavior when people leave a comment just to keep the issue open.

Not included in the list above are resolved issues: fixed bugs and implemented feature requests. There’s no question that these should be closed. The only question is “when?” I’m partial to closing these when the fix or feature is in a shipped release. The tooling doesn’t always make that easy. Fedora has some automated connections between its update system and Bugzilla that will move reports through automatically. GitHub-hosted projects tend to close issues when a commit or pull request that says “fixes ” lands in the primary branch. There are ways to queue closures for when a corresponding release lands, but it tends to be more effort than most maintainers are willing to set up (myself included).

This post’s featured photo by Neringa Hünnefeld on Unsplash.

The post How to close issues appeared first on Duck Alignment Academy.

Syslog-ng journald source: how to avoid log bombs on errors?

Posted by Peter Czanik on 2026-07-22 11:56:05 UTC

Choose your poison: Up until version 4.12, when syslog-ng ran into an error jumping to a saved systemd journal position, it read the journal from the beginning. With the latest syslog-ng version, you can configure what happens in case of such an error.

Read more at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-journald-source-how-to-avoid-log-bombs-on-errors

syslog-ng logo

Compilaciones ultra rápidas con MicroVMs y libvirt

Posted by Rénich Bon Ćirić on 2026-07-22 11:00:00 UTC

Hoy me puse a experimentar con la arquitectura de MicroVMs en QEMU y libvirt, y la neta me quedé impresionado.

Si tú me has seguido por acá, sabes que en varios escenarios de migración desde entornos legacy (como VMware) a clusters hiperconvergentes de 3 nodos con libvirt y Ceph, el reto clásico siempre ha sido la eficiencia: las máquinas virtuales tradicionales tardan entre 30 y 90 segundos en arrancar y tragan gigabytes de RAM nomás para estar paradas.

Hoy te voy a enseñar cómo armé un motor de compilación efímero que arranca una máquina virtual aislada por hardware en menos de 200 milisegundos, compila tu código o empaqueta un RPM, guarda los artefactos y se destruye sin dejar rastro.

El problema con los entornos de compilación tradicionales

Normalmente, cuando un desarrollador quiere compilar algo con dependencias nativas (por ejemplo, una aplicación en Crystal con bindings a libssh como mi proyecto shellmin), se topa con dos caminos incómodos:

  1. Mantener servidores de compilación o VMs de CI/CD de larga vida que terminan acumulando residuos y consumiendo recursos innecesarios.
  2. Pedir acceso directo por SSH o root al hypervisor, lo cual desde el punto de vista de seguridad de una organización está completamente fuera de discusión.

Note

La idea aquí es ofrecer un servicio de MicroVM Build-as-a-Service. El desarrollador no necesita acceso shell al servidor ni cuentas en el hypervisor; nomás empuja su código o dispara un webhook y la infraestructura hace todo de volada.

Pensando en términos de Linux: Los archivos repos y build_deps

Para mantener las cosas simples y alineadas a la filosofía de Linux, en lugar de obligar al desarrollador a escribir scripts de inicialización complejos o configurar XMLs mamones, la máquina virtual lee los archivos planos repos y build_deps en la raíz de su repositorio.

En proyectos del mundo real, no basta con declarar únicamente los paquetes en build_deps; muchas veces requerimos habilitar fuentes externas (como repositorios COPR o repositorios de terceros como MariaDB o RabbitMQ) en el archivo repos. Por ejemplo, para compilar nuestra aplicación en Crystal con bindings a libssh (shellmin), necesitamos habilitar el repositorio COPR de zawertun/crystal antes de que el manejador de paquetes pueda instalar crystal.

En el archivo repos declaramos las fuentes externas:

# repos
zawertun/crystal

Y en el archivo build_deps declaramos los paquetes requeridos:

# build_deps
crystal
shards
libssh-devel
gc-devel
pcre2-devel
openssl-devel
gcc
make

¿Y cómo regresan los artefactos compilados al host? En lugar de andar extrayendo archivos a mano con herramientas de disco o SSH, la MicroVM utiliza un montaje de directorio compartido por hardware mediante VirtioFS (o 9p). El orquestador monta la carpeta del trabajo en el guest en /etc/build_workspace. Cuando el proceso de compilación genera los binarios o paquetes RPM, los escribe directamente en la carpeta compartida artifacts/, por lo que el host recibe los artefactos terminados de inmediato en su disco local.

Desacoplando la arquitectura: Archivos independientes

Para que la automatización sea totalmente explícita y transparente, desacoplé la configuración en archivos independientes. Nada de andar metiendo bloques culeros dentro del script principal; todo se lee directamente del disco.

Aquí te muestro los componentes principales que utilicé:

El XML de la MicroVM (microvm_build.xml):
Un template XML declarativo que usa la máquina virtual ligera microvm de QEMU con arranque directo de kernel (vmlinuz), consolas serie y montaje compartido VirtioFS.
<!-- microvm_build.xml -->
<domain type='kvm'>
  <name>microvm-shellmin-builder</name>
  <memory unit='MiB'>128</memory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='microvm'>hvm</type>
    <kernel>/boot/vmlinuz-current</kernel>
    <initrd>/var/tmp/microvm-initrd.img</initrd>
    <cmdline>console=ttyS0 quiet reboot=k panic=1 pci=off</cmdline>
  </os>
  <features>
    <acpi/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <filesystem type='mount' accessmode='passthrough'>
      <driver type='virtiofs'/>
      <source dir='/var/tmp/build_workspace'/>
      <target dir='build_workspace'/>
    </filesystem>
  </devices>
</domain>
El Init del Guest (microvm_init.sh):
Un script transparente que se ejecuta como PID 1 dentro de la MicroVM, monta los sistemas de archivos virtuales (/proc, /sys, /dev), el workspace compartido VirtioFS, instala dependencias de build_deps/repos, compila la aplicación y apaga la VM de inmediato.
#!/bin/sh

# microvm_init.sh
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs none /dev

# Montar espacio de trabajo compartido VirtioFS desde el host
mkdir -p /etc/build_workspace
mount -t virtiofs build_workspace /etc/build_workspace

printf "\n[GUEST INIT] MicroVM kernel booted successfully!\n"

# 1. Procesar fuentes externas de repositorios (repos)
if [ -f /etc/build_workspace/repos ]; then
    printf "[GUEST INIT] Procesando repositorios externos...\n"
    while IFS= read -r line || [ -n "$line" ]; do
        case "$line" in
            \#*|"") continue ;;
            https://*|http://*)
                printf "[GUEST INIT] Descargando repo: %s\n" "$line"
                curl -sSL -o "/etc/yum.repos.d/$(basename "$line").repo" "$line"
                ;;
            *)
                printf "[GUEST INIT] Habilitando COPR: %s\n" "$line"
                dnf -y copr enable "$line" &> /dev/null || true
                ;;
        esac
    done < /etc/build_workspace/repos
fi

# 2. Procesar paquetes de dependencias de compilación (build_deps)
if [ -f /etc/build_workspace/build_deps ]; then
    printf "[GUEST INIT] Instalando dependencias de compilación...\n"
    deps="$(grep -v '^#' /etc/build_workspace/build_deps | tr '\n' ' ')"
    if [ -n "$deps" ]; then
        dnf -y install $deps &> /dev/null || true
    fi
fi

# 3. Ejecutar la compilación del proyecto (shellmin)
if [ -d /etc/build_workspace/shellmin ]; then
    printf "[GUEST INIT] Compilando aplicación Crystal (shellmin)...\n"
    cd /etc/build_workspace/shellmin
    shards build --release --without-development
    cp bin/shellmin /etc/build_workspace/artifacts/
fi

poweroff -f
El script orquestador (run_microvm_build.bash):
El script en Bash que coordina todo el jale en el host: prepara el espacio de trabajo con los fuentes y manifiestos, genera la definición de libvirt y ejecuta la MicroVM siguiendo los estándares de EVALinux.
#!/usr/bin/bash

# run_microvm_build.bash
set -euo pipefail
IFS=$'\n\t'

readonly ScriptDir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly DomainName="microvm-shellmin-builder"
readonly Timestamp="$(date +%Y%m%d-%H%M%S)"
readonly JobId="job-${Timestamp}-$((1000 + RANDOM % 9000))"
readonly JobResultsDir="${ScriptDir}/results/${DomainName}/${JobId}"
readonly ArtifactsDir="${JobResultsDir}/artifacts"
readonly LogsDir="${JobResultsDir}/logs"

readonly TmpDir="$(mktemp -d --tmpdir=/var/tmp microvm-shellmin-poc.XXXXXX)"
chmod 755 "$TmpDir"

cleanup() {
    local exit_code=$?
    printf "[CLEANUP] Limpiando dominio %s y directorio %s...\n" "$DomainName" "$TmpDir" >&2
    virsh -c qemu:///system destroy "$DomainName" &> /dev/null || true
    virsh -c qemu:///system undefine "$DomainName" &> /dev/null || true
    rm -rf "$TmpDir"
    exit "$exit_code"
}
trap cleanup EXIT

prepare_workspace() {
    local -r workspace="$TmpDir/build_workspace"
    mkdir -p "$workspace/artifacts" "$ArtifactsDir" "$LogsDir"

    # Copiar manifiestos repos y build_deps
    cp "${ScriptDir}/repos" "$workspace/repos"
    cp "${ScriptDir}/build_deps" "$workspace/build_deps"

    # Clonar código fuente a compilar
    git clone --depth=1 https://gitlab.com/renich/shellmin.git "$workspace/shellmin" &> /dev/null
}

run_microvm_build() {
    local -r runtime_xml="$TmpDir/runtime_domain.xml"
    local -r exec_log="$LogsDir/build.log"

    virsh -c qemu:///system define "$runtime_xml" &> /dev/null
    virsh -c qemu:///system start "$DomainName" &>> "$exec_log" || true
}

Note

¿Por qué usar /var/tmp en lugar de /tmp? En sistemas Linux modernos (como Fedora y RHEL), /tmp está montado en memoria RAM usando tmpfs. Si guardas árboles de código o artefactos grandes ahí, saturas la memoria del servidor de volada y no va a escalar. Por eso usamos /var/tmp, el cual está respaldado por almacenamiento en disco.

Resultados con espacios de nombres (Namespacing) para evitar sobreescrituras

Un error común en motores de compilación sencillos es volcar todos los logs y binarios en una carpeta plana como results/. Al hacer esto, compilaciones subsecuentes terminan sobreescribiendo los logs y los binarios producidos.

Para solucionar esto de raíz, cada trabajo de compilación genera un directorio único con espacio de nombres (Namespacing) basado en el proyecto y el ID del trabajo (timestamp o UUID):

results/
└── microvm-shellmin-builder/
    └── job-20260722-060942-2579/
        ├── artifacts/
        │   └── shellmin
        └── logs/
            ├── build.log
            └── microvm.log

De esta manera, cada compilación mantiene un historial 100% aislable, auditable e inmutable, sin riesgo de sobreescribir artefactos o logs anteriores. Gracias al montaje de directorio compartido por VirtioFS, la subcarpeta artifacts/ recibe los binarios compilados en el host en tiempo real antes de que la VM efímera se autodestruya.

Abstrayendo la complejidad: ¿Cómo simplificar este PoC a futuro?

Seamos honestos: en el estado actual de este PoC, mantener scripts de inicialización en shell artesanales (como microvm_init.sh) con montajes manuales de /proc o scripts orquestadores en el host (como run_microvm_build.bash) resulta verboso, intimidante y propenso a errores tanto para desarrolladores como para sysadmins.

Para llevar este patrón de diseño a producción y evitar que el equipo tenga que lidiar con la fontanería interna de KVM/libvirt, la arquitectura se simplifica y abstrae mediante estas cuatro mejoras:

Un ejecutable CLI abstraído (microvm-build):
En lugar de mantener scripts de Bash de 150 líneas en el host, la orquestación se empaqueta en una herramienta CLI o daemon escrito en Crystal o Go. El desarrollador o el pipeline de CI/CD simplemente ejecuta microvm-build --src . --output ./results sin tocar XMLs de libvirt ni interactuar con la consola serie.
Aprovisionamiento inmutable:
En lugar de escribir scripts /init a mano con comandos mount y parsing en shell, se utilizan motores de aprovisionamiento declarativos estandarizados (como Fedora CoreOS Ignition o unidades simples de systemd dentro del sistema base) para preparar el entorno de compilación de forma determinista.
Especificaciones declarativas en YAML o TOML:
En lugar de requerir que el usuario conozca la mecánica interna de la VM, se abstraen las fuentes y dependencias en un manifiesto limpio en YAML (o imágenes de construcción tipo OCI), dejando que el motor construya dinámicamente los recursos.
Cumplimiento FHS y aislamiento de resultados:

Internamente, el proceso se alinea al estándar FHS (Filesystem Hierarchy Standard) para mantener una estructura organizada:

Espacio de trabajo:
/usr/src/<proyecto>/
Caché del manejador de paquetes:
/var/cache/builder/
Logs de inicialización:
/var/log/builder/
Temporales efímeros:
/var/tmp/ (respaldados por disco)

Conclusión

A final de cuentas, las MicroVMs con libvirt y QEMU nos permiten tener lo mejor de dos mundos: la seguridad total de aislamiento por hardware (KVM) que solías tener en VMware, combinada con la velocidad de arranque en milisegundos (< 200 ms) que esperas de un contenedor.

Si tú estás buscando modernizar tu infraestructura sin regalarle privilegios a nadie ni saturar tus servidores con VMs pesadas, este patrón de diseño te va a hacer un paro chingón.

¿Qué te parece? ¿Te gustaría implementar algo así en tu infraestructura? ¡Platícamelo en los comentarios!

Some Changes to GNOME Security Tracking

Posted by Michael Catanzaro on 2026-07-20 13:20:06 UTC

Due to the increase in AI-generated security vulnerability reports, it is time for some changes in how GNOME manages vulnerability reports.

These policy changes intentionally do not distinguish between reports that contain AI-generated content and those that do not. Following the same rules for all vulnerability reports is simpler than having two different ways of doing things. Reporters rarely disclose AI use, and it’s nice to not have to guess whether the issue report is AI-generated or not; it’s normally obvious, but not always. Also, vulnerability reports that are not discovered by AI are becoming increasingly rare. Non-AI reports are now moderately unusual, so it really doesn’t make sense to optimize for them.

Reduced Disclosure Deadline

Traditionally, I have applied a 90 day disclosure deadline to all security issues reported to GNOME Security. 90 days is an industry standard timeline, but it doesn’t work particularly well for GNOME. In practice, almost all GNOME maintainers handle vulnerability reports in one of two ways:

  • The project maintainer fixes the issue quickly, typically within 1-3 weeks after it is reported.
  • The project maintainer does not fix the issue at all. The issue report eventually reaches the 90-day disclosure deadline, at which point I unset confidentiality.

The 90-day deadline is intended to allow project contributors time to fix the issue before it becomes public, but in practice, maintainers do not actually make use of most of this time. I disclose the issue report and request a CVE when it is fixed or when the disclosure deadline is reached, whichever comes first. Once a CVE is assigned, contributors who are not regular project maintainers will sometimes attempt to fix it. Accordingly, keeping the issue reports confidential for 90 days only introduces a delay that is not useful.

Some other projects, notably the Linux kernel, have implemented an immediate full disclosure policy for issue reports that seem to be AI-generated, on the basis that a vulnerability that can be discovered by AI is presumably already known to attackers. But this policy seems pretty extreme, and is certainly unkind to maintainers who might feel pressured to urgently fix the issue. Immediate disclosure would not work well for GNOME.

Instead, I will switch to a 30 day disclosure deadline for issues reported on August 1, 2026 or later. This seems like a good compromise. The shorter deadline would probably work better for GNOME even if not for the increase in AI-generated issue reports.

Procedure for Projects that Prohibit AI-Generated Content

If a project prohibits issue reports that contain AI-generated content, I will no longer forward security issues reported to GNOME Security to the project’s issue tracker, since the overwhelming majority of vulnerability reports contain AI-generated content and would violate the project’s policy. Instead, I will immediately close the issue report in the GNOME Security issue tracker, then ping the project maintainers to let them know about the existence of the report. If you prefer to receive vulnerability reports in your project’s issue tracker, then please change your project’s AI policy to make an exception for vulnerability reports.

Unfortunately, GNOME maintainers don’t have access to confidential issues in this issue tracker, and GitLab does not allow CCing individual developers on confidential issue reports. I had been planning to adopt immediate disclosure for these issues only, but perhaps we should instead expand the permissions to allow all GNOME developers to see the issue tracker. Opinions welcome.

Moving On

I have been managing GNOME security issue tracking since November 2020. (Thank you to Red Hat for supporting this work.) Security tracking is largely a secretarial duty: I keep track of issues when they are reported and when they are closed, disclose them when the deadline is reached, and request CVEs when appropriate. It is not a huge amount of work, but I am getting tired of it, so it’s time for a change. I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

Currently nobody else is tracking GNOME security issues. If you are an experienced GNOME community member and you are interested in taking over this work, let me know and I will help you get started. (Security tracking is not a good task for newcomers.)

This may also be an opportunity to improve our tracking infrastructure. I use a wiki page, but this is fairly primitive and requires considerable manual upkeep. It’s easy to forget to update the page when an issue report is closed, for example. Ideally, we would replace the wiki with a proper web app that dynamically updates based on the actual state of the issue.

Self-Hosting voice services (TTS, ASR, Wake Word)

Posted by Andreas Schneider on 2026-07-20 13:09:40 UTC

TL;DR https://codeberg.org/cryptomilk/crane-wyoming

Where I started

I use Home Assistant, and for text-to-speech (TTS) I’ve been running Piper through Wyoming Piper.

Piper is a fast, local neural TTS engine originally built for the Rhasspy project and now maintained by the Open Home Foundation. It’s designed to run entirely offline, even on modest hardware like a Raspberry Pi.

Wyoming is the open protocol Home Assistant uses to talk to voice components like TTS, speech-to-text, wake word, voice activity detection (VAD, which decides when someone has started or stopped speaking) over the network, so any service that speaks Wyoming can be plugged in as a satellite. Wyoming Piper just wraps Piper so it can be served this way.

Both work well and I have no complaints about reliability. My issue is quality: the German voices aren’t great. Piper depends on open datasets for training, and good open German speech data is scarce, so the German models lag behind the English ones. I also run TTS locally on my desktop for event reminders, so voice quality matters to me beyond just Home Assistant.

Looking for something better

I wanted better output quality, so I started looking at alternatives and found Crane, a Rust inference
framework built on Candle.

An “inference model” is a trained neural network used to actually produce output like text, speech, an image, rather than to learn from data (that’s “training”). An “inference framework” is the software that loads such a model and runs it efficiently: managing GPU/CPU memory, batching requests,
and exposing an API around it. Piper and Crane are both inference frameworks.

Crane already had Qwen3-TTS support, and its Serena voice’s German output sounded noticeably better. I also wanted to try Voxtral-4B-TTS-2603, Mistral’s open-weight TTS model, so I added support for it. Voxtral TTS produces expressive, natural-sounding speech across 9 languages including German, with low time-to-first-audio and streaming support. It is a good fit for a voice assistant that needs to start speaking quickly.

Adding Wyoming support

Once Voxtral was working in Crane, I built crane-wyoming, a standalone Wyoming protocol server, so Home Assistant could use these models as its TTS service. To make that possible, I added the Tts trait and the surrounding TTS abstractions to Crane, since there was no stable interface for driving a TTS model on its own, separate from Crane’s full inference engine (tokenizer/LLM/VLM machinery). Those abstractions have since been merged upstream: lucasjinreal/Crane#44.

crane-wyoming depends on Crane only for that Tts trait and the concrete model types it needs to construct, not Crane’s engine crate. So it carries its own small TTS-only model runtime (one dedicated worker thread per loaded model) and its own on-disk response cache.

The project grew into a small Cargo workspace. Besides the Wyoming server
itself, it now has cw-say, a standalone CLI client for scripting.

It also has sd_crane_wyoming, an output module for speech-dispatcher. speech-dispatcher is the common Linux TTS abstraction layer that screen readers like Orca, and other accessibility tooling, talk to. It launches output modules as subprocesses and speaks to them over stdin/stdout, using its own line-oriented, SMTP-style protocol. sd_crane_wyoming translates that into Wyoming requests against a running crane-wyoming server. That way, the same server process and cache serving Home Assistant can also serve the desktop. After registering it in speechd.conf, spd-say -o crane "..." works. So does anything else built on speech-dispatcher, like Firefox’s “Read Aloud” or Orca itself. All of it gets the same voice quality as Home Assistant, without running a second TTS backend.

What’s next

  • Speech-to-text. I’ve added Qwen3-ASR support for utomatic speech recognition (ASR) into Crane. This needs to be wired in crane-wyoming next. Also Voxtral-Mini-4B-Realtime-2602 is interesting.
  • VAD. Crane already has a Silero VAD implementation. Adding it for STT is straight forward.
  • Wake word. Once VAD is in place, add Open Wake Word support or similar.

With all of that implemented, you’d have a complete self-hosted Wyoming voice stack with no cloud dependency.

Current limitations

The catch is that you need a GPU to run it well.

If you only need TTS for occasional things like reminders, short announcements, running it on CPU with caching is enough, since repeated phrases just get served from cache instead of resynthesized.

All of this is for advanced users and hackers right now. There’s no polished packaging yet. Systemd units exist for both system and user services, including socket activation, but you still have to build from source.

However testing and feedback are welcome.

https://codeberg.org/cryptomilk/crane-wyoming

misc fedora bits: 3rd week of july 2026

Posted by Kevin Fenzi on 2026-07-18 17:48:16 UTC
Scrye into the crystal ball

Another week, another saturday post recaping things. :)

RHEL10 migrations

Bunch more things reinstalled with RHEL10 this last week. Made some good progress. We are soon going to be down to the 'tricky' ones that will require an outage. So, there will likely be an outage or two in upcoming weeks to knock those out before Fedora 45 branching.

Fedora 45 Mass rebuild

The mass rebuild for f45 started this last week and seems to be moving along fine. Of course s390x is the slowest arch, but thats not unexpected.

I did manage to update all the builders and reboot into the latest kernel before the mass rebuild started, along with updating to koji 1.36.1. So far no builders have dropped off or failed that I am aware of, which is nice.

DNS and geoip

This last week we noticed that out dns geoip setup wasn't updating correctly and had some pretty old data in it. This may have been causing some network blocks in some regions to go to proxies that are... not in those regions. ;(

Thanks to work from Vit Smolík, it's now updating correctly. So, for some fedoraproject.org services hopefully some folks will see improved performance with web application access.

I also added memory to some proxies and removed some from the EU zone that were not really in EU.

Thats about it this week...

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

From July 13 to July 19

Posted by Aurélien Bompard on 2026-07-18 07:11:00 UTC

Across the various Fedora working groups, a primary shared focus is the execution of the Fedora 45 Mass Rebuild, which aligns with widespread efforts to modernize core toolchains, system defaults, and developer environments. Another major cross-team initiative is the ongoing infrastructure migration from Pagure to Forgejo, requiring coordination across FESCo, Release Engineering, Design, and Docs. Artificial intelligence and automation have also emerged as a prominent, dual-sided theme: while teams like AI & ML, Security, and Release Engineering are actively developing AI agents to automate nightly compose log analysis and vulnerability scanning, Infrastructure and Release Engineering are simultaneously deploying defensive measures—such as retaining the Anubis system and disabling web-based git blame—to mitigate aggressive AI web scrapers. Finally, there is a strong, unified push toward improving community governance and the contributor experience, evidenced by the drafting of new usage and conflict of interest policies, the creation of the Docs Captain pilot program, and the development of modernized onboarding materials.

Announcements

For Fedora contributors, the Fedora 45 Mass Rebuild has officially started, and maintainers are encouraged to track build failures on Koji. Related to package maintenance, a list of long-term FTBFS (fails to build from source) packages has been published; these packages have failed to build since Fedora 42 and will be retired in early August unless they are fixed or exempted. On a celebratory note, the latest Fedora Podcast (episode 056) highlights the 2026 Fedora Contributor Recognition Program winners, featuring a great conversation with Justin Forbes and Ankur Sinha about keeping the project running and welcoming.

Several new self-contained Change Proposals have also been announced for Fedora 45. The distribution's default databases are slated to be updated to the latest LTS releases, MySQL 9.7 and MariaDB 12.3. The ODBC stack is being modernized to replace static driver registrations with auto-generated configurations using per-driver drop-in snippets. LibreOffice will see two major packaging improvements: the introduction of upstream-sourced hunspell dictionaries for better version syncing, and a switch to HTML-based, noarch help files to significantly reduce repository space. Finally, to simplify Fedora CoreOS provisioning, a proposal aims to enable Ignition to natively accept Butane YAML configurations directly at first boot, removing the need for a separate transpilation step.

Council

During the bi-weekly meeting, the Council reviewed the draft Conflict of Interest Guidelines and agreed to publish the document on Discourse for a two-week public feedback period, offering a key opportunity for community engagement before the rules are formalized. The Council also discussed the upcoming Fedora Forge Usage Policy, focusing heavily on the proposed rules for archiving inactive repositories. To avoid disruptive surprises for existing contributors, the Council formally took ownership of the policy's publication but decided to delay its release until a consensus is reached on how to handle repository archiving. Additionally, members were reminded of an open ticket regarding the Fedora logo license, which will be closed as the license cannot be changed.

On the forums, the discussion surrounding the Fedora Innovation Lifecycle continued with a focus on re-imagining "Initiatives." Members proposed a lightweight, self-managed alternative to the Sandbox process that would allow contributors to showcase multi-release work without strict deadlines or approvals, relying instead on simple "heartbeat" checks to ensure the projects remain active.

Decisions

  • The Council will publish the drafted Conflict of Interest Guidelines on Discourse for a two-week public feedback period before making any formal decisions.
  • The Council formally took over the finalization and publication of the Fedora Forge Usage Policy, but will resolve the ongoing debate regarding the archiving of inactive repositories before publishing it under the Policy Change Policy framework.

Learn more about the Council team.

FESCo

This week, FESCo processed a massive wave of System-Wide Change proposals for Fedora 45, establishing a clear theme of modernizing core toolchains, system defaults, and developer environments. Significant proposals under review include switching the default Secrets Service to oo7, disabling DNF vendor changes by default, and updating major stacks like LLVM 23, Ruby on Rails 8.1, and MySQL 9.7. During their weekly meeting, the committee discussed the upcoming Forgejo distgit migration, agreeing to wait for a published roadmap to ensure proper community feedback on permissions, push rules, and CI integrations before proceeding.

FESCo also addressed late-arriving changes impacting the mass rebuild schedule. While the GNU Toolchain Update was approved to proceed, the Shadow Stack enablement was postponed due to unresolved concerns about breaking third-party applications and Rust-based packages. Other common work topics this week included infrastructure housekeeping (such as updating election policies and issue templates) and routine package maintenance, including handling non-responsive maintainers and retiring inactive software projects.

Decisions

Learn more about the FESCo team.

Workstation / GNOME

In a brief follow-up to the Fedora Workstation Working Group meeting minutes, it was confirmed that the group will be taking a short break from their regular meeting schedule. Due to members traveling to the GUADEC conference and other scheduling conflicts, all meetings for the remainder of July have been called off.

Decisions

  • All Fedora Workstation Working Group meetings for July are canceled. The next meeting is scheduled to take place on August 4, 2026.

Learn more about the Workstation / GNOME team.

Server

The Server Working Group held a weekly meeting (with the agenda and summary posted to the mailing list) focusing on release testing, documentation, and the Fedora home server spin-off. To make F45 release testing more accessible for contributors, the team introduced a new project board and ticket system, which will eventually be automated. For the home server spin-off, a contributor volunteered to set up and document a local Kiwi development environment so others can easily join the effort. The group also discussed updating the contributor's guide to remove outdated Pagure links and welcomed upcoming documentation contributions regarding mDNS and Ansible usage on Fedora.

Decisions

  • The working group agreed to begin F45 release testing using the newly created ticket system, adapting the tickets as necessary throughout the testing process.
  • A server-specific documentation style guide will be drafted to track styling and phrasing decisions that deviate from or add to the main Fedora Docs Style Guide.

Learn more about the Server team.

Infrastructure

The Fedora Infrastructure team kicked off the F45 mass rebuild on July 15th, ensuring autosigning was enabled for the f45-rebuild tag. A significant portion of the week's effort was dedicated to migrating various infrastructure hosts and virthosts to RHEL10, which involved careful timing to minimize builder outages. On the mailing list, the team discussed the effectiveness of the Anubis anti-scraper system. Contributors concluded that Anubis remains absolutely critical for preventing infrastructure outages and managing CPU load, even if some modern AI agents can bypass its proof-of-work challenges.

Operational troubleshooting addressed several immediate issues, including a stalled Bodhi consumer pod that halted Rawhide and ELN updates, PR merge failures on node-exporter, and misrouted EPEL mirrors. The team is also actively improving monitoring by adjusting Zabbix checks and advancing the Forgejo deployment with new metrics templates and foundational work on private issues. Contributors looking to engage can assist with AWS IAM role configurations for projects like Testing Farm and Logdetective, or help refine Apache LoadBalancer timeouts to handle external proxy delays more gracefully.

Decisions

  • Anubis will be retained across the infrastructure as a critical defense against web scrapers and bots.
  • Autosigning was officially enabled for the f45-rebuild tag to support the ongoing mass rebuild.

Learn more about the Infrastructure team.

Release Engineering

The Fedora 45 Mass Rebuild was a central focus this week, with the tracker ticket coordinating readiness across toolchain updates and a meeting discussion clarifying the standard operating procedure for verifying driving changes before commencing. To improve future rebuilds, contributors are exploring ways to update the mass rebuild scripts so they automatically check Bodhi and skip packages that recently failed gating. In community tooling news, an experimental AI Agent was introduced to autonomously analyze Rawhide nightly compose logs and identify root causes of failures, offering a new way for contributors to help triage issues. Meanwhile, the migration to Forgejo continues, with the kiwi-description repository successfully moved and plans forming to replace Pagure AMQP messages with Forgejo webhooks.

Routine release engineering tasks included resolving git repository unpacker errors, setting up Koji tags for ELN image-builder, and processing side tags for the Perl 5.44 update.

Decisions

Learn more about the Release Engineering team.

Quality

The most significant development this week is the launch of on-demand openQA testing for dist-git pull requests. Contributors can now trigger automated tests by simply commenting /openqa test on a PR, with success or failure states reporting directly back to the interface. In other tooling updates, a compose critical package generation script was merged (with Bodhi integration ongoing), openQA test coverage was extended for KDE and Workstation applications, and UI/UX improvements were applied to the testdays-web platform to clarify when events are ready for result submissions. The "Heroes of Fedora Quality Q2" report was also published to celebrate community contributions.

For ongoing contributor engagement, the QA team is calling for community validation on several new nightly composes. Testers with available time are encouraged to review and submit results for Fedora 45 Rawhide 20260718.n.0, Fedora 45 Rawhide 20260715.n.0, and Fedora-IoT 45 RC 20260713.0.

Learn more about the Quality team.

Design

The Design team is actively preparing for upcoming releases and events, including initial planning for the Fedora 46 wallpaper with community polls focusing on "U"-themed inspirational figures. Emma Kidney published a blog post detailing the new collaborative design workflow used for Flock 2026 branding. In other project updates, the team finalized the LoLa AI Package Manager mascot, resolved data issues to generate Flock 2026 YouTube thumbnails, and is working on migrating the fedora-logos repository from Pagure to the Design team's Forgejo space to streamline package updates.

For contributors looking to get involved, there are ongoing efforts to create a Contributor Onboarding Video Series, where the team is currently crowdsourcing opinions on background music. There are also open opportunities to design avatars for Fedora's Matrix bots, including Zodbot, Meetbot, Nonbot, and the new Moderation bot. Furthermore, the team is heavily refining a community onboarding poster to ensure it serves as excellent "rookie reading material" while remaining visually cohesive, accessible, and cost-effective for community members to print.

Decisions

  • Community Poster Redesign: During the July 13th meeting, the team decided to remove solid color banners from the community onboarding poster layout. This decision prioritizes core alignment and spacing, improves visual cohesion, and significantly reduces ink consumption for community members printing the materials at their own expense.

Learn more about the Design team.

Docs

The Fedora Docs team is finalizing its migration away from Pagure.io ahead of the platform's July 31 shutdown, urging maintainers to move remaining repositories to Forgejo (Issue #35). Infrastructure and workflow improvements are a major focus this week, with ongoing work to refactor the local docsbuilder.sh preview script to use updated, secure containers (Issue #19) and efforts to implement automated Forgejo Actions CI monitoring to catch silent production site build failures (Issue #53). Additionally, the team is exploring a massive UI/UX overhaul to better support knowledgebase-style content in the Antora theme, and community brainstorming is highly encouraged even for those not ready to write code (Issue #51).

To decentralize documentation maintenance, the team is launching the "Fedora Docs Captain" pilot program (Issue #50). This initiative pairs subject-matter experts with experienced technical writers to revamp documentation for the Kernel, Multimedia, and AI/ML SIGs. Volunteers are actively needed to serve as sponsors or team leads for these pods. In a related effort, a community initiative is underway to consolidate scattered multimedia, hardware driver, and third-party codec documentation into a single authoritative source to improve the new user experience (Issue #58).

Decisions

  • Repository settings across all docs/* repositories will soon be updated to enforce new contribution guidelines, requiring contributors to submit pull requests via forks rather than pushing directly to repository branches (Issue #46).
  • The "Fedora Docs Captain" pilot program will be timeboxed and evaluated at the Fedora 45 release to determine whether to scale the initiative to other Special Interest Groups or conclude the experiment (Issue #50).

Learn more about the Docs team.

EPEL

This week, the EPEL team focused on package updates, security retirements, and early planning for EPEL 11. Notably, syncthing has been retired from EPEL 8 and 9 due to unfixable security vulnerabilities and SQLite incompatibilities; users are advised to upgrade to RHEL 10 to continue using it. Concurrently, updates for syncthing v2 were pushed to stable for EPEL 10.2 and 10.3. During the weekly meeting, the steering committee also approved incompatible updates for rust-routinator and ffmpeg, with the ffmpeg update planned to land in epel9-next first to allow maintainers time for necessary adjustments.

Looking ahead, early planning discussions for EPEL 11 have begun. A key topic of discussion is addressing feedback from enterprise users who mirror repositories directly by URL (such as with Satellite or Foreman) and were disrupted by recent changes to metalinks and baseurls. A proposal is currently being drafted to remediate this URL structure in EPEL 11—and potentially implement it smoothly in EPEL 10 as well—to ensure a more predictable experience for users.

Decisions

  • Approved the incompatible update request for rust-routinator (Issue #369).
  • Approved the incompatible update for ffmpeg 5 to 7, which will be introduced in epel9-next first (Issue #370).

Learn more about the EPEL team.

ELN

In the ELN meeting, the primary discussion focused on the delayed enablement of bootc images for Fedora ELN. Progress has been slow due to review bottlenecks on the Konflux side, prompting suggestions to move all ELN container builds into Konflux. By standardizing the pipeline and removing bootc as a special case, the group hopes to resolve structural build issues and improve the overall RHEL-on-Konflux experience.

The team also clarified the roadmap for future bootc images, noting that the Fedora ELN bootc image (to be hosted at quay.io/fedora/eln-bootc) will serve as a precursor to upcoming CentOS Stream 11 builds. Because CentOS Stream 11 is still in early bootstrap, contributors agreed to schedule a dedicated conference call to coordinate the integration of Konflux, pungi, and bootc configurations across both the Fedora and CentOS Stream ecosystems.

Learn more about the ELN team.

Atomic

During the Fedora Atomic Initiative meeting, progress was shared regarding Enterprise Linux Next (ELN) base images. Contributors are currently waiting on reviews for Konflux tenant configuration merge requests that will switch the setup from minimal-plus to standard, which is required to complete the ELN base image builds. Once merged, the team will need to determine the process for pushing the resulting base image to the correct namespace, presenting an area where contributors familiar with Konflux might be able to assist.

In broader news relevant to the Linux community and bootc users, an initiative is underway to split Ignition into a standalone RPM, allowing it to be included in more workflows such as bootc container image builds. Additionally, a Fedora 45 change proposal was highlighted that aims to provide native Butane configuration support directly in Ignition. If implemented, this will eliminate the need for the intermediate Butane-to-Ignition conversion step, allowing users to use Butane directly for their instances.

Learn more about the Atomic team.

CoreOS

During the CoreOS meeting, the team reviewed the Fedora 45 Release Schedule and warned that the ongoing Mass Rebuild may cause temporary turbulence and CI breakages in the rawhide stream. The change proposal to enable systemd-oomd and swap on Zram by default was finalized and moved forward in the release process. In other community news, contributors are seeking reviews on an Afterburn pull request designed to make logic less Azure-specific, and members discussed strategies for better surfacing bugs caught in the next stream before they reach stable releases.

A significant portion of the meeting focused on the ongoing need to increase the /boot partition size for new installs, an issue recently highlighted by failing tests on aarch64 rawhide. Acknowledging the complexity of this migration, several contributors volunteered to form a dedicated working group to address it, offering an excellent engagement opportunity for those interested in helping architect a solution for core system storage limits.

Decisions

  • The team approved the systemd-oomd and swap on Zram change proposal and officially marked it ready for the Fedora Change Wrangler.
  • A dedicated working group was formed to tackle the /boot partition size limits, with an initial action item to draft a comprehensive list of requirements for the migration effort.

Learn more about the CoreOS team.

Kernel

This week, a user reported an issue with the Rawhide nodebug kernels setup process. The repository configuration file required to set up the repo on new systems is currently missing from the server, causing the standard wiki instructions to fail.

While the .repo file is missing, the actual repositories are still present and intact on the server. This presents a quick engagement opportunity for infrastructure or kernel contributors to restore the missing file and fix the setup process for the broader community relying on these nodebug kernels.

Learn more about the Kernel team.

AI & ML

The AI & ML SIG is making strides in integrating AI into Fedora workflows, highlighted by a new proof-of-concept AI agent analyzing Rawhide nightly composes to identify failure root causes. To support these efforts, the SIG is formalizing an AI skills library and has established a new "Skills Reviewers" sub-team to curate shared, agent-neutral AI skills. On the hardware front, the SIG is addressing the growing interest in shared GPU infrastructure by initiating a draft for an Acceptable Use Policy to define trust models and access controls for Fedora's GPU hardware.

There are several immediate opportunities for contributors to get involved. The SIG is actively seeking maintainers for new llama.cpp backends (with a priority on Vulkan) and testers for the newly introduced pi-coding-agent in Rawhide, particularly on non-x86 architectures like aarch64. Additionally, developers interested in LLMs are encouraged to help expand the AI Skills Library or integrate other local LLMs into the existing coding agents.

Decisions

  • Skills Reviewers Team: The SIG officially approved the creation of a skills-reviewers sub-team on Forgejo. Seeded with six initial members, the team will manage the ai-ml/skills-library repository and implement a lightweight review process requiring at least one approval before merging new Agent Skills. (Ticket #31)
  • GPU Infrastructure Access: It was agreed that existing GPU infrastructure (gpu01) will be strictly earmarked for CI purposes during the F45 release cycle. General access requests will be temporarily closed as wontfix while the hardware remains in a "transitionary/exploration" phase and the formal Acceptable Use Policy is drafted. (Ticket #34)

Learn more about the AI & ML team.

RISC-V

The Fedora 45 rebuild for RISC-V is currently about 25% complete, and the team continues to make steady progress resolving remaining issues on the Fedora RISC-V tracker. Hardware capacity has expanded, with four RVA23 units—including community-contributed hardware—now active in the Fedora RISC-V Koji. Furthermore, technical discussions are actively underway with hardware vendor SpacemiT's Linux team to improve virtualization support and resolve known issues.

For those looking to get involved with the group, requirements for a potential RISC-V intern have been drafted and published, offering a new engagement opportunity for prospective contributors.

Decisions

  • The team decided to optimize the F45 rebuild by importing approximately 50% of "noarch" packages directly from the primary Koji into the RISC-V Koji, which will save significant time and compute resources.

Learn more about the RISC-V team.

Security

The Security SIG held a meeting this week primarily focusing on secure development practices and how end-users can verify Fedora's security posture. The group highlighted existing safeguards like the package review process and mandatory hardening compiler flags, while also discussing the integration of automated vulnerability management tools. Notably, the conversation covered the new ProdSec scanner (Trustshell) and Hummingbird, a tool that uses AI to scan for CVEs and automatically generate pull requests for Rawhide packages. The team also explored the potential of mapping Fedora's practices against the OpenSSF baseline checklist.

Contributors looking to get involved can review the meeting agenda and logs on the forum. Several topics were deferred due to time constraints, providing an excellent opportunity for asynchronous engagement on the SIG's issue tracker, particularly regarding the Cyber Resilience Act (CRA) requirements and Linux-distros mailing list policies.

Decisions

  • The discussion on aligning Fedora's security documents with the "Vulnerability and Incident Policy" CRA requirement (Ticket #14) was postponed to next week's meeting.
  • The Linux-distros discussion (Ticket #13) was deferred to be handled asynchronously on the issue tracker.

Learn more about the Security team.

Gaming

David Campbell announced the release of Hnefatafl Copenhagen 6.1.1, a strategic board game with historical roots similar to Chess or Go. Linux gamers interested in trying it out can install the game by enabling the dcampbell24/hnefatafl-copenhagen Copr repository. Once installed, it can be launched directly from the application menu or by running hnefatafl-client in the terminal.

Learn more about the Gaming team.

Go

In a recent discussion, Tadej Janež sought advice on packaging docker-credential-helpers for Fedora. Because the upstream project includes macOS and Windows-specific helpers (osxkeychain and wincred), the conversation focused on excluding these unnecessary modules and their dependencies from the vendor tarball using go2rpm. Mikel Olasagasti provided a solution to remove the directories prior to archiving, which successfully cleared out the unneeded dependencies.

This process resulted in an essentially empty vendor archive, prompting Tadej to ask follow-up questions about handling SPEC file macros that operate on empty vendor sources and resolving an rpmlint error caused by a zero-length modules.txt file. Contributors with Go packaging experience are encouraged to join the thread to help resolve these final packaging hurdles.

Decisions

  • The package will use pre_commands and exclude_directories in the go-vendor-tools.toml configuration to explicitly remove the OS X and Windows credential helpers (osxkeychain/ and wincred/) from the vendor archive and licensing checks.

Learn more about the Go team.

Perl

This week, the Perl group focused heavily on routine package maintenance and version updates. Michal Josef Špaček successfully merged multiple version bumps, updating perl-Test-Inter to 1.13 across PR #9, PR #10, and PR #11, as well as updating perl-HTTP-Date to 6.08 in PR #5, PR #6, and PR #7. In broader Linux community news, Michal Schorm submitted a patch to fix a Failure to Build From Source (FTBFS) in perl-SDL caused by underlying code behavior changes, which was subsequently merged by Hans de Goede. Additionally, contributors looking to engage with RHEL compatibility can review Yaakov Selkowitz's newly opened pull request for perl-HTTP-Daemon to build the package using Module::Build on RHEL.

Decisions

The group approved and merged the FTBFS fix for perl-SDL. They also officially accepted the version bumps for perl-Test-Inter (1.13) and perl-HTTP-Date (6.08) across their respective repository branches.

Learn more about the Perl team.

Other Discussions

Orphaning packages

  • Orphaning xset and xrdb: Peter Hutterer announced the orphaning of the xset and xrdb packages, inviting anyone who still has a use for them to take over maintenance.

Package updates

  • Orphaned package wavemon updated to 0.9.7: A user provided an updated COPR build for the orphaned wavemon package (version 0.9.7) for Fedora 44, offering occasional future builds without committing to long-term maintenance.
  • z3 soname bump: Jerry James announced an upcoming soname bump for z3 version 5.0, which will require rebuilding opam and prusa-slicer.
  • Node.js rolling stream: upgrade path for current nodejs22: A discussion was started regarding the upgrade path for users currently on the nodejs22 stream in F44/Rawhide as the project transitions to a metapackage approach.
  • Flint soname bump: Jerry James announced an update to flint version 3.6.0, which includes a soname bump requiring rebuilds for several dependent packages like Singular and polymake.
  • libupnp soname bump: Gwyn Ciesla announced an upcoming upgrade for libupnp to 22.0.3 in Rawhide, confirming that dependent rebuilds will be handled.

New contributor introductions

  • Mohab Soliman, a mechatronics engineer from Egypt with experience in 3D printers and FreeCAD, introduced themselves to the 3D printing SIG and asked for guidance on contributing.
  • Jesus De Los Reyes Larraga, a QA/platform engineer, introduced themselves, offering their expertise in infrastructure, automated testing, and various programming languages to contribute to the ecosystem.
  • Philip Czarnik, a software developer from Germany with experience in Angular, Java, Python, and C/C++, introduced themselves and expressed interest in volunteering 2-4 hours to start contributing.

Banco Mundial de Sementes de Svalbard

Posted by Avi Alkalay on 2026-07-17 19:07:06 UTC

A expedição mal tinha começado e eu já recebia um baque inesperado e surpreendente numa pequena volta guiada em Longyearbyen, entre o vôo de chegada e o embarque no navio. O guia citou o Banco Mundial de Sementes de Svalbard como a coisa mais normal do mundo. Como se ter a ideia e executar o plano de criar uma espécie de Arca de Noé da genética vegetal planetária fosse tão banal e desimportante quanto fazer o chá da tarde.

Que iniciativa absolutamente genial, importante, estratégica, vital! E claro que depois devorei referências e informações sobre isso.

Concebido, construído e mantido pela Noruega (outro financiador citado é a Fundação Bill & Melinda Gates), trata-se de um enorme armazém escavado 130 metros dentro da rocha. Svalbard foi escolhido como local por não ter atividade sísmica e por ter permafrost (gelo constante) que ajuda a preservar as sementes a -18℃. Mesmo que os sistemas de refrigeração falharem, o permafrost garante que a temperatura do armazém subirá a 0℃ somente após uns 200 anos.

A Noruega não cobra, é gratuito países depositarem sementes no armazém. O objetivo é preservar a biodiversidade agrícola e de plantas do planeta.

Guerras, conflitos, mudanças climáticas e outros problemas podem causar perda de biodiversidade e indisponibilidade de sementes para replantar uma espécie vital para a humanidade. E de fato, em 2015, a 🇸🇾Syria precisou recuperar do armazém de Svalbard algumas sementes. Essa foi a primeira vez que tal emergência aconteceu. E esperamos que nunca mais se repita.

Também no meu Instagram e Facebook.

Expedição ao Polo Norte

Posted by Avi Alkalay on 2026-07-17 18:46:25 UTC

Embarcamos numa expedição ao Polo Norte centrada em Svalbard, arquipélago da 🇳🇴Noruega que fica dentro do Círculo Polar Ártico (latitude 67°). Organizada pela Latitudes Viagens de Conhecimento, voamos de Oslo à pitoresca Longyerbyen e lá embarcamos no navio Sylvia Earle para circundar e atracar em diversos pontos do arquipélago.

Santuário protegido, impressionantes glaciares, pássaros, baleias, morsas, raposas e ursos polares, proporcionaram perspectivas inéditas e emocionantes para vivenciarmos nosso Planeta. Como se não bastasse, nos acompanharam guias que eram historiadoras, geólogos, biólogas, antropólogas e até filósofos que ampliavam o significado de absolutamente tudo o que vimos. Não era só ver glaciar; era ver glaciar com a História geológica do lugar e a profunda transformação que sofreu nas últimas décadas com o aquecimento global, e como isso afeta toda a Terra. Não era só ver urso polar ou baleia; era isso junto com a História da caça às baleias, geopolítica e como elas foram salvas pelo descobrimento do petróleo. Enfim.

Cada saída exploratória tinha uma surpresa ou algo inesperado, ou curiosidade de cair o queixo, ou simplesmente a emoção avassaladora de estar em frente a um glaciar de 200km de borda por 55m de altura (Austfonna).

Daqui para frente farei algumas publicações de fotos que são só ilustrativas para o relato do que aprendi e me impressionou, que segue nos respectivos textos. São informações novas e valiosas para mim, que preciso registrar.

Também no meu Instagram e Facebook.

The Dumb Git Protocol That Flooded Our Git Server

Posted by Miroslav Vadkerti on 2026-07-17 00:00:00 UTC
A CI clone spike pulled terabytes off an internal git server and caused an outage. The cause was one URL pointing at git’s dumb HTTP protocol, which makes every fresh clone re-fetch a repo object by object.

Loadouts For Genshin Impact v0.1.18 Released

Posted by Akashdeep Dhar on 2026-07-15 18:30:19 UTC
Loadouts For Genshin Impact v0.1.18 Released

Hello travelers!

Loadouts for Genshin Impact v0.1.18 is OUT NOW with the addition of support for recently released characters like Sandrone and for recently released weapons like A Teaspoon of Transcendence from Genshin Impact Luna VIII or v6.7 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

  • Complete the 4-piece bonus for Disenchantment in Deep Shadow by @qorexdevs in #575
  • Revisit the title case class names for weapons by @gridhead in #570
  • Added Sandrone to Loadout by @Ank-22 in #578
  • Added A Teaspoon of Transcendence by @Ank-22 in #579
  • Review A Teaspoon Of Transcendence inclusion by @gridhead in #582
  • Create separate GitHub Action for generating point releases by @gridhead in #571
  • Automated dependency updates for GI Loadouts by @renovate[bot] in #566
  • Disable caching while building executable binaries by @gridhead in #584
  • Update actions/download-artifact action to v8 by @renovate[bot] in #583
  • Stage the release v0.1.18 for Genshin Impact Luna VIII (v6.7 Phase 2) by @gridhead in #585

Characters

One character has debuted in this version release.

Sandrone

Sandrone is a claymore-wielding Cryo character of five-star quality.

Loadouts For Genshin Impact v0.1.18 Released
Loadouts For Genshin Impact v0.1.18 Released

Sandrone - Workspace and Results

Weapons

One weapon has debuted in this version release.

A Teaspoon of Transcendence

White Fairy's Queening - Scales on Crit DMG.

Loadouts For Genshin Impact v0.1.18 Released
A Teaspoon of Transcendence - 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 1584 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.

The importance — or not — of reputation

Posted by Ben Cotton on 2026-07-15 12:00:00 UTC

We talk a lot in open source about reputation. Individuals have a reputation. Projects have a reputation. This reputation is how we build trust with strangers from around the world. People and projects have an incentive to behave well so as to not ruin their reputation. Or do they?

Glyph

@miss_rodent yeah, that's kinda what I mean. The whole industry behaves as if you have a strong incentive to behave in a particular way because we have some strongly-tracked pervasive notion of reputation. but we barely have any notion of reputation *at all* let alone a structured and carefully enforced one. if this breaks the floodgates on activism-via-RCE, that broken trust is going to take a long time to repair

2026-05-30, 3:18 am 0 boosts 8 favorites

Glyph is right. We put too much on the concept of reputation without stopping to think about what it actually means.

One way that I’ve seen this come up a lot is in conversations about blocking AI agents — or humans who are just a translation layer between an AI model and a project. Folks have come up with a variety of different ways to determine who is a real, trustworthy person that should be allowed to make a contribution to the project. Some, like Mitchell Hashimoto’s vouch, use an explicit maintainer vouching model. Others use heuristics that look at account activity to make a guess. Both of these models can make it harder for newcomers to make those early contributions that build their reputation.

Discourse’s trust levels are a pretty good model for a trust ladder in a community. The problem is that once you go to a different Discourse site, you’re brand new again. Similarly, someone who has been banned from a community for repeated misbehavior can join a new community with no trouble.

In chapter three of Program Management for Open Source Projects, I talk about trust being a combination of person and role. You might trust me when I write about leading open source communities but not when I write critical software. By the same token, I’m relatively well-known in places like Fedora and the OpenSSF. But at an Erlang conference, nobody has heard of me.

If you’ve gone to a conference, you’ve probably had an experience along these lines: you chat with a friend-of-a-friend in the hallway for a few minutes, think “they seem nice”, and then later you learn they invented your favorite compression algorithm. Even the biggest of the Big Names are a nobody to a lot of people.

So reputations? Not that useful. If you can build a good one, that’s nice, but you can’t count on it.

The problem with reputation is that it doesn’t answer the question you want to answer (unless that question is “who is well-known?”). Start by figuring out what question you want answered. Then you can find the best way to answer it. And don’t rely on “but you’ll ruin your reputation” to prevent bad behavior.

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

The post The importance — or not — of reputation appeared first on Duck Alignment Academy.

Things I Read: 30 Apr – 14 Jul 2026 - Beach Reads Edition

Posted by Brian (bex) Exelbierd on 2026-07-15 07:50:00 UTC

I got behind a little in my reading and a lot in my posting because of the onrush of the end of school, the beginning of summer and holiday season, and needing to give two talks. This catch-up post is a bit longer than most, but that’s partly because it represents some binge reading I did while on the beach on vacation. I accidentally gave myself a digital detox because I took my Kindle loaded with 300 unread items from Instapaper and a bunch of books and wound up using it way more than I used my phone. The winnowed down results are here and I hope you enjoy them.

Disclaimer: I work at Microsoft on upstream Linux in Azure. These are my personal notes and opinions.

AI & the future of software work

  • The bottleneck has moved: redesigning the SDLC for AI

    I’ve always been bothered by the admonishment that you must “read every line of code” generated by an LLM. This article argues that LLMs are useful only if they boost the throughput of the whole system. That boost comes from the same place it always has: features of acceptable quality that move the codebase further toward its goals.

    Since humans aren’t going to read every line of code, and never have, what do you do instead? You formalize the gating humans have traditionally used.

    Risk-based change classification is one example. Not all work requires the same level of scrutiny. Some changes are routine, well-understood, and low risk. Others carry architectural, security, or product risk that demands deeper review. Classifying work by risk profile allows scarce human judgment to be applied where it matters most, instead of spread thinly across everything.

    I found this opening comment about Agile insightful because it made me think about what its rituals should do, rather than what we built an industry to do.

    Agile wasn’t primarily about being nimble or responding to change. That’s the story we told about it. Agile was the industry’s answer, mostly unconscious, to a single problem: how to manage a scarce, expensive development bottleneck.

  • Let’s talk about LLMs

    Writing code not being the hardest or most critical part of building software isn’t controversial, except among those for whom writing code is pleasurable. I believe most people want to focus on the harder parts, not grinding out code. One goal of LLM coding tools is to allow anyone, experienced or not, to produce code that achieves their goal.

    It seems to be widely agreed among advocates of LLM coding that it’s a skill which requires significant understanding, practice, and experience before one is able to produce consistent useful results … strong prior knowledge of how to design and build good software is also generally recommended or assumed.

    I believe I can do this, but I’ve been a developer. The real question is whether someone can learn to do this without ever having been a developer. More and more, I believe the answer is yes, we just haven’t looked at the problem long enough in isolation. Accounting, piloting, and other professions have seen core elements of their work automated away and retooled their education systems to account for this. I believe software development can too.

  • “maybe later” was a feature - arnorhs.dev

    This article provides the corollary risk. Our backlogs are filled with work that would require enough effort that we should seriously question the value of doing it. Unchecked LLM use as a way to grind through it is as bad as anything else done unchecked.

    The rule of product management is to keep builders so busy they don’t have time to invent things to deliver. If LLMs accelerate development, product has to accelerate too. A company has to organize to use its people wisely, otherwise garbage from the backlog gets built.

Forking

  • Open source was not ready for AI-speed contributions

  • Reviving an Abandoned Open-Source Project: 6 Years of Atomic Calendar Revive

  • Respectful Open Source

    Together, these three articles poked at a thought that has been in my mind for a while. We need more forks. Not the “soft fork” or “friendly fork” variety, but also not “hard forks,” which, to me at least, carry a connotation of anger or social breakdown. We need forks where someone carries the patch they wrote or generated. We need forks where others can review the patches “on offer” and discuss or debate them. We need well-maintained forks that keep up with their upstream. That is inherently required if you care about your patch and the project, and it lets long-term maintenance and use signal to other forks and the upstream that your patches may be worth carrying. All of this will require an infrastructure that can surface forks usefully, something GitHub and their clones haven’t figured out yet.

    A common complaint is that we are drowning in PRs with no more review capacity. Carrying your own patch in your own fork moves us toward that.

    A fork isn’t “I fixed it for me.” It’s “I’m now responsible for fixing it for everyone.” That’s a much bigger sentence than it looks. – “Reviving an Abandoned Open-Source Project: 6 Years of Atomic Calendar Revive”

    The last article really drives this home: a patch not submitted may be the best solution for some things.

Open Source Sustainability

  • The Quiet Renovation at Bitwarden - ByteHaven - Where I ramble about bytes

    Apparently “always free” is back at Bitwarden. But this author isn’t happy about that. They’ve already “moved on” to a free clone. This attitude is what really bothers me.

    The “all for me, none for thee” mentality: “I am shocked that the company that creates the thing I refuse to pay for hasn’t found a market to sustain itself from other people who, because they aren’t me, should pay. Now it is forced to figure out a profit strategy that includes cutting costs for users like me. Instead of becoming a supporter of the thing I need, want, and claim to care about, I’ll begin using an open source project that spends most of its time either repackaging the company’s code or blindly reimplementing its features with little to no innovation. That’ll show them!”

    It’s like the argument about LLM resource usage. In aggregate, it is huge, and because that is bad, we should save some of our torches and pitchforks for use on the users, even though at a personal level it is very little. Here we see the opposite: people think code development and web hosting should be free because one free-rider user costs little, even though those costs are real in aggregate.

  • Why Gentoo?

    In discussing Gentoo, the use of tools like GitHub and Codeberg is touched on:

    Sure, abandoning them would be inconvenient for us, but we can do that if need arises.

    Many make these kinds of statements and then get angry when Big Corp (tm) uses a project and doesn’t contribute back. Hint: this is the exact same thought that your favorite noncontributor is having. Changing projects will be an inconvenience, but it is a calculable risk. It is the difference between “Mr./Mrs. Right” and “Mr./Mrs. Right Now.”

    As a bonus, I love that they mention OpenPGP being used for the one thing it is actually good at. Shout out to The PGP problem.

Growing older and longevity

As someone rapidly becoming a man of a “certain age,” and who has begun attracting the non-terminal health problems associated with that age, this roundup of articles stuck with me.

Even if you are not yet of a certain age, you should read this stuff. The challenges are coming for you too.

  • Even a Little Alcohol Can Harm Your Health

    The idea that a low dose of alcohol was heart healthy likely arose from the fact that people who drink small amounts tend to have other healthy habits, such as exercising, eating plenty of fruits and vegetables and not smoking. In observational studies, the heart benefits of those behaviors might have been erroneously attributed to alcohol, Dr. Piano said.

  • Are You Aging Well? Try These Simple Tests to Find Out.

    As the old saw goes, “that which is measured is managed.” These tests will help you know where you are so you can decide what to do. The goal isn’t to ace the test, it is to live healthier.

Social connection & talking to strangers

  • The Dialogue Dividend

    Intentionally scheduling no-agenda calls with friends you can “water cooler” talk with is critical for your mental health. Professionally, it can be a bit self-reinforcing if you don’t grow your network. Therefore, you should talk to strangers, as the next articles suggest.

  • The stranger secret: how to talk to anyone – and why you should

    study by the University of Virginia (Talking with strangers is surprisingly informative) … “People tend to underestimate how much they’ll enjoy the conversation, feel connected to their conversation partner and be liked by their conversation partner.”

    You are just saying, “It’s cold today, isn’t it?” You are not asking someone to join you on a quest for world peace.

  • Why saying hello to strangers can be good for you

    reported on studies showing that simply chatting with strangers has a lasting impact: It can make participants happy.

  • The World: Aging well as an introvert

    Considering all the research around socializing and longevity, some introverts can be forgiven for feeling worried.

    I’ve never felt like I’ve had a lot of friends. This article focused on the kinds of people you know and should have in your network, even if you’re someone who doesn’t want or need a lot of people around. The categories really resonated with me.

    Note: This link is to a Newsletter I receive and I’ve been unable to find a link to it as a published article.

Economics

  • Why Japanese companies do so many different things

    With the rise of LLMs, companies spend all of their time talking about how they can cut staff. In contrast, here are Japanese firms awash in labor, diversifying and growing.

  • AI Agents Have Already Chosen Their Money: Bitcoin

    The Bitcoin Policy Institute found that AI agents choose Bitcoin, which is shocking(!) The prompts profess a need to be neutral about policy and then describe situations where Bitcoin is theoretically best. It is a first-class example of results seeking.

Evil is done by failures

  • Hitler Was Incompetent and Lazy—and His Government an Absolute Clown Show

    There are no evil geniuses. There are charismatic fuck ups who find minions to do the dirty work (see the next article). Just because you can’t find the intelligence behind the boot on your neck doesn’t mean you should stop worrying about removing it.

  • Actually, Democracy Dies in H.R.

    Over 20 years ago, I remember having a conversation with a friend. We were both unhappy at work and he was debating changing professions entirely. He said he was seriously thinking about joining the US Border Patrol. When I questioned this, he explained that it was known as a fast path to better government jobs and higher level positions in other agencies.

    Reading this article and looking back at 20 years of US border and immigration policy, I believe I now understand this on a whole new level.

Recently Finished Books

I’ve been tracking my book reading on my blog, but those notes never get surfaced anywhere. I’ve decided to start including links here. Head to my reading page to find detailed notes or reactions for each book, similar in style to this post.

And finally

  • I Sold Out for $20 a Month and All I Got Was This Perfectly Generated Terraform

    This one has some real banger quotes, but also hits on the core issue of code as craftsmanship. In a departure from the norm, I’ll let quotes drive this.

    Who was going to hire this band of Eastern European programmers who chain smoke during calls and whose motto is basically “we never miss a deadline”. As it turns out, a lot of people.

    How pleasant and well-organized that code is to work with is not really a thing that matters in the long term.

    It’s $7000 a year for the servers, with two behind a load balancer. That’s absolutely nothing when compared with the costs of what having a team of engineers tune it would cost

    Visual imagery aside, when you buy for a deadline, you are not buying for beauty. Keep that in mind.

    I delight in craftsmanship when I encounter it in almost any discipline. I love it when you walk into an old house and see all the hand crafted details everywhere that don’t make economic sense but still look beautiful. I adore when someone has carefully selected the perfect font to match something.

    “well great doesn’t matter at all” effectively boils down to “don’t take pride in your work” which is probably the better economic argument but feels super bad to me. In a world full of cheap crap, it feels bad to make more of it and then stick my name on it.

    So now I’m paying $20 a month to a company that scraped the collective knowledge of humanity without asking so that I can avoid writing Kubernetes YAML.

    “You know what the difference is between you and me? I know I’m a mercenary. You thought you were an artist. We’re both guys who type for money.”

    The companies paying for the creation of open source aren’t hiring craftspeople or artists. They aren’t the Medicis handing out money to support the creation of great works of art. They are hiring bands of mercenaries. The key is that most of them have used the cult of open source and the identity of developers as craftspeople and artists to avoid having to pay for quality and instead get it for free. You got hired to mulch the flower beds. You trimmed the bushes, edged the lawn, and planted more flowers for free. Maybe you did it for “the users” which is great when they are real people who really exist. However, a lot of the code we work on for commercial open source companies is being consumed by other commercial entities, not humans. They didn’t care about the flowers either.

What Does Fedora Want From Me Today?

Posted by Neil Hanlon on 2026-07-14 17:54:48 UTC

I began contributing as a packager with Fedora a few years ago, in concert with my participation in founding and bootstrapping Rocky Linux from the ground up. That alone deserves a blog post series I may write some day… but more to the point… I haven’t done a great job of maintaining my packages. There’s a host of reasons I could get into for why, but particularly in light of having a newborn and therefore much more limited time and energy than I ever thought was possible, optimizing my workflows and maximizing my impact (and reducing ownership of things where needed) are the most powerful knobs I can use to make the greatest difference not just in Fedora but across all the things I involve myself with.

What Does Fedora Want From Me Today?

Posted by Neil Hanlon on 2026-07-14 17:54:48 UTC

I began contributing as a packager with Fedora a few years ago, in concert with my participation in founding and bootstrapping Rocky Linux from the ground up. That alone deserves a blog post series I may write some day… but more to the point… I haven’t done a great job of maintaining my packages. There’s a host of reasons I could get into for why, but particularly in light of having a newborn and therefore much more limited time and energy than I ever thought was possible, optimizing my workflows and maximizing my impact (and reducing ownership of things where needed) are the most powerful knobs I can use to make the greatest difference not just in Fedora but across all the things I involve myself with.

Syslog-ng 4.12.0 available for Ubuntu 26.04 (Resolute)

Posted by Peter Czanik on 2026-07-14 12:41:41 UTC

Recently I was asked if syslog-ng supports Ubuntu 26.04 (Ubuntu Resolute). Yes, and with the arrival of the syslog-ng 4.12.0 release we also provide ready-to-use packages for it. The release notes mention it, and info is in the Readme on GitHub.

I tend to mention FreeBSD and openSUSE more often in my blogs (personal preference), so today I installed Ubuntu 26.04 and tested syslog-ng myself.

Read more at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-4-12-0-available-for-ubuntu-26-04-resolute

syslog-ng logo

Steam: para que jale bien en Fedora 44

Posted by Rénich Bon Ćirić on 2026-07-13 22:20:00 UTC

Hoy te vengo a contar sobre un desmadre con el que me topé instalando Steam en mi Fedora 44. La neta es que instalar el cliente con un simple dnf -y install steam parece que hace todo el paro, pero a la hora de la verdad, jugar de manera fluida y sin fallas en Linux requiere afinar varios detalles que dnf no te va a solucionar por sí solo.

Si tú tienes una tarjeta de video AMD Radeon (en mi caso una RX 7900 XTX) y crees que con el comando por defecto ya estás del otro lado, déjame decirte que te vas a quedar a medias. Aquí te platico lo que aprendí que es indispensable para que tu setup de Vulkan y Steam funcione al cien, y por qué el metadato por defecto del paquete de Steam se queda corto.

Los archivos que faltan y por qué valen madre las cosas

Cuando dejas que dnf haga la instalación básica de Steam, el manejador de paquetes se enfoca en que abra el cliente y poco más. Pero cuando ejecutas juegos modernos mediante Proton, el juego tiene que compilar shaders a nivel interno y decodificar videos/cinemáticas que usan codecs patentados. Ahí es donde todo se va a la chingada si no tienes lo siguiente:

Aceleración por Hardware de Codecs Patentados (Freeworld):
Fedora, por cuestiones de patentes, compila sus drivers de Mesa sin cochinadas privativas. Lo malo es que no soportan decodificación por hardware de H.264, H.265 (HEVC) o VC-1 de forma nativa. Si juegas algo en Proton que use estos formatos en sus cinemáticas, el juego se va a trabar o congelar. La solución es instalar los drivers freeworld de RPM Fusion para reemplazar los de stock.
La biblioteca de cómputo y el desmadre de SPIR-V (libclc):
Para que Mesa pueda compilar shaders, depende de libclc (la implementación de funciones OpenCL). Históricamente, en varias distros, los archivos de compilación intermedios de SPIR-V (los archivos .spv) se empaquetaban erróneamente en paquetes de desarrollo (-devel). En Fedora 44, estos binarios residen en el subpaquete libclc-spirv. Si tu juego o emulador intenta compilar shaders y no encuentra estos archivos, valió madres todo; el juego se va a crashear sin decirte por qué.
Monitoreo de Telemetría (MangoHud):
Para verificar que tu juego de verdad esté corriendo bajo Vulkan y usando la GPU dedicada (y no cayendo en un fallback feo por software como llvmpipe), necesitas MangoHud. El paquete de Steam no lo instala por ti, y necesitas instalar tanto la versión de 64 bits como la de 32 bits porque Steam corre juegos de ambas arquitecturas.
Diagnóstico (vulkan-tools):
Para no andar a ciegas, necesitas la herramienta vulkaninfo para asegurarte de que tu sistema reconozca tu tarjeta de video y no tenga conflictos con capas implícitas de Vulkan.
Plugins de GStreamer de Freeworld (gstreamer1-plugins-bad-freeworld / gstreamer1-plugins-ugly):
Proton y varios juegos nativos usan el framework GStreamer para decodificar videos internos y cinemáticas. Al igual que con Mesa, las patentes obligan a Fedora a dejar fuera los códecs de video/audio más populares (como AAC, H.264, etc.). Si no instalas las versiones de RPM Fusion, los juegos se quedarán con pantallas en negro en los cutscenes o de plano crashearán.
Micro-compositor Gamescope (gamescope):
El compositor de ventanas de Valve para juegos. Es súper útil para forzar resoluciones específicas, habilitar reescalado por hardware (como FSR) a nivel de sistema, limitar los FPS de forma global y evitar desmadres con pantallas múltiples y ventanas.

Note

Para habilitar los paquetes freeworld es obligatorio que tengas activados los repositorios de RPM Fusion Free y Nonfree. A estas alturas ya deberías tenerlos listos, compa.

El comando definitivo

Bueno, ahí va el cotorreo. Para corregir este desmadre y dejar tu sistema chingonsote para jugar, tienes que correr este comando en tu terminal:

# Instalar MangoHud, compositor, decodificadores de video y drivers freeworld
# Corre esto como root
dnf -y install --allowerasing \
    vulkan-tools \
    gamescope \
    mangohud.x86_64 \
    mangohud.i686 \
    gstreamer1-plugins-bad-freeworld \
    gstreamer1-plugins-ugly \
    mesa-vulkan-drivers-freeworld.x86_64 \
    mesa-vulkan-drivers-freeworld.i686 \
    mesa-va-drivers-freeworld.x86_64 \
    mesa-va-drivers-freeworld.i686 \
    libclc-spirv.x86_64 libclc-spirv.i686 \
    libclc-devel.x86_64 libclc-devel.i686

Important

Una vez que termines de instalar todo este cotorreo, tienes que reiniciar tu máquina (reboot). Sí o sí, compa. Esto asegura que systemd cargue las nuevas variables de entorno, que Steam se reinicie por completo y que el sistema cargue las nuevas bibliotecas dinámicas (como el driver de video freeworld y las capas de Vulkan) de forma limpia.

¿Qué onda con las advertencias de vulkaninfo?

Una vez que tengas todo instalado, la neta te recomiendo correr vulkaninfo --summary para verificar que tu GPU0 sea detectada con tu tarjeta AMD y el driver DRIVER_ID_MESA_RADV.

No te espantes si te sale una advertencia coolera sobre libvulkan_dzn.so diciendo que falló la creación de la instancia con código -9. Ese driver es la capa de Direct3D 12 para Vulkan orientada a entornos de Windows/WSL2. Como tú estás en Linux nativo con el driver AMDGPU, es normal que no encuentre ningún dispositivo D3D12 y aborte. Es completamente seguro ignorarlo.

Conclusión

A final de cuentas, ¿qué fue lo que hicimos con todo este desmadre? Configuramos una base sólida para que Steam y Proton no tengan ningún obstáculo:

  • Reemplazamos los controladores limitados de Fedora con las versiones freeworld de RPM Fusion para dar paso a la aceleración por hardware de video.
  • Instalamos las bibliotecas SPIR-V necesarias (libclc-spirv y libclc-devel) para que el compilador de shaders de Mesa (ACO) trabaje sin crasheos.
  • Agregamos GStreamer completo para evitar pantallas en negro en cinemáticas y Gamescope/MangoHud para el control y diagnóstico del rendimiento.
¿Por qué va a funcionar mejor y qué puedes esperar?
A partir de ahora, notarás que los juegos en Steam Play (Proton) cargan sus cinemáticas correctamente y sin caídas de FPS gachas, la compilación de shaders no se detendrá a mitad del camino por archivos faltantes, y podrás forzar resoluciones y ver tu rendimiento en tiempo real. Jugar en Fedora 44 ahora sí será una experiencia fluida y sin sorpresas. ¡A darle átomos y a jugar chido!

Departing From Flock To Fedora 2026

Posted by Akashdeep Dhar on 2026-07-13 18:30:15 UTC
Departing From Flock To Fedora 2026

When I was just about getting used to the time zone shift and the hotel bedding, 17th June 2026 came, and I had to leave Prague. Even though I did my packing beforehand, I still found myself waking up as early as around 0500am Central European Summer Time. My scheduled flight, Emirates EK0140, was going to take off from Prague (PRG) for Dubai (DXB) at 0400pm Central European Summer Time, so I had plenty of time to connect with family and friends back home. After having a quick breakfast by myself at around 0730am Central European Summer Time, I saw Tomáš Hrčka leaving the Ibis Praha Mala Strana hotel at that time. I made a brief return to Nový Smíchov Shopping Centre to purchase more goodies for my folks before returning to meet with a departing Lenka Segura at breakfast.

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #01

I also met with Kamil Paral briefly, who was on his way out too, and Lukas Ruzicka and Adam Williamson at the hotel lobby, who were planning on leaving too. After dropping my goods at the hotel, I headed over to the nearby Rossmann Cosmetics outlet for some purchases, as advised by my sister-in-law and my mother. As the Douglas Lifestyle inside the Nový Smíchov Shopping Centre did not open by then, this also allowed me to walk a little further on an overcast morning, after it seemed to have rained heavily the previous night. Taking the scenic route while heading back to the hotel, I clicked a bunch of pictures while being on a video call with my family members along the walking route. As the designated check-out time was 1200pm Central European Summer Time, I had plenty of time to pack my goods.

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #02

Thanks to the spring balance that I was carrying with me, I got my checked-in luggage to around 24 kilograms - staying well under the Emirates standard limit of 30 kilograms, while my travelling backpack was barely about 5 kilograms heavy. I started heading downstairs at around 1150am Central European Summer Time, and with the checkout done, I started looking for cabs on the Uber application. It took forever for a ride to be booked on that platform, so I instead relied on the Bolt application, which got me a ride in about the next 10 minutes or so. I was able to swiftly make it to Václav Havel Airport Prague (PRG) by around 1245pm Central European Summer Time, and after a failed attempt at securing the VAT refund, I decided to have myself checked in for the journey without wasting more time on it.

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #03

At the designated Emirates check-in gates, there were automated kiosks for self-service with multiple human attendants too, for if (read whenever) someone faced difficulties with the novel process. After having my luggage sent and a quick chat with the human attendants to ensure that the check-in kiosk also accounted for layover journeys, I headed into the immigration checks. Surprisingly enough, the immigration process, both during arrival and departure, was stamp-free and very seamless. I, for one, loved getting immigration stamps on my passport, so while that did ease the process significantly, I realized that we were giving away yet another organic process for convenience's sake. The crazy short immigration time meant that I had more time (read money) to spend at the Aelia Duty Free Stores!

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #04

Restricting my needless purchases to just chocolates and collectibles, I finally came to Gate B8, from where my Emirates EK0140 was going to be boarded. At around 0230pm Central European Summer Time, I had a Chicken Cheddar Panini Meal for lunch because I knew it would take a while before lunch was served during the flight. At around 0300pm Central European Summer Time, when the flight was finally starting to board, the Prague Airport (PRG) had another shocking surprise for me. Not only was my water bottle discarded - only for them to have a water vending automated machine on the other side of the checks - but I was also frisked physically after passing through the metal detectors without any buzzing concerns, and my purchases from their duty free airport stores were separately checked too.

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #05

Being a frequent traveller, I always made sure to remove my metal-hooked boots too to ensure that the security checks went through just fine, so believe me when I say - I was absolutely shocked when that actually happened. To add further insult to injury, their automated water vending machine was fancy enough to get my purchased water bottle stuck, with no one to help me with it. Not only was I forced to stay thirsty until I could board the flight, but there were also additional checks using German Shepherd sniffer dogs that everyone was subjected to. As you could imagine - I was super pissed at the overall situation, but I stayed calm regardless, as the last thing I wanted to do was spoil my mood further and worsen the ongoing affair - also not a choice note on which I wanted to end my Flock 2026 journey...

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #06

The flight finally took off, with us being seated in the flight after the final checks, at around 0400pm Central European Summer Time, and I decided to catch up on some respite. I knew that with the rush that I had to make in Dubai (DXB) during the short ninety-minute-long layover, I would be able to use some of the recovered energy. Unlike my arrival flight, which had almost eight hours of dreadful layover, I had a shorter one this time, which could have ended up being even more tricky if the transit buses were involved. After being served meals and finishing off the third season of Oshi No Ko (2023), I finally had some sleep on the six-hour-long flight. The fact that I had an empty seat between my window seat and the aisle seat also helped me avoid the overcrowded affairs in flying economy on longer flights.

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #07

At around 1230am Gulf Standard Time, I found the flight closing in on Dubai International Airport (DXB), and yet again, we were at an airport concourse - not an arrival gate. With the transit bus taking away almost thirty minutes for me to make it to the arrival gate, I was thankful that the security checks passed with zero hitches. The fact that I landed at different gates hurt as now I also had to give fifteen minutes on a transit train to travel closer to the Series A departure gates. Minus the peak rush, I had to sprint to the travelator escalator in Terminal 3 with my lightweight backpack to finally make it closer to my designated gates. At that defining moment, moving all the heavy things to the checked-in luggage felt like the right thing to do, and I was able to sprint on for a longer duration as a result.

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #08

The layover rush finally ended when I finally made it to Gate A12, where the boarding process had begun for Emirates EK0570. Even though I had roughly 15 minutes before the boarding gates eventually closed, it was way better to be there earlier. Plagued with the classical Gate Lice situation, I had to weave through the passenger crowd as my boarding group was called, being seated at the tail end of the Emirates flight. With nothing to make a rush for, I wanted to relax on the last leg of my struggling journey with the larger footspace and lesser stuffiness at the twin seats. While I was briefly requested by a fellow passenger to swap seats for one of the more cramped seating regions, I respectfully declined their request as not only did the seat cost more, but I also really needed some rest on this flight.

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #09

Awkwardly enough, they had run into some trouble with the Emirates staff due to their seat-swapping request attempts, as I was the second person that they asked to swap with. After clearing up the boarding confusion, we took off from Dubai International Airport (DXB) at around 0130pm Gulf Standard Time, and we were soon provided with the health reporting self-declaration by the flight helpers right after. While my co-passenger left that to be done later, I wanted to get this out of the way so that I could finally get some undisturbed rest. While drifting into sleep and enjoying some flight meals at the break of dawn, the flight was finally closing in on Netaji Subhash Chandra Bose International Airport (CCU), and after a lengthy deboarding, I was back on the ground in my hometown of Kolkata, India.

Departing From Flock To Fedora 2026
Departing From Flock To Fedora 2026

Manifest #10

Of course, I had to go through immigration here too - but as I had the health reporting self-declaration filled in advance, passing through with the immigration stamps on my passport was a breeze. While my fellow passengers struggled to find a writing surface at the arrival gates, I was glad that I did that even when I was just about to fall asleep on the Emirates flight. Right when I thought that my travel struggles were about to end, the luggage belt started its operation late at around 0830am Indian Standard Time, and I had to wait for almost an hour to obtain my checked-in luggage. Having not received an SMS notification, I also contemplated reaching out to the Emirates staff due to the abnormal duration, but not having to do that saved my return journey from getting any worse than it already had been.

From July 06 to July 12

Posted by Aurélien Bompard on 2026-07-12 20:45:00 UTC

Across the various Fedora teams, the primary focus is squarely on preparations for the upcoming Fedora 45 release, driven by the impending July 15th mass rebuild and critical change proposal deadlines. Concurrently, a massive, project-wide infrastructure migration is underway as multiple groups transition their repositories, issue trackers, and CI/CD pipelines away from legacy systems like Pagure.io toward Forgejo and GitLab. Security and system stability also remain top priorities, highlighted by the enforcement of mandatory 2FA for packagers, active patching of high-severity CVEs in groups like EPEL and Perl, and proposals to gate stable release updates on reverse dependency checkers (rmdepcheck). Finally, there is a strong, unified push to improve contributor onboarding and cross-team collaboration through standardized documentation, centralized Kanban boards, and the restructuring of community governance, such as the formalization of the new Atomic SIG and the proposed AI Working Group.

Announcements

The Fedora Council has paused the Community Initiatives process effective immediately, noting that the current framework has proven ineffective for surfacing new ideas. Consequently, the AI Developer Desktop proposal has been closed as an official initiative, though independent exploration and collaboration within the community are still highly encouraged. While existing approved initiatives (Fedora Forge, Atomic, and Docs 2026) will continue their scheduled terms, the Council is actively seeking community feedback on a proposed "sandbox" lifecycle process to better evaluate and champion future innovations in a more open, transparent way.

For Fedora 45 contributors, several critical deadlines are approaching to ensure a smooth release. The F45 Mass Rebuild is scheduled to begin on July 15, 2026; maintainers needing to exclude packages must add a noautobuild file to their dist-git repositories. Also due on July 15 is the keepalive deadline for Spins and Labs, requiring maintainers to acknowledge their tracking tickets and ensure packages are up to date to guarantee inclusion in the upcoming release. Finally, a list of long-term FTBFS (Fails To Build From Source) packages failing since F42 has been published; these will be retired around August 5 unless maintainers intervene to fix them or request an exemption from FESCo.

Council

The Council discussed the Draft Council Proposal for the Fedora Innovation Lifecycle (also tracked in Ticket #564), which aims to create a structured pathway for experimental features, though some members raised concerns about potential process overhead. In other community news, the Council is exploring Open Collective for external fundraising targeting the Fedora Linux 45 cycle, seeking to address moderator burnout by formalizing support and escalation pathways, and reviewing the Authorized Analytics Volunteer Agreement to safely manage community health data under GDPR. Additionally, a recap of the 2026 Strategy Summit was published, highlighting discussions on governance, engineering, and community initiatives, while a ticket regarding FESCo election voting rights was closed and deferred to FESCo.

On the infrastructure and legal side, updates were debated for the Fedora Forge usage policy regarding repository archiving, and AI agent context was merged into the Council Tickets tracker. Legal and trademark discussions continued regarding FedoraCVE.org, 3rd-party community sites, Red Hat's EU CRA Stewardship proposal, and confusing Weblate Terms & Conditions for translators, where it was affirmed that the Fedora Project Contributor Agreement takes precedence. Finally, the Council agreed to migrate the historical Fedora Budget repository and acknowledged the need to enhance Fedora's public-facing presence.

Decisions

  • Fedora Atomic Naming: The Council approved the use of the "Fedora Atomic" name for bootable container base images of Fedora.
  • Provenpackager Revocation Disclosure: The Council decided not to publicly disclose the confidential details or voting record of a past provenpackager revocation incident, opting instead to focus on improving the project's Conflict of Interest policy to prevent future governance issues.

Learn more about the Council team.

FESCo

This week, FESCo focused on reviewing upcoming Fedora 45 Change Proposals and refining packaging policies. Key community discussions centered around disabling DNF vendor changes by default, enabling Shadow Stack on x86_64, and adding Stratis storage support to Anaconda. During their weekly meeting, the committee postponed discussions on the Forgejo dist-git migration and the Engineering representative's responsibilities to gather more input. Furthermore, FESCo is seeking volunteers and feedback for an upcoming proposal to make 2FA mandatory for all packagers, following the recent enforcement and grace period announcement of 2FA for provenpackagers.

Decisions

  • Cryptography Libraries: Dropped the signoff requirement from the defunct "Fedora crypto team" for new cryptography libraries. FESCo will act as the gatekeeper until a new public review process is established.
  • ELN Draft Builds: Permitted the ELNBuildSync (EBS) service to use and promote draft builds in Koji side-tags inherited from eln-build for ELN rebuild batches.
  • Non-responsive Maintainer: Approved adding ankursinha and jflory7 as additional admins to the ledger package.
  • Change: Lazarus with multiple widgetsets: Approved the proposal to offer the Lazarus IDE built with multiple widgetsets.
  • Change: LLVM 23: Approved the system-wide update of all LLVM sub-projects to version 23.
  • Change: Grub EFI For Confidential Computing: Approved the introduction of an independent, minimal GRUB bootloader package for UEFI to quickly boot Unified Kernel Images (UKI).

Learn more about the FESCo team.

Mindshare

During the Mindshare Committee meeting, members highlighted the impending shutdown of Pagure.io at the end of the month, urging contributors to migrate any remaining repositories to avoid disruptions. The committee also reviewed a funding request for All Things Open 2026, noting a need for more local community engagement and outreach to staff the event before approving the budget. Meanwhile, on the forums, the Polish Fedora community discussed their upcoming infrastructure migration and confirmed that their continued use of Fedora domains and logos complies with the project's Community Sites and Accounts trademark guidelines.

Decisions

  • Assigned new term owners for the committee's charter areas: @theprogram will lead Regional Event Support, @t0xic0der will lead Digital Ambassadorship, and @jnsamyak will lead the Recognition Service.
  • Decided to hold an asynchronous ticket vote to select the Fedora Council Representative, with @t0xic0der and @jnsamyak running as candidates.
  • Deferred the budget vote for All Things Open 2026 pending further outreach to identify and include more local attendees.

Learn more about the Mindshare team.

Diversity & Inclusion

During their weekly meeting, the DEI team reviewed early survey feedback from the 2026 Fedora Mentor Summit, noting that the topic-based mentor lunches were highly praised, though ambient noise levels were a concern to address for next year. In infrastructure news, the team successfully completed their migration to Forgejo and is currently updating their issue templates to match the new platform. The team also concluded a discussion regarding age verification legislation, deciding that any official project-wide stance falls under the purview of the Fedora Council rather than the DEI team.

Planning is officially underway for the 2026 Fedora Week of Diversity, which is targeted for October. The team is organizing a 2-3 hour virtual event featuring short 10-20 minute talks and is currently brainstorming an overarching theme, with "Respect the Culture" as an initial proposal. There are immediate opportunities for contributors to get involved with the event by volunteering for speaker management, event logistics, content marketing, and design roles.

Decisions

Learn more about the Diversity & Inclusion team.

Workstation / GNOME

This week, the Workstation Working Group focused heavily on desktop stability and upcoming upstream improvements during their July 7 meeting. Key technical discussions highlighted the need for better GNOME Shell reliability during power management events and GPU resets, particularly on AMD and hybrid graphics systems. The group also debated desktop crashes caused by inotify instance exhaustion—likely tied to web process leaks in Epiphany—and plans to consult the Linux UAPI Group for a resolution. On the feature side, GNOME Shell is adopting SVG cursor support to eliminate blurry pointers on high-resolution displays, and progress continues on integrating voice control (Anthony) with IBus.

In the community forums, a user started a discussion regarding the new in-kernel NTFS driver (NTFSPLUS) merged in Linux 7.1. The user noted that the driver is currently disabled in Fedora's kernel configuration and inquired if there are plans to enable it as a module or by default, replacing the existing ntfs-3g symlink.

Decisions

  • The Working Group agreed to consult the Linux Userspace API (UAPI) Group to help resolve the ongoing inotify resource management issues.
  • Matthias Clasen will engage with the upstream release team to monitor new package dependencies and will advocate for rearchitecting Mutter to better survive GPU resets.
  • Due to member unavailability during the first half of August, the group decided to adjust the schedule for upcoming meetings.

Learn more about the Workstation / GNOME team.

KDE

The rollout of KDE Apps (Gear) 26.04 on Fedora 43 appears to have successfully reached users. Previously, this update was blocked because it required a newer version of the gpgme package (2.0+), which would have introduced a soname bump that conflicts with Fedora's stable release update policies. Recent user feedback confirms that a workaround or solution has been implemented, and the KDE Gear 26.04 update is now actively landing on Fedora 43 systems.

Learn more about the KDE team.

Server

In their July 8th meeting, the Server Working Group focused on streamlining Fedora 45 release testing and expanding server documentation. The team reviewed ongoing pull requests for DNSmasq and PXE boot configuration, noting successful validation for UEFI clients while continuing to troubleshoot legacy BIOS network loading issues. Additionally, the group discussed the initial steps for organizing Kiwi development for the upcoming Fedora home server spin-off, identifying the need for a comprehensive development environment setup guide, and shared various homelab storage use cases involving NFS, Samba, and Syncthing.

To improve community engagement in quality assurance, the group is overhauling its testing tracking by moving to a Kanban-style project board on the Fedora Forge. This new system will feature individual tickets for specific tests, making it significantly easier for community contributors to pick up testing tasks, run them in local virtual machines, and report results for each new Rawhide build.

Decisions

  • For release testing, the group will create one ticket per test on a project board, including the build date in the title. Tests will start in a "To Do" column and move to either "Passed" or "Failed." Upon a new build release, the ticket titles will be updated and moved back to "To Do."

Learn more about the Server team.

Infrastructure

The Infrastructure team is preparing for the Fedora 45 mass rebuild starting July 15, which includes enabling autosigning for the f45-rebuild tag. On the monitoring and operations front, the team successfully removed legacy Nagios and collectd systems, fully transitioning to Zabbix, and refined COPR Zabbix warnings to reduce alert fatigue. Hardware maintenance is ongoing, with several RHEL10 virthosts being reinstalled with minimal downtime. Additionally, recent Koji server timeouts caused by wiki scrapers overloading proxies were identified and resolved.

In development news, major progress was made on Private Issues functionality for Forgejo, and CI infrastructure was expanded with new Forgejo Actions runners. To improve code quality, the team merged a pull request to restore pre-commit hooks in the infra/ansible repository, pinning them to hashes and introducing an .ansible-lint-ignore file to allow for gradual compliance. Furthermore, discussions are underway regarding Datanommer PostgreSQL operations, specifically exploring a migration to Kubernetes using CloudNativePG and upgrading to Timescale/PG18.

Decisions

  • Squash commits were enabled for the infra/ansible repository.
  • The OpenQA memory alert threshold in Zabbix was increased to 95% to reduce unnecessary notifications during heavy loads.
  • The copr/certbot role was officially moved to the main ansible/roles directory.
  • The openshift-apps playbooks are actively being converted to use the app-actions role, with a significant batch of playbooks successfully migrated and merged this week.

Learn more about the Infrastructure team.

Release Engineering

This week, Release Engineering focused heavily on preparations for the upcoming Fedora 45 cycle, with the F45 Mass Rebuild scheduled for July 15th and the creation of F47 release signing keys underway. Significant infrastructure improvements are also in progress, including the successful production migration of the fedora-scm-requests repository to Forgejo and the ongoing integration of Konflux CI with Fedora's Forgejo using a newly established global bot account. Additionally, Koji tags were configured to allow image-builder to build for ELN, and a script issue preventing the creation of detached signatures for the butane release was resolved.

Contributors should be aware that the web-based git blame feature in Fedora Package Sources has been disabled to mitigate abuse from AI scrapers; users are advised to clone repositories and use git blame locally instead. Maintainers receiving orphaned package warnings for oxygen-icon-theme dependencies can safely ignore them, as this is a known false positive stemming from its migration to kf6-oxygen-icons and will not result in auto-retirement. Finally, multiple packages were unretired, and stalled EPEL requests were processed to keep community packages moving forward.

Decisions

  • Fedora 45 Spins: The Robotics Spin will be dropped starting with the Fedora Linux 45 release.
  • Koji Policies: Following FESCo approval, the Koji hub policy was updated to allow draft builds for ELN within specific eln-build-side* tags to improve the reliability of ELN rebuild batches.
  • Infrastructure Security: Web-based git blame endpoints in dist-git are intentionally blocked due to massive crawler abuse.
  • Konflux CI Integration: The team decided to use a global konflux-bot token via Pipelines-as-Code global repository settings rather than distributing secrets to individual tenant namespaces, improving security and simplifying operations.

Learn more about the Release Engineering team.

Quality

The Quality team successfully concluded the Kernel 7.1 test week and is currently reviewing the Fedora 45 change list to plan upcoming test days for major transitions like RPM 6.1, GNOME 51 Alpha, and Stratis Anaconda support. There are several new opportunities for community testing and feedback, including a newly developed GTK4 frontend for DNF5 and a secure automated build workflow for pre-built NVIDIA kernel modules. Furthermore, contributors can now show off their team affiliation using the new Quality group on Discourse, which syncs with FAS and provides a custom bug flair for user profiles.

In testing infrastructure and policy, a major proposal was introduced to gate all stable release updates on rmdepcheck, a reverse dependency static checker designed to prevent updates from breaking dependencies in Fedora and EPEL. Tooling continues to improve, with the openQA dist-git PR test feature nearing production and new event banner features merged into testdays-web. Internally, the team is also discussing process refinements, including experimenting with four-week sprints and maintaining a curated board of accessible issues for new contributors.

Learn more about the Quality team.

Design

The Fedora Design team has finalized the F45 wallpaper and officially launched the Fedora 46 Wallpaper Epic. The F46 design will be inspired by a famous STEM figure whose last name begins with "U," with a community inspiration vote and mindmap session scheduled for July and August. Alongside release artwork, the team is actively developing branding for several community projects, including a lobster mascot for the LoLa AI Package Manager, a logo for the Testing Farm's Artemis provisioning service, and a Mobility SIG logo for the Phosh Tour.

There are several excellent opportunities for community engagement this week. Anyone in the Fedora community is welcome to contribute to the F46 Wallpaper sketches and drafts phase. Additionally, designers can jump into fun, low-pressure tasks like creating an avatar for the Matrix Moderation Bot or helping to illustrate Community Personas that will visually represent the diverse types of Fedora contributors.

Decisions

  • The Fedora 46 Wallpaper will be inspired by a famous STEM figure whose last name begins with "U".
  • The Community Personas project was converted into a larger Epic to be properly scoped and broken down into smaller tickets during the upcoming sprint.
  • The upstream fedora-logos repository will be adopted and moved off pagure.io into the Fedora Design Team space to ensure it is maintained.

Learn more about the Design team.

Docs

This week, the Fedora Docs team focused heavily on structural improvements and cross-team collaboration. A major initiative was proposed to unify Fedora Multimedia Documentation, aiming to consolidate scattered guides on third-party codecs and hardware drivers into a single authoritative source to improve the user experience. To support this and other cross-team efforts, the team is organizing a "Fedora Docs Captain" pilot program with the Kernel, Multimedia, and AI/ML groups to decentralize documentation leadership and pair subject-matter experts with Docs team sponsors. Additionally, efforts to improve contributor engagement are underway, including welcoming a new volunteer writer and restructuring the contributor guides (and its introductory article) into a dedicated, highly visible module on the landing page.

Behind the scenes, several repository alignment tasks were completed to streamline workflows and avoid confusion for existing contributors. The team successfully finalized a standardized issue labeling system and common README format across the organization. Furthermore, all project boards were migrated from individual repositories to the organization level to provide a better overview of ongoing work.

Decisions

  • Project Boards: All project boards have been successfully migrated to the organization level, and per-repository boards should no longer be used (Ticket #48).
  • Issue Labels: A simplified, standardized set of issue labels (categorized by type, effort, priority, and status) has been finalized and deployed across all repositories within the docs organization (Ticket #40).
  • Repository READMEs: A common README format has been approved and successfully implemented across key documentation repositories (Ticket #36).
  • Repository Alignment: The overarching repository alignment tracker was closed, with any remaining incomplete subtasks now being tracked in their own dedicated issues (Ticket #18).

Learn more about the Docs team.

Internationalization

During the Internationalization meeting, the team discussed upcoming changes for Fedora 45, highlighting that an initial draft for the LibreOffice Dictionaries change has been submitted. Contributors are encouraged to propose any additional Self-Contained Changes before the July 21st deadline. The group also reviewed the upcoming release schedule, noting the major toolchain updates deadline on July 13th and the mass rebuild starting on July 15th.

To help with ongoing maintenance, a call to action was issued for Fedora 43 bug triaging. Contributors are asked to engage by reviewing the 45 remaining bugs reported against Fedora 43 to either fix them or move them to a later release.

Learn more about the Internationalization team.

EPEL

This week, the EPEL community evaluated a proposal to gate all stable release updates on rmdepcheck, a reverse dependency static checker designed to prevent updates from breaking package installability. While the initiative is generally supported to ensure stability, mailing list discussions highlighted concerns regarding transient CI network failures and the potential burden of fixing dependent packages maintained by unresponsive contributors. Additionally, maintainers are coordinating major incompatible updates to resolve severe CVEs. This includes a planned upgrade of ffmpeg in EPEL 9—which will first receive a 5.1.10 patch before transitioning to version 7.1.5 via epel9-next—and an update to rust-routinator 0.15.2 that removes a vulnerable, off-by-default feature.

Decisions

During the weekly meeting, the steering committee voted to approve a documentation pull request clarifying the policy against building packages against non-default modules. The committee also initiated asynchronous in-ticket voting for the ffmpeg and rust-routinator incompatible update requests to prevent blocking contributors from moving forward.

Learn more about the EPEL team.

ELN

The ELN SIG met on July 7 to discuss significant infrastructure and tooling upgrades. Notably, ELNBuildSync 1.3.2 has successfully migrated from CentOS Stream hosting to Fedora Infrastructure, and FESCo has approved draft build support in EBS, which is currently being prepared for deployment. The Content Resolver has also been ported to dnf5 by new contributor James Troy, cutting run times in half (from 6-7 hours down to 2-3). Additionally, the team is finalizing bootc images and coordinating with release engineering to ensure they are properly synced to Fedora's Quay registry.

To align ELN with RHEL 11 expectations, the SIG is preparing to migrate several image types to use image-builder in the pungi configurations, starting with qcow2 guest images and modernizing the boot.iso. Contributors should prepare for the upcoming Fedora 45 mass-rebuild, which will trigger a flurry of activity to fix build failures. There are also immediate opportunities for contributors to help resolve the remaining ~17 failures and OpenSSL 4.0 porting issues from the recent ELN mass rebuild.

Decisions

  • Transition ELN non-cloud images (starting with qcow2 and boot.iso) to image-builder to lead RHEL 11 development, with cloud images to follow pending coordination.
  • Publish bootc images to a dedicated quay.io/fedora/eln-bootc repository rather than grouping them with other containers.
  • Delay the production deployment of Koji draft build support in EBS until after upcoming maintainer PTO to ensure stability.

Learn more about the ELN team.

Atomic

During their weekly meeting, the Fedora Atomic Initiative discussed ongoing efforts to migrate the fedora-bootc repository to the unified pipeline. While organizational access on the forge is ready, the team must implement a workaround for the Konflux service account token by creating a dedicated FAS account for repository owners to properly restrict namespace access. Contributors also briefly discussed the future of boot media, noting a shared desire for a neutral Anaconda GUI installer capable of pointing to any bootc registry. In the forums, community interest continues to grow around the proposal to create a systemd-sysexts SIG, which aims to build and distribute systemd system-extensions for atomic systems.

Decisions

  • Following the Fedora Council's approval of the "Atomic" name, the group officially agreed to formalize the Atomic SIG.
  • The team will set up a wiki page for the new SIG and request a dedicated Fedora calendar so contributors can subscribe specifically to Atomic meetings without inheriting events from all other Fedora SIGs.

Learn more about the Atomic team.

CoreOS

During the CoreOS meeting, the team reviewed the upcoming Fedora 45 release schedule, noting the mass rebuild on July 15 and the change proposal deadline on July 21. Contributors discussed submitting official change requests for Ignition Native Butane Support and the Ignition submodule split to increase visibility across the broader Linux community. The team also evaluated enabling UEFI boot and TPM support on AWS. Because requiring TPM would drop support for legacy instance types, they opted to defer TPM enforcement to future unified kernel image (UKI) releases to avoid disrupting existing users.

In community discussions, interest continues to grow around the proposal to create a systemd-sysexts SIG. This Special Interest Group aims to build and distribute systemd system-extensions using Fedora content, providing a new way to extend atomic systems with software that doesn't run well in containers or Flatpaks. Contributors interested in helping set up official builds (likely in Konflux), documentation, and distribution methods are encouraged to join the effort.

Decisions

  • The team agreed not to enable TPM support on current Fedora CoreOS AWS AMIs to avoid breaking compatibility with legacy instance types. Instead, TPM support will be applied exclusively to the sealed/UKI images once they are ready.

Learn more about the CoreOS team.

Alternative Images

During the Alternative Images meeting, the project's migration from Pagure to GitLab was reported as complete for both the website and image building. A remaining task—and an opportunity for contributors—is to retire the old Pagure repositories or update their README files to point to the new locations. In broader news relevant to the Linux community, CentOS Stream 9 and 10 are rolling out new Secure Boot certificates and shims. The quarterly image builds were paused to wait for final package updates (such as fwupd for CentOS Stream 9) and will commence next week.

Additionally, CentOS Stream RISC-V repositories are now built, signed, and ready. The team is currently waiting on a CentOS infrastructure ticket to create the necessary targets and tags before they can begin generating the RISC-V images.

Decisions

  • The quarterly image builds were scheduled for next week to ensure all new Secure Boot certificates and updated packages are fully integrated.
  • The initial RISC-V rollout will consist of two specific images: a generic qcow2 image meant for virtual machines and a raw image designed for P550 hardware.

Learn more about the Alternative Images team.

AI & ML

This week, the AI & ML group announced that pre-built binary NVIDIA open kernel modules are now available for community testing outside of the AI Desktop Remix. On the organizational front, the group is heavily focused on improving contributor onboarding and defining its community structure. Active discussions include evolving the SIG into the "Fedora AI Working Group" to reflect a broader scope encompassing both hardware enablement and open AI best practices, creating a welcoming first-page navigation experience, and establishing a formal "Skills Reviewers" sub-team to curate shared AI skills.

To avoid conflating general community participation with hardware privileges, a proposal is underway to scope gpu01 host access exclusively to the ai-packagers-sig while keeping the main ai-ml-sig open to all interested users. This infrastructure management theme is also reflected in ongoing efforts to clean up GitLab group mappings.

Decisions

Learn more about the AI & ML team.

RISC-V

The RISC-V group is currently progressing through the F45 rebuild, which is approximately 20% complete, and preparing for the upcoming F46 mass rebuild expected around July 15. On the infrastructure side, Jason Montleon successfully consolidated the RISC-V kernel repositories, moving builds from GitHub to Copr and integrating 'omni' kernels directly into the RISC-V Koji. Additionally, a proposal has been drafted regarding migrating the RISC-V documentation from the Wiki to Forge, presenting a great opportunity for community feedback and contributor engagement.

During the July 7th meeting, the team highlighted ongoing hardware developments, notably the active investigation of virtualization on RVA23 hardware (SpacemiT K3) alongside upstream QEMU and kernel developers. While there are known issues currently being documented for upstream resolution, hardware capacity is expanding, with a new K3 unit en route to serve as an additional Koji builder. Contributors should also note that general group activity is expected to slow down through July and August due to summer holidays.

Learn more about the RISC-V team.

Security

During the Security SIG meeting (agenda outlined in the forum discussion), the team focused on establishing official Fedora representation on the linux-distros mailing list to better coordinate embargoed CVEs. To support this, the group will draft a formal policy for reading members into embargoed issues to present to FESCo. The SIG also discussed the organization of security documentation, concluding that upcoming systemd and SELinux hardening guides will be published in Fedora's Quick Docs to ensure optimal search engine visibility for end users.

Discussions regarding the Cyber Resilience Act (CRA) and the formulation of a "Vulnerability and Incident Response Policy" were deferred to the next meeting due to time constraints. Contributors interested in shaping Fedora's security policies, managing vulnerability responses, or writing technical security documentation are highly encouraged to join the upcoming meetings and assist with these foundational efforts.

Decisions

  • Bugzilla will be used to manage private tickets for linux-distros issues until the new Forge platform fully supports private issues.
  • The SIG will draft a formal policy for handling embargoed security information and present it to FESCo for feedback and approval.
  • Initial security hardening documentation will be placed in Quick Docs rather than the Security SIG team pages to improve discoverability.

Learn more about the Security team.

Perl

This week's activity in the Perl group focused entirely on package maintenance and security updates. The most critical update for the broader Linux community was the version bump of perl-DBI to 1.650 across multiple branches (PRs 3, 4, and 5), which successfully patched three security vulnerabilities: CVE-2026-14739, CVE-2026-14740, and CVE-2026-14380.

Other routine maintenance included version bumps for perl-WWW-Salesforce to 0.400 and perl-Razor-Agent to 2.88. For contributors managing database dependencies, a pull request for perl-Test-mysqld was merged to utilize -any virtual provides for MariaDB and MySQL, which should streamline future package builds and dependency resolution without causing disruptive surprises.

Decisions

  • Security Patches: The group approved and merged updates for perl-DBI to version 1.650 to resolve CVE-2026-14739, CVE-2026-14740, and CVE-2026-14380.
  • Dependency Management: The group decided to implement -any virtual provides for MariaDB/MySQL dependencies in perl-Test-mysqld.
  • Package Updates: Version bump pull requests were approved and merged for perl-WWW-Salesforce (0.400) and perl-Razor-Agent (2.88).

Learn more about the Perl team.

Python

Elliott Sales de Andrade initiated a discussion on updating Zarr to v3, noting that the current v2 build fails to build from source (FTFBS) on Python 3.15. While an initial mass prebuild attempt a year and a half ago encountered several failures, those underlying issues have since been resolved or the affected packages have been retired.

To successfully move forward with the Zarr v3 update, contributor assistance is currently needed to review the python-donfig package.

Learn more about the Python team.

Other Discussions

  • How can we improve the Changes Process?: Discussion continued on improving the Fedora Changes process. Maxwell G summarized the feedback, noting support for both a git-based approach and the current wiki workflow, while highlighting the pain points of split discussions across devel@, Discourse, and other platforms. He proposed focusing first on the discussion process, suggesting keeping initial feedback on the devel list and posting read-only digests to Discourse, and asked for co-owners for a formal FESCo proposal on this matter.
  • F45 Change Proposal: Enable Shadow Stack by Default on x86_64 (system-wide): Aoife Moloney announced a proposed change for Fedora 45 to enable Shadow Stack protection by default on supported x86_64 machines for applications built with gcc, clang, and rustc. Christoph Erhardt clarified that this protection applies to all binaries carrying the SHSTK note, regardless of the programming language they were written in.
  • Proposal: gate all stable release updates on rmdepcheck: Adam Williamson proposed gating all stable release updates (Fedora and EPEL) on the rmdepcheck reverse dependency static checker to prevent updates that cause unsatisfiable dependencies. The proposal received strong support, with discussions on whether to extend this to Rawhide and Branched, how to handle waivers, and the technical implementation details, leading to a consensus to submit a lightweight FESCo ticket for approval.
  • Packages providing Flatpak sandbox escapes via vulnerable MIME Type Handler: Sebastian Wick raised concerns about packages like wine providing Flatpak applications a way to escape sandboxes via vulnerable MIME type handlers that execute arbitrary code. The discussion explored the root causes, the responsibilities of different projects (Flatpak, Wine, Freedesktop), and potential solutions, with Michael Cronenworth agreeing to drop the .desktop file registration in favor of the binfmt-misc handler in the core wine RPM to mitigate the issue in Fedora.
  • F45 Change Proposal: Disable Vendor Change by Default (system-wide): Aoife Moloney announced a Fedora 45 change proposal to disable automatic vendor changes in DNF5 by default, preventing packages from silently switching vendors during transactions. The discussion highlighted that while some users prefer the current behavior for testing third-party repos like Copr, the change provides better consistency and safety, especially for derivatives like Fedora Asahi Remix, and still allows explicit vendor changes via command-line options.
  • Looking for zig co-maintainer for Fedora and EPEL: Jan Drögehoff sought a co-maintainer for the zig package, especially for EPEL, and Marko Kostic volunteered to help. After some initial issues with FAS account synchronization, Marko was successfully added as a co-maintainer, and Rénich Bon Ćirić also joined to assist.
  • Help needed with matrix-synapse: Kevin Fenzi bumped an older thread asking for help with maintaining matrix-synapse, inquiring if there had been any progress on getting Synapse's latest version to build on F44 and below.
  • Spins and Labs Keepalive Deadline: 2026-07-15: Aoife Moloney reminded maintainers of Fedora spins and labs to acknowledge their Pagure tickets by July 15, 2026, to confirm their inclusion in Fedora 45. Dan requested and received a ticket for the Cinnamon spin.
  • review request - dupeguru - a GUI tool to find duplicate files: Carl Byington submitted a review request for dupeguru, a Python/Qt5 GUI tool for finding duplicate files. Barry asked about Qt6 support, and Carl noted an outstanding upstream pull request for the conversion.
  • Looking for a new maintainer for Phoc and Phosh DE packages: Tomi Lähteenmäki sought new maintainers for several Phoc and Phosh packages due to a lack of time. Sam Day volunteered to take over as the primary maintainer for phoc, phosh, phosh-mobile-settings, phosh-tour, and stevia.
  • Other discussions included a list of new packages in Fedora Linux, an issue with GCC plugins packaging for AFL++, troubleshooting s390x cloud images hanging on libvirt/qemu, an F45 Change Proposal to adopt PURL Metadata, the Fedora 45 Mass Rebuild Notification, a request for a sponsor for the sckoc package, a request to unretire sugar packages, and the announcement of the Koji 1.36.1 release.

Orphaning packages

  • EPEL SIG should clean up their own mess: Leigh Scott expressed frustration over being expected to maintain the EPEL Cinnamon stack, stating it wasn't his responsibility and giving notice to orphan and retire the entire stack. This led to a discussion about appropriate communication and the structural issues with Bugzilla assignments for EPEL packages.
  • Orphaning hexchat: Kevin Fenzi announced plans to orphan the hexchat package, suggesting it be retired since upstream was archived in 2024 and it currently fails to build in Rawhide. He recommended users switch to zoitechat, a GTK3 drop-in replacement that recently entered Fedora.
  • List of long term FTBFS packages to be retired in August: Miro Hrončok posted the second weekly reminder listing long-term FTBFS (Fails To Build From Source) packages scheduled to be retired from Fedora 45 on August 5, 2026. Dominik 'Rathann' Mierzejewski requested a PR to add mingw subpackages to the gsm package to resolve a dependency issue.

Package updates

  • Protobuf update: Petr Menšík provided an update on the Protobuf rebase, noting that he prepared updates for the protobuf-c and protobuf3-c libraries, ensuring compatibility and creating a COPR repository for testing.
  • [heads-up] mutter and gnome-desktop3/4 soname version bump for rawhide: Milan Crha coordinated rebuilds for packages affected by the mutter and gnome-desktop3/4 soname version bumps in the GNOME 51.alpha updates. Sam Day assisted by rebuilding phoc, phosh, phosh-mobile-settings, and stevia in the side tag, allowing the update to be successfully pushed to Rawhide.
  • libical 4.0 for rawhide (when?): Milan Crha provided an update on the transition to libical 4.0 in Rawhide, listing packages that build successfully, those with available patches, and those with generic build failures. Mamoru TASAKA backported a PR for cairo-dock-plug-ins to assist with the transition.
  • [heads-up] gvfs dropped 'archive' and 'afp' in 1.61.1 (rawhide): Milan Crha notified maintainers that gvfs dropped 'archive' and 'afp' support in version 1.61.1, causing build failures for packages like nemo. Leigh Scott quickly rebuilt nemo in the side tag to resolve the issue.
  • OCaml 5.5.0 rebuilds: Jerry James announced and completed a mass rebuild of OCaml packages for the update to OCaml 5.5.0 in a side tag, which was subsequently merged into Rawhide.
  • RFC: incompatible update for routinator for Fedora and EPEL 9 and 10: Michel Lind issued an RFC for an incompatible update to routinator (version 0.15.2) for Fedora and EPEL to address multiple high-severity CVEs and a path traversal vulnerability. He disabled automatic pushes and submitted a FESCo request for approval.
  • Sequoia-PGP updates with PQC support: Fabio Valentini announced updates to sequoia-pgp applications and libraries that include support for Post-Quantum Cryptography (PQC) algorithms following the ratification of RFC 9980.
  • gnome-shell 51.alpha update for rawhide changes gnome-shell api to 51: Milan Crha notified maintainers that the gnome-shell 51.alpha update changes the API to 51, requiring updates for several GNOME shell extensions.
  • [Scitech]LabPlot rebuild for liborigin update: Alexander Ploumistos requested rebuilds of LabPlot for F43, F44, and F45 following the release of liborigin 3.0.4, and confirmed the removal of obsolete transition tags from version 2.0.0.

New contributor introductions

  • Ikar's introduction: Ikar introduced themselves as a software engineer and long-time Linux user looking to contribute around 5 hours a week to Fedora.
  • Mohab Soliman's introduction: Mohab Soliman, a mechatronics engineer from Egypt, introduced themselves and expressed interest in contributing to Fedora's engineering and gaming parts.
  • Raul Perez' introduction: Raul Perez, a software engineer from Spain, introduced himself and shared his extensive background with Linux and open source, expressing a desire to start with small contributions to Fedora.

Day Three - Flock To Fedora 2026

Posted by Akashdeep Dhar on 2026-07-11 18:30:22 UTC
Day Three - Flock To Fedora 2026

I found the sunrays hitting my face at around 0430am Central European Summer Time on 16th June 2026, as I forgot to put the curtains on the night before. Being in the Northern Hemisphere, the cities of Czech Republic enjoyed longer durations of sunlight as compared to us living near the equatorial line. Even though I woke up a couple of hours before my scheduled alarm, I could state that I was gradually getting used to the time zone shift and the hotel bedding. As there were only two planned involvements for me on that day, i.e. Fedora Mindshare Townhall Session and Fedora Mentor Summit 2026 Contributor Recognition Awards Programme, I decided to have myself assigned to the registration duty for the first part of the day to ensure that I was able to be of assistance for however long I was present there.

Day Three - Flock To Fedora 2026
Manifest #01

After having a (slightly better) breakfast meal with Tomáš Hrčka and Cristian Le at around 0700am Central European Summer Time, Tomáš left early for a morning walk while Cristian and I decided to leave for the event venue a little while later. I got to know from him that he was planning on leaving for Brno that evening after the conference finished as we made it to Orea Hotel Andel Prague. Moving up from my designated slot with Michal Konecny, Cristian and I hung out at the front desk of the event. While we were not expecting many registrations at the tail end of the conference, we also had to be there as a source of information. I was also reached out to by Rajan Shah on WhatsApp, who was planning on visiting a Flock event for the first time before travelling on to attend DevConf.CZ 2026 in Brno.

Day Three - Flock To Fedora 2026
Manifest #02

Putting my work laptop on charge there and helping Cristian with a power bank, I saw Jennifer Schimmoller and Dorka Volavkova arriving at the registration desk. While helping Dorka bring the sweets from the International Candy Swap event to the main table, Jennifer swiftly onboarded me to the (very intuitive) Pretalx ticket scanning application. It was interesting to see just how the ecosystem application also provided the metadata information about what size of tee shirts I was tasked to offer to the attendees, thus lowering the entry barrier towards volunteering in conferences by quite a lot. We also faced a couple of exceptional cases there, with attendees requesting tee shirt switches due to incorrect sizes and incorrect status, both of which were handled by us volunteers present at the registration desk.

Day Three - Flock To Fedora 2026
Manifest #03

Even though we were almost certain that there would not be a lot of new check-ins on the third day, Jennifer still advised me to request folks who were seeking more tee shirts to return at around 0300pm Central European Summer Time. It would allow us to hand over the last ones to the longtime Fedora contributors for their (potentially possible) forward distribution in their respective regions. Placing the badge card ahead also got Maxwell G to reach out to me as the Fedora Badges service administrator, as the social event badge achievement had expired by then. While I did award him the badge achievement manually, I reactivated the specific invitation so that it would expire that midnight, as manually awarding those to almost hundreds of people after the event's end would not be a scalable solution.

Day Three - Flock To Fedora 2026
Manifest #04

At around 0900am Central European Summer Time, I met up with Jeremy Cline and Brian Exelbierd at the registration desk. Just like a lot of my Fedora Project friends, it was great to meet up with them after over a year since our previous chat during Flock To Fedora 2025. Amidst our discussions on our interactions with agentic tooling for software development and our frustrations related to business travel policies, I was surprised (read horrified) to notice that Brian (of all people) had somehow begun preparing slides for his presentations. While he was more than capable of "winging" the talk – an impressive quality that he had more than exhibited in the Fedora Project and at Red Hat for years – it was interesting to see how veterans like him also sought practice for the stage talk, every now and then.

Day Three - Flock To Fedora 2026
Manifest #05

The three of us also debated the use of agentic technologies among (mostly newer) engineers. I stated that the immediate utilization of generative tooling by incoming developers was much akin to young students' direct usage of calculators without ever starting by calculating on their fingers. He disagreed with the notion, stating that it does not matter whether a cook knew about the internals of a microwave oven or not, as long as they knew how to use it. We both eventually agreed on it being important for human developers to know what they wanted for them to be able to get there. Upon being joined by Jaroslav Řezník, I left for Kevin Fenzi's infrastructure presentation at around 1000am Central European Summer Time, while working with Jona Azizaj on the planned event of Fedora Mentor Summit.

Day Three - Flock To Fedora 2026
Manifest #06

She had to scrap the work done by Eduardo Javier Echeverria Alvarado on the slide deck to create a new one during the previous night. Through a brief spat with Michel Lind on the eligibility for obtaining the social event badge achievements, I took the feedback of potentially introducing newer ones that could also be received by our remote attendees. After another chat with Michael Scherer in the Sapphire room, we moved into the Topaz + Quartz shared room to attend the next couple of talks on Fedora Accessibility Test Days and Accelerating Microsoft Contributions To Fedora Project at around 1130am Central European Summer Time. Finishing up a chat with Artur Frenszek-Iwicki and Cristian, I finally met Rajan, whom I also invited to join us at the Fedora Mentor Summit 2026's Lunch And Learn Activity.

Day Three - Flock To Fedora 2026
Manifest #07

Offering the Forgejo Project's peel view for reviewing artwork asset differences during Emma's interactive presentation on Open Source Design Considerations, it was finally time for the lunch break at around 0100pm Central European Summer Time. With how Rajan had been leading DevConf.IN for the last couple of years, I knew that he was a reliable ally for the Fedora Project whenever we wanted to bring the community presence to India. Maybe we could have the next iteration in India? We never knew what the future had in store, but we did our best to make the most of Flock 2026's last day. After sharing lunch with him, Ankur Sinha and Michael, I was briefly pulled aside by Aoife Moloney for some schedule changes.

Day Three - Flock To Fedora 2026
Manifest #08

She wanted to reduce the effective duration of the Fedora Mindshare Townhall Session by about fifteen minutes to squeeze in all the lightning talks. I was split on this as this was Fedora Mindshare's visible presence after many years, I also knew that fifteen more minutes would allow all the lightning talks to be covered. Being the session chair, I conditioned my approval by asking her to be highly strict with answering times so that we were able to keep the session as interactive as possible. After all, the Townhall Session was planned to be a pathway towards the intricate conversations after the event's proceedings. Being a means for folks to know more about the committee's charter after the recent election, I wanted for it to empower to organize more localized events and encourage ways to recognize contributions.

Day Three - Flock To Fedora 2026
Manifest #09

Finally, being seated at the Plenary Hall for the Lightning Talks at around 0200pm Central European Summer Time, I discovered that all the speakers did a great job of finishing their planned content on time. As I had a slide deck to present during the Fedora Mindshare Townhall Session, I was extremely grateful when we ended up getting Ankur's laptop to present from. From the previous charter, only Emma and I were present there, while Matthew Holmes represented the incoming one on the stage. Helping set up the seats myself, we started off with a round of charter introductions before elaborating further on the progress made by the team during the previous term. As the Mindshare Representative to Fedora Council, I have had a statistical approach towards observing both our progress and our learnings.

Day Three - Flock To Fedora 2026
Manifest #10

The interactive session went well, with us taking feedback on what we could build on from Peter Boy's and Jef Spaleta's questions. Finishing this session at around 0315pm Central European Summer Time, I had a chat with Vít Smolík and Jonáš Hubený, who reflected on the rarity of the Stroopwafel achievement. Shockingly enough, not only did we have Justin Wheeler at the stage and Kevin seated in the front rows, but we were also joined by Adam Williamson – the three of whom were amazing (read crazy) enough to make the top cut. It was also impressive to see just how successful Vít had become in his contributions to the Fedora Project in a short period. At around 0400pm Central European Summer Time, we finally kicked off the Fedora Mentor Summit 2026 Contribution Recognition Awards Programme.

Day Three - Flock To Fedora 2026
Manifest #11

With Jona kicking off the final session by marking the 2026 iteration as the fifth iteration of the Fedora Mentor Summit's proceedings, I took over soon after to explain how the process worked in the background. We were also grateful to Benson Muite, Cornelius Emase and the Nairobi GNU/Linux User Group, who got us laser-cut tangible trophies for the winners. Speaking of the winners, the three winners were Fabio Valentini, Justin Forbes and Ankur this time around, with the session attendees taking part in celebrating their recognition. This programme finally paved the way for the Closing Ceremony, and with the event finally brought to a successful closure by around 0430pm Central European Summer Time, it was time for farewells, goodbyes and forward travelling to DevConf.CZ 2026 too!

Day Three - Flock To Fedora 2026
Manifest #12

With some chat with the programme winners to congratulate them and with Adam to thank him for his continued work on the judging panel, Carol Chen gifted me an event souvenir from Finland. I also hung around for a little while longer to take pictures with Michael Winters (as he proudly called us, "The Data Guys" haha) and with Cornelius in his traditional wear. Dropping off my backpack at Ankur's room, since he was staying at the event venue, we planned to visit a drinking place called Beer Time. While it was just him and me initially, we were soon joined by Hristo Marinov, Christopher Klooz, Jeremy Cline, Emma Kidney, Jess Chitas, Matthew and many others. We marched to the next location and, following their suggestion, I also found myself having a sweet-tasting, enjoyable drink with limited alcohol.

Day Three - Flock To Fedora 2026
Manifest #13

After a couple of rounds of (250ml-sized) Van Honsebroucks and countless chats around the community and family, we decided that it was time for late dinner at around 0700pm Central European Summer Time. While we had to bid Cristian farewell as he had to leave for Brno, this additional time with our Fedora Project friends definitely allowed our community bonds to further deepen. On my advice, our collective soon found itself at the Old Hanoi restaurant – almost poetically finishing the Flock conference where it started. Amidst the continued tête-à-tête, I did find myself getting drowsier by the passing minute, so I had to leave at around 0830pm Central European Summer Time post having the Crispy Garlic Duck Dish so that I could get some rest before my long return flights home on the next day.

Day Three - Flock To Fedora 2026
Manifest #14

We also met with a couple of dining groups at the Old Hanoi restaurant, which seemed to have become a household name for the last couple of Flock events that we had in Prague – one with Matthew Miller and the Fedora Quality team folks, and the other with Jef, Aoife and Shaun. Making a stop at Ankur's room yet again for my travelling backpack, I also chanced upon David Duncan and Neal Gompa in the hotel lobby. Leaving the celebration collective at the Anděl crossing, I could not think of a better way to close the event's gathering, with me leaving for the Ibis Praha Mala Strana hotel to call it a night after around 0900pm Central European Summer Time and them continuing along the way. As I was not going DevConf.CZ, despite repeated requests from Hristo, I had to leave for Kolkata the next day.

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

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

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