/rss20.xml">
fedora

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

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.

🎲 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
  • 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)

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.

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!

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.

misc fedora bits: 2nd week of july 2026

Posted by Kevin Fenzi on 2026-07-11 18:06:26 UTC
Scrye into the crystal ball

Here's another short recap of the last week from me. Another shortish week as I was off monday, but still of course a lot going on.

Aarch64 hardware fun

So, we have a bvmhost-a64 that runs 10 buildvm-a64's for koji builders. A while back it refused to boot with a memory error. Reseating memory got it booting again, but this week when I tried to reinstall it it failed to boot again. At first we thought it was a bad memory stick and pulled one to get it booting again. This took it from 512G memory to 384 (The sticks are in pairs so it was 2 down). Since the mass rebuild for fedora 45 is next week, I didn't want to run with fewer builders, so I had a stick moved from a staging host. Adding that and... it didn't boot again. Turns out on further inspection that it was the memory slot itself on the motherboard that is bad. No memory in that slot works. :(

The vendor wanted us to ship the machine back for testing/repair/replacement. (Normally they would replace/repair on site, but this machine was past the time when they do that).

So, on to plan "B". I repurposed a buildhw we had to be a new bvmhost-a64 and reinstalled all the builders are we are back up and running. Of course we will be down one builder, but that is much better than being down N buildvm's.

RHEL10 reinstalls

Made some progress on rhel10 migrations, although less than I would like. I reinstalled all our bvmhost-x86's that run builders (and all the buildvm-x86 vm's that are on them). I hope to get a number more next week. I'm hopefull I can do them without causing any outages, will do my best.

AWS proxy instances ssh problems

Someone wanted to debug / look at something on one of our proxies and noted that they couldn't ssh into it, even though they were in the right groups and should have been able to. I could not either. Login via root was still possible, but none of our users. Nothing seemed wrong with our config, ansible hadn't changed any in that area in quite a while. ssh config looked normal, nothing odd in /etc/ssh/sshd_config* files. It wasn't even getting past ssh, just saying 'ssh keys failed'. It affected all the proxies we have that were running in aws. I did see some odd selinux denials, but setenforce 0 did not get things working.

Finally, I happened to do a ps to make sure sshd was running in the right selinux context and found it. It was the ec2-instance-connect package. It installs a systemd drop in for ssh that adds it's own AuthorizedKeysCommand option, which completely overrides ours thats in config. Additionally, removing that package causes sshd to... be disabled and stopped. Luckily I was logged in as root and able to start/reenable it. I filed https://bugzilla.redhat.com/show_bug.cgi?id=2498870 on this.

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

You probably don’t need an LTS release

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

One topic that often takes up more brain space than it needs is the concept of a long-term support (LTS) release. An LTS is what the name implies: a release with a longer support period than the usual for a project. LTS releases can be a benefit to users. To some, having an LTS release may signify that this is a Real, Serious Project™. But most projects don’t need one.

Why you don’t need one

The most obvious downside to an LTS release is that it imposes a significant burden on the project maintainers. The longer the definition of “LT”, the greater the burden. I suspect the function is closer to a power function than a linear one. Backporting fixes takes a lot of effort and the effort required compounds the further away a fix is from the original state of the software. If you don’t have people with the time, skills, and motivation to maintain an LTS release, it will not go well.

LTS releases are also often in tension with what users want. Some project maintainers admit their LTS patches are poorly tested, which means the LTS release may end up being buggier. That’s not ideal. People say they want an LTS release but then they get upset if they don’t get access to the new features, too. What they usually want is an easy upgrades with no regressions. The time not spent backporting fixes can be better spent improving test suites and upgrade paths.

When an LTS release makes sense

That’s not to say that an LTS is never a good idea. The more of the following that are true, the more sense it makes for your project to have one:

  • Upgrades between versions are difficult and cannot easily be improved
  • You have a large user base in production use
  • Project contributors have the skill, time, and interests to maintain the release
  • Someone is willing to pay good money for it
  • The project is very large and complex (e.g. a kernel, operating system, or desktop environment)
  • The project is a foundation that other projects are built upon (e.g. a language or framework)

You’ll note that the list above does not say “other projects do” or “users say they want it.” Often, better testing or a longer development schedule addresses the supposed need sufficiently.

This post’s featured photo by Joshua Olsen on Unsplash.

The post You probably don’t need an LTS release appeared first on Duck Alignment Academy.

Flock 2026

Posted by Jeremy Cline on 2026-07-09 16:14:00 UTC

Another Flock to Fedora conference has come and gone, and like last year, this one was held in Prague. Unlike last year, I was not in the middle of moving across the country (again) so I was able to attend, thanks to my employer.

As always, it was great to see so many familiar faces and meet new folks face-to-face. To those of you who weren’t able to make it, you were missed. And, as always, I spent a lot of time in the hallway track talking to people, getting a sense of what everyone was working on and interested in.

Day -1

The day before the conference started, there was a sponsorship dinner. Although Bex did all the work getting the paperwork to the correct people at Microsoft, he wasn’t able to make it to Prague in time for the dinner so I was sent. I arrived on Saturday morning after a quick connection through Dublin, which gave me plenty of time to get settled in and resist taking a nap. I spent the dinner chatting with Kevin Fenzi and Jef Spaleta, and while I can’t remember all the topics, curling was definitely mentioned.

Day 0

I volunteered to help at the check-in desk the morning of the first day, which I felt went very smoothly (the new label makers were a nice addition). It was nice to help out, but it was also a great way to match names I’ve seen on Matrix to faces as folks arrived. After my shift, I got sucked into the hallway track until lunch.

After lunch and a bit more hallway track, I went to the “PR-based Gating for Fedora: Can We Make It Work?” workshop from František Lachman. There was a lot of discussion in and around the Fedora contribution workflow which I have lots of thoughts about, but I felt there was a rather widespread desire to make things better (even if the exact way we do that isn’t clear). Lots of people who were not me brought up keeping the specfiles in one repository rather than forty thousand or however many git repositories we’re up to. In any case, I’d really like a nice pull request workflow for Fedora where I can’t mess up updates, and where we can all share the tooling we build around packaging.

I spent the rest of the day in the hallway track, doing some last minute preparations for my talk on signing, and preparing for the joint Microsoft talk with Reuben and Bex. I was happy to meet some of the Red Hat folks working on cryptography and signing, and I’m hopefully somewhere down the line we can all do approximately the same thing for signing content.

I got dinner with Bex and Reuben at some place that served North Carolina style BBQ, and it was pretty good (especially with kimchi on top!).

Day 1

This was the first day of recorded presentations. I went to the usual “State of Fedora” address, followed by the Fedora Council and FESCo panels. I thought it was interesting (but sadly unsurprising) to see downward trend of contributors, and I’d be interested to see a further breakdown of who’s leaving. I have plenty of not-backed-by-hard-data ideas about why this is happening, but I do hope it leads to a stronger focus on (and acceptance of) improving the contribution experience - the general feeling in the hallways, as I mentioned earlier, makes me somewhat optimistic.

After lunch and a bit of hallway track, I went to the “Secure by Design: Aligning Fedora with the EU Cyber Resilience Act (CRA)” workshop by Jaroslav Řezník and Roman Zhukov. A good portion of it was a run down of what the CRA entailed and how the roles it describes map into Fedora. After that I spent a bit of time preparing for my talk. My talk went well, I think, except the live demo didn’t entirely work (gpg2 + gpg-agent + gnupg-pkcs11-scd is very finicky and I forgot a setup step). With that stressful event out of the way, I was able to relax a bit at the dinner party, chat with numerous folks, and fill up on the “appetizers” they brought out in vast quantities. Big props to the event organizers, the weather was great and I really appreciated the open space and variety of food options.

Day 2

It was hard to believe it was already the final day of the conference, but I think at this point I was also feeling pretty worn out. I went to Justin’s “State of the Fedora Kernel” talk, and was glad to hear that the GitLab workflow I helped build before I left wasn’t absolutely terrible. I made some last minute edits to the slides for our “Two Years In: Accelerating Microsoft Contributions to Fedora” talk (where I was happy to have Bex and Reuben do most of the talking), then helped present that talk. Afterwards I went to the “What’s new in Fedora CoreOS” talk and managed to chat with Jean-Baptiste Trystram and Joel Capitao about signing and Konflux, which we’ll hopefully get sorted out in the next couple weeks (in the staging environment, anyway). Hopefully we’ll also be able to get Fedora CoreOS images into the Azure community gallery alongside the Cloud images.

The lightning talks were all enjoyable, and I’m really impressed some folks even managed to make up slides for theirs and nothing went terribly wrong (great work everyone). There was time for a bit more hallway track, and then I went to the Contributor Recognition Program, which concluded the presentations for Flock 2026. I spent the evening catching up with old and new friends, chatting about ideas on improving various bits of Fedora infrastructure, and how to make the contributor experience better. People were already leaving for DevConf (or home) at this point, so if I didn’t get a chance to say goodbye, I’m sorry and I hope we’ll see each other next year!

Day 3

It was an uneventful trip back home, thankfully.

I’m looking forward to put all the work I’ve done on improving Fedora’s signing infrastructure through its paces, to get support for PQC done, and I have a few ideas on what to work on next. Hopefully some of them work out and don’t lead to too many people screaming at me. Flock is a great event to get excited about the next year of work and to test the waters on wild ideas, so I’m really glad I was able to make it this year.

HDR Kodi available for Fedora

Posted by Tomasz Torcz on 2026-07-09 15:53:18 UTC

RPM Fusion shipped Kodi 22-beta1 for Fedora 44. This is the version with PR adding HDR support under Wayland merged. It's a bit weird seing a beta version submitted as an update to stable branch, but hey, it works. Thanks Leigh!

It works OK under GNOME session with HDR enabled. The UI elements are bit oversaturated when playing High Dynamic Content, but the videos themselves are pretty. At last. This is the year of HDR on Linux Desktop.

If only GeForce Now would catch up with the times…

068/100 of #100DaysToOffload

Heroes of Fedora Quality for Q2 2026

Posted by Kamil Páral on 2026-07-09 13:32:32 UTC

The second quarter of 2026 is over, and so in this post we’d like to highlight the top Fedora Quality contributors who helped us maintain the quality bar for Fedora during this time period. Fedora wouldn’t be a high-quality distribution without its community. Every single person who helped us detect and resolve issues, or verify that things work as expected, deserves our gratitude, thank you!

If you haven’t participated yet in testing Fedora, perhaps you’d like to give it a try? We gladly welcome everyone. Please look at our Fedora Quality homepage.

Testing proposed updates 📦

When software packages are updated in Fedora (bringing bug fixes and new features), they are not released to end users immediately. They first go to the updates-testing repository, where they undergo automated testing, and also await manual feedback from human testers. This feedback can be provided through Bodhi, either by using its web interface or CLI tools, see instructions. Alerting package maintainers by posting a negative feedback with a problem description can stop the update from reaching general audience and causing issues to all our users. Testing proposed updates is a simple, yet vital process for keeping Fedora releases of high quality during their whole lifecycle. It is used both for already stable and in-development Fedora releases.

Test period: Q2 2026 (2026-04-01 – 2026-06-30)
Contributors: 408
Updates commented1: 5103

NameUpdates commented
Derek Enz (derekenz)882
Geraldo S. Simião Kutz (geraldosimiao)811
Filipe Rosset (filiperosset)437
besser82287
bojan263
Ian Laurie (nixuser)214
Eugene Mah (imabug)187
anotheruser129
Colin Thomson (g6avk)111
Kamil Páral (kparal)82
Wasser Mai (wasser19641)68
Ephraim Kaov (ephmo)66
Adam Williamson (adamwill)63
markec62
Neal Gompa (ngompa)61
Joe Ant (maketopsite)54
František Zatloukal (frantisekz)48
Michel Lind (salimma)30
Cristian Ciupitu (ciupicri)27
brett h (bretth)24
patchman24
Simon de Vlieger (supakeen)24
Alex Gurenko (agurenko)23
niels-s23
Steve Cossette (farchord)21
Ankur Sinha (ankursinha)21
Carl George (carlwgeorge)19
Benjamin Beasley (music)17
itrymybest8017
Fabio Valentini (decathorpe)17
John Howard (johnh99)16
Gilles Duboscq (gilwooden)16
robatino15
JR Sanders (jrsanders)14
Pawel Buzniak (pawef10)13
Davide Cavalca (dcavalca)13
Peter Robinson (pbrobinson)13
Christopher Klooz (py0xc3)12
Oleg Obleukhov (leoleovich)12
Petr Pisar (ppisar)12
Patty Berge (thetick)11
Lukáš Růžička (lruzicka)11
Yixin Wei (esoapw)11
Marcin Juszkiewicz (hrw)11
rosti11
Luca Boccassi (bluca)10
Vadim Fedorenko (vfedorenko)10
Daniel Anderson (lordalfredo)10
Miro Hrončok (churchyard)10
Mattias Ellert (ellert)10
…and also 358 other testers who commented on less than 10 updates each, but 750 comments combined!

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

Test days participation 📅

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

Test period: Q2 2026 (2026-04-01 – 2026-06-30)
Contributors: 25
Test cases executed: 76

NameTest cases executed
nielsenb10
clnetbox6
imabug6
nixuser5
pauloheaven5
guiltydoggy5
adriend4
g6avk4
anotheruser4
bittin3
psklenar3
agurenko2
bretth2
derekenz2
augenauf2
geraldosimiao2
luya2
py0xc32
boniboyblue1
itrymybest801
jgroman1
kurtlindberg1
g4ridwan1
farel1
pstourac1

We sincerely thank all contributors!🏅

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

Syslog-ng Java destination disabled

Posted by Peter Czanik on 2026-07-09 13:19:41 UTC

For many years, syslog-ng used Java, where C libraries were unavailable. However, over the years native C libraries became available for Elasticsearch and Kafka, and HDFS practically disappeared. As a “scream test”, I am going to disable Java support in all of my syslog-ng packages.

Once upon a time, Java support was added to syslog-ng to be able to load Elasticsearch Java drivers. Later, Kafka, HDFS, and a generic HTTP destination were also added. Unfortunately, using Java was a major pain. Loading libraries required some manual configuration. Packaging the Java destination in official Linux distribution packages was possible, however, packaging the actual drivers written in Java was impossible. For a while, I maintained unofficial packaging for these drivers, but as C alternatives appeared, I removed these components. Nobody complained. Recently all drivers, except for HDFS, have been removed from the source code as well. Again: nobody complained.

Right now, we still have HDFS support in the source code, but not for long. I have been posting about it for years now, and nobody asked us to keep it. This is the last driver making use of the Java destination of syslog-ng. We will delete it soon, too.

We do not delete code related to Java right now. However, as a “scream test” I am going to disable the Java destination in all my packages. I have done it already in the official openSUSE syslog-ng package. Fedora Rawhide is next. I will also remove it from my git snapshot packages.

If you use Java with your own driver code, let us know! Otherwise, the Java destination will be not just disabled in packages but removed from code as well.

syslog-ng logo

Red Hat EX467 exam

Posted by Fabio Alessandro Locati on 2026-07-09 00:00:00 UTC

Last Friday, I renewed my Red Hat Certified Specialist in Managing Automation with Ansible Automation Platform (EX467) certification. As I’m already a Red Hat Certified Architect and have passed this same exam about three years ago, I wasn’t too worried about it.

The exam still focuses on leveraging the Ansible Automation Platform in enterprise environments rather than writing Ansible code, which remains the domain of the EX294. Compared to three years ago, the platform version has been updated, but the overall structure and approach felt familiar. Timewise, the exam continues to be completable well within the allocated time if you have enough experience with the platform. This time it took me 1 hour and 38 minutes to go through it.

Megacable: Modo puente con un gateway linuxero

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

Hoy se me ocurrió que quiero mi módem de Megacable en modo puente. La neta, tener doble NAT es un dolor de cabeza si quieres hospedar tus servicios, recibir conexiones directas o simplemente tener un ruteo limpio. Así que decidí ponerlo en modo puente y, de paso, resolver el detalle de que el perfil de IP pública no incluye IPv6.

Aquí te cuento toda la historia y cómo configuré mi gateway con NetworkManager y Firewalld para que todo jalara bien chingón.

Note

Para fines prácticos y por mera seguridad de mi infraestructura, todas las direcciones IP (tanto IPv4 como IPv6) y nombres de dominio externos mostrados en este artículo fueron modificados. Son meros ejemplos de demostración, no te vayas con la finta.

La llamada

Para poder cambiar el módem Huawei HG8145V5 a modo puente, necesitaba las credenciales de administrador (root). El problema es que cambian todos los días. Y, ahí estuve, llamando a las 01:15 hrs y me contestaron de volada. Me tomó unas 5 llamadas para conseguir las claves del día, pero al final la paciencia rindió frutos. Me explicaron que para darme acceso de administrador y ponerme en modo puente, el procedimiento requería contratar una "IP pública dinámica".

A final de cuentas, me pareció una buena idea y decidí pagar los 100 varos extras al mes para salir del Carrier-Grade NAT (CGNAT). Al final sí se armó la cosa: me asignaron una IP pública real y con eso pudimos avanzar sin problemas.

El modem

Ya con acceso root al módem, configuré el equipo para que no se sobrescribiera la configuración con las actualizaciones automáticas remotas (TR-069) y asegurar la estabilidad de la red.

Para lograr esto, hice lo siguiente:

  1. Entré a System Management -> TR-069.
  2. Desmarqué Enable ACS Management y Enable Periodic Informing.
  3. Fui a la configuración de WAN y borré por completo el perfil TR-069 de administración remota. Así les corté el cable de tajo.

Luego, modifiqué el perfil de internet principal (el cual suele llamarse algo como INTERNET_R_VID_XXX):

  • Cambié el WAN Mode a Bridge WAN.
  • Mantuve habilitado el VLAN ID con el tag correspondiente a mi zona.
  • En las opciones de copiado de puertos (Binding Options), seleccioné LAN1, que es donde tengo conectado el cable hacia mi gateway.

Apliqué los cambios y ¡madres!, el módem se convirtió en un simple puente transparente. Mi gateway recibió la IP pública (198.51.100.50) de volada vía DHCP en la interfaz enp3s0.

El drama

En cuanto se activó la IP pública, me di cuenta de que el IPv6 ya no estaba disponible. Volví a hablar con soporte y de manera muy clara me explicaron la situación: en su plataforma, los perfiles del BNG están separados, de modo que el perfil de IP pública es estrictamente IPv4-only. O tienes IP pública o tienes IPv6 nativo, pero no ambos al mismo tiempo.

Como yo no me iba a quedar sin IPv6, decidí usar un túnel broker. Fui a tunnelbroker.net (de Hurricane Electric), me registré y configuré un túnel apuntando a mi nueva IP pública. El servidor de Dallas, TX (198.51.100.1) fue el que me dio menor latencia (unos 62 ms promedio).

El gateway

Aquí es donde viene lo chido. Para que todo funcione de manera permanente, configuré mi gateway con NetworkManager, firewalld y radvd.

Primero, creé el túnel SIT (Simple Internet Transition) en mi gateway ruteado sobre la interfaz física:

# Crear interfaz de túnel SIT en NetworkManager
nmcli connection add \
   type ip-tunnel \
   con-name he-ipv6 \
   ifname he-ipv6 \
   mode sit \
   remote 198.51.100.1 \
   ip-tunnel.parent enp3s0 \
   ipv4.method disabled \
   ipv6.method manual \
   ipv6.addresses "2001:db8:1::2/64" \
   ipv6.gateway "2001:db8:1::1" \
   ipv6.route-metric 100 \
   connection.zone external

Note

Configurar ip-tunnel.parent en lugar de una IP local estática es un parote, porque si tu IP pública cambia, el túnel sigue amarrado a la interfaz correcta.

Luego, configuré mi interfaz de red local (enp2s0) para manejar mi prefijo ULA (para cosas locales) y el bloque IPv6 global que me dio Hurricane Electric:

# Asignar ULA y GUA pública a la LAN
nmcli connection modify enp2s0 \
   ipv6.method manual \
   ipv6.addresses "fd41::1/64, 2001:db8:2::1/64"
nmcli connection up enp2s0

El Firewall

Para que el túnel levante, el firewall debe permitir el tráfico del protocolo 41 (SIT) desde el servidor de Hurricane Electric. También quería asegurarme de no hacer NAT66 (masquerading) en mi prefijo IPv6 público para tener ruteo nativo, pero sí mantenerlo en mi prefijo ULA (fd41::/64).

Bueno, ahí va el cotorreo para configurar firewalld:

# Permitir protocolo 41 en la zona externa
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv4" source address="198.51.100.1" protocol value="41" accept'

# Quitar masquerading global de IPv6
firewall-cmd --permanent --zone=external --remove-rich-rule='rule family="ipv6" masquerade'

# Habilitar masquerading exclusivo para la ULA
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv6" source address="fd41::/64" masquerade'

# Aplicar cambios
firewall-cmd --reload

Repartiendo IPs con radvd

Para que todos los clientes de la red local obtengan sus IPs globales automáticamente mediante SLAAC, edité el archivo /etc/radvd.conf para anunciar ambos prefijos:

# /etc/radvd.conf
interface enp2s0 {
   AdvSendAdvert on;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;
   prefix fd41::/64 {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };
   prefix 2001:db8:2::/64 {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };
};

Encendí el servicio:

systemctl enable radvd
systemctl restart radvd

La automatización (DDNS)

Como la IP pública de Megacable es dinámica, cada vez que cambie, el túnel de Hurricane Electric se va a romper si no le avisamos al endpoint del nuevo valor de la IP.

Para no tener que andar haciéndolo a mano, me armé un script despachador de NetworkManager en /etc/NetworkManager/dispatcher.d/50-he-tunnel-update.bash que reacciona de volada cuando cambia la IP en la interfaz WAN (enp3s0) y actualiza el túnel mediante la API de HE.

Por mera seguridad, las credenciales (usuario, Update Key de la pestaña Advanced del túnel, e ID del túnel) las guardé en un archivo separado en /usr/local/etc/tunnelbroker.bash con permisos 0600.

El script del dispatcher se ve más o menos así:

#!/usr/bin/bash
# Despachador de NetworkManager para actualizar la IP del túnel
set -euo pipefail
IFS=$'\n\t'

readonly Interface="enp3s0"
readonly ConfigFile="/usr/local/etc/tunnelbroker.bash"
readonly UpdateUrl="https://ipv4.tunnelbroker.net/nic/update"

main() {
    local -r interface="${1:-}"
    local -r action="${2:-}"

    if [[ "$interface" != "$Interface" ]] || [[ "$action" != "up" && "$action" != "dhcp4-change" ]]; then
        return 0
    fi

    # shellcheck source=/dev/null
    source "$ConfigFile"

    # Enviar actualización a HE
    local response
    response=$(curl -4 -sS -G \
        --data-urlencode "username=$username" \
        --data-urlencode "password=$password" \
        --data-urlencode "hostname=$hostname" \
        --data-urlencode "myip=AUTO" \
        "$UpdateUrl")

    if [[ "$response" =~ ^(good|nochg) ]]; then
        # Reiniciar conexión he-ipv6 para refrescar
        nmcli connection up he-ipv6 &>/dev/null || true
    fi
}

main "$@"

¡Madres! Con esto, la actualización de la IP queda automatizada y el túnel se levanta solito sin importar cuántas veces Megacable nos cambie la IP WAN.

La prueba de fuego

En cuanto encendí radvd, mi workstation obtuvo su dirección IPv6 global (2001:db8:2::100/64).

Para probar si de verdad todo jalaba, levanté mi servidor Caddy local y corrí un curl desde un VPS externo (vps.ejemplo.net) apuntando directo a mi IPv6:

ssh vps.ejemplo.net "curl -6 -I -m 5 http://[2001:db8:2::100]/"

Me devolvió un hermoso HTTP/1.1 200 OK de Caddy de volón pimpón. Cero NAT, cero complicaciones y ruteo nativo directo a mi máquina. ¡Una chulada!

¿Qué te parece? Si estás atorado con el doble NAT de tu ISP, mándalos a la chingada y ármate tu propio túnel. Vale totalmente la pena.

Reflections on Organizing Flock as Fedora Community Architect

Posted by Justin Wheeler on 2026-07-07 08:00:00 UTC
Reflections on Organizing Flock as Fedora Community Architect

This is the third and final post in my series on Flock to Fedora 2026. The first post covered the highlights of what happened at the event. The second post looked behind the scenes at how Flock gets organized. This post is more personal — it is about what organizing Flock has taught me over the last four years.

The Underrated Importance of Having Fun

The hallway track does not exclusively take place in hallways. At Flock to Fedora, we have a long-standing tradition of fantastic, inclusive social events which invite people to connect over something other than Fedora, Linux, and open source. As someone who has attended several of these social events and now had the privilege to co-organize some of them, I realize this is something truly unique to how we do Flock to Fedora. A lot of attention, time, and care is spent on curating thoughtful evening programming which gets our community to bond, get to know each other, and honestly, have some fun.

In the heavily-corporate world of Open Source in the 2020s, we may not get to discuss the role and importance of having fun as often as we should. But in my experience in Fedora, having fun together as a community is how we build the trust and relationships that get us through some of our most challenging and difficult moments as a project and community. So, whether "hallway track" takes place in the actual venue hallway, a river boat cruise, a local pub, or over a board game, all of these things are critical ingredients to making the Fedora community sustainable for all of the time we spent from wherever we call home, collaborating over video calls, Matrix, Discourse, mailing lists, and the overwhelming number of other places where Fedora contribution conversations take place.

Global Equity and Regional Access

There are lots of things on my mind about Flock 2027, but of course, I am thinking about the where question. Where should the next edition take place? What continent should the next Flock take place? Should we repeat cities more often, or go to brand-new places? How can we make sure we are not only appealing to our long-time contributors, but also our global community of people in regions where we historically had low engagement and participation?

These are the kind of questions that keep me up late at night. Inclusion is critically important to me. Fedora is nothing without the global diversity and perspective we have. Everyone can participate and influence the future of their favorite operating system, and Fedora has processes to ensure that influence is fair, equitable, and open to the community regardless of who you are or where you come from. Therefore, the location decision carries many delicate considerations that are not always obvious to people who have the privilege to attend Flock wherever and whenever it may be.

I do not have answers here, but I am excited to analyze the survey results later this month. The data always tells me a perspective grounded in actual feedback from the community. While there are various complex factors that go into where and when the next Flock will be, I always value what our community has to say about this. I look forward to sharing the results of the Flock 2026 post-event survey and what the community has to say about the next edition of Flock to Fedora.

Virtual Experience Enhancements

The virtual/hybrid experience of Flock is a critical part of how we should be thinking ahead to Flock 2027. Since Flock restarted after the COVID-19 pandemic, we invested significantly more into our virtual, hybrid experience. It is unfortunate that this often ends up as being one of the most expensive costs of the entire event, even eclipsing spend on our financial assistance program and sponsored travel. Yet, it is critically important, both for people who cannot travel yet are key figures in the community, and for the long-term memory of the project contributors about what we are doing and focusing on now. There is also the benefit to the wider Linux and Open Source ecosystem to have visibility into what we are discussing and doing in Fedora from the live-stream and recorded sessions.

I am content with how we have piloted the use of Matrix to curate virtual engagement in live sessions at Flock. While it is surely not perfect, it is amazing to me to compare the digital infrastructure we have in 2026 to my first Flock in 2015. This is simply a level of engagement we could never have facilitated over IRC. I know we have a lot to improve on. But I am keen to think more about how we keep this part of the event planning as a critical, important part. The virtual experience was not important or financially possible for the first Flock edition in Charleston, South Carolina back in 2013. But in 2026, it is more important than ever.

I want to think more about how we can lean on Fedora’s First Foundation to show the rest of the Open Source ecosystem how to create the most inclusive, most engaging hybrid event experience there is. Perhaps we can lean on lessons from our virtual Fedora Release Parties we conduct twice a year.

Looking Ahead

Some of the things I am most proud of about Flock 2026 are our record-breaking attendance and sponsorship, and how the community continues to rally around this event. I eagerly anticipate reading the complete results of the Flock 2026 post-event survey and what people have to say, good and bad, about this year’s edition. The entire Flock organizing team puts in a lot of effort and time to build an event that represents the Fedora community. Since Flock is our annual flagship contributor event, this is a very important task!

The trajectory of Flock to Fedora is on the right path. There are still some friction points we need to improve, we need to start earlier on some things, and we need to leave room for the community to get involved. All that said, the signs I am watching are showing healthy growth. Now, we must not rest on our laurels, and sustain this momentum to deliver quality results for the entire Fedora community.

Bye-bye, Flock 2026. Here we come, Flock 2027!

More in this series

Fedora Package Review Process reimagined

Posted by Jakub Kadlčík on 2026-07-07 00:00:00 UTC

The Fedora Package Review Process is clunky, archaic, and not on par with what we expect when contributing to Open Source projects in this century. We all know that, and we all want it to improve. That being said, we need to realize what is currently our main bottleneck. Even though the process is not friendly to new contributors, they are doing just fine - at all times, we have hundreds of new packages in the queue. Our biggest problem is our inability to effectively review them.

I don’t think we talk about this problem enough. That’s why it felt so validating to hear Miro Hrončok voice my exact thoughts during the Flock to Fedora 2026 keynote.

In this blog post, I am going to elaborate on the ideas that we (mostly Miro) came up with, shooting shit in the hallway after the session.

Proposing new packages through PRs

This is an obvious one, we talked about the same idea with Zbigniew Jędrzejewski-Szmek at Flock to Fedora 2025. It is a necessary prerequisite for any potential improvements, which will allow us to have a workflow that contributors are familiar with, inline code comments, CI/CD, and other things that are not possible in Bugzilla.

Proposing new packages through PRs would be trivial to implement if we had all Fedora packages in a monorepo. Which we don’t, and we probably don’t want to have. And even if we wanted to have, it would require massive changes throughout the ecosystem.

As a workaround, we discussed having an intermediate repository on the forge.fedoraproject.org into which we would only propose new packages. It would have Packit CI enabled, and therefore every proposed package would automatically get a scratch build and a test suite run on top of it. Currently supported tests are rpmlint, rpminspect, and license-validate. We know that adding new tests is easy, as I am currently working on support for fedora-review.

Of course, a final approval from a fellow package maintainer would still be needed. Once accepted, we would merge the PR and automatically create a new DistGit repository and import the package. Then we would delete all data from the intermediate repository to keep it clean.

Bulk review

The review queue is and always has been in hundreds. Many of the packages are dependencies for something else, and people have no motivation to review them separately. And even if they do, it’s not always easy to test them on their own. This currently leads to accepting broken packages that nobody tested or ignoring the tickets completely.

We discussed the possibility of proposing multiple packages within one PR. They could be reviewed, tested, and accepted all at once.

For such PRs, we could automatically create a new project in Copr and build the packages in the order they were committed. We could nicely use Copr’s build batches feature here. If multiple packages were added in one commit, they could be built in parallel. If the contributor decides to force-push into their PR, we would wipe the Copr project and start over.

Auto import into DistGit

There is no reason why the contributor would have to manually run

fedpkg request-repo my-package 12345
fedpkg request-branch --all-releases

fedpkg clone foo
cd foo
fedpkg import /path/to/the/foo.src.rpm
fedpkg push
fedpkg build

fedpkg switch-branch f44
git rebase rawhide
fedpkg push
fedpkg build
# ...
# repeat for f43, f42, etc

We can request all the DistGit repositories and branches for them. And once they are created, we can automatically import the packages. There are some open questions though. How can the contributor signalize what branches they want? Should we use the git history from the PR? Can we use Forgejo actions to trigger the requests and imports?

Proposal vs prototype

I realize this is not a formal proposal but merely a blog post on my personal website. That was an intentional decision. We’ve been discussing and bike-shedding this topic for years, and yet we don’t have much to show for it. I am writing this article mainly not to forget the ideas we’ve had, and even though I am interested in your thoughts, this is not an RFC. I already started implementing a prototype, and soon I’ll record a demo for you. Then, I’ll start bothering you and asking for feedback.

In my opinion, it doesn’t have to be perfect. We just need to kick this off, implement something small that works, and improve it as time goes.

Maybe I should also say that I am not aiming to replace the current Package Review Process. My goal is to provide an alternative version of this process and allow contributors to choose which one they want to follow. Then, someday in the future, if the alternative turns out to be popular, possibly deprecating the old review process.

I am not a tool

Posted by Miro Hrončok on 2026-07-07 00:00:00 UTC

I work at Red Hat in the Python Maintenance team mostly taking care of the Python ecosystem in Fedora. For the past year or so, I’ve been motivated by my employer to use agentic AI to deliver my work. Clearly, we are not the only ones.

At the beginning, I struggled to find reasonable use cases for this tool. I maintain software, which involves a lot more communication and coordination than actually writing code. When people ask me what I do, I often half-jokingly reply that I read and write a lot of emails. How can AI boost my productivity when I spend 80% of my time essentially talking to people? Where is the fun in replacing the remaining 20% of actually crafting code with more talking, this time to half-competent robots?

In time, I found ways to use AI that felt productive. And, ever so hypocritically, not only at work. But at what cost? I am supporting an industry that regularly harms open source projects such as Fedora, helps destroy the planet and uses stolen data. Moreover, I’ve become reliant on a proprietary tool. Is my AI-boosted contribution to Fedora worth it?

Despite my moral dilemma, I still love my job. I am a long-standing, well-known Fedora contributor, working for the most part on whatever I feel is needed, earning a competitive salary. In theory, I could go look for another job where I would not be motivated to do this, but I wouldn’t be able to keep doing the thing I love. I try to make the best out of this situation and, despite my initial distaste, use the tool to improve the project. So at the end of the day, I close my eyes and think of Fedora1.

However, the implications of embracing AI are not just impacting me. The nature of my work means I’ve made hundreds (thousands?) of small open source contributions here and there. And sometimes, when I use AI to deliver those, it kinda feels like bringing a chunk of meat to a vegan BBQ. The people on the receiving end of my contribution for the most part don’t care about my job sustainability or IBM shareholders, nor should they.

Once, I used AI to contribute to a Fedora packaging project. It was reluctantly reviewed by another long-standing, well-known Fedora contributor (who happens not to be employed by Red Hat and is not well-compensated for this work). When talking to them, I realized that they were uncomfortable reviewing such a change. I made them uncomfortable by choosing to use AI for this. My employer made me uncomfortable; I passed it on to a volunteer. What an outstanding open source citizen.

I appreciate the irony of this; and yet, I am no slop generator. I understand what I submit and I put my name on it. I disclose the usage for transparency, because it matters. I don’t just drop a vibecoded patch on an open source project. If you have an AI policy, I read it and respect it. So it pains me deeply when our carefully considered contributions are outright branded AI slop or LLM hallucinations, and the person bringing them is evaluated solely on the basis of the tool they used. Especially when such judgment is made by people I respect2.

No, I am not a tool. Please don’t treat me as such.

PS On a lighter note, here are some examples of AI usage that somehow eliminate this problem for me:

  • Debugging a problem — in our team we’ve been very successful in showing a failing test to Claude and telling it that it started failing with Python 3.15. While burning thousands of tokens and wasting gallons of drinking water it can usually successfully determine what caused the failure. We were able to determine this ourselves in the past, but this actually boosted our productivity. We can then report the problem to upstream after we have verified the find.
  • My own/my team’s semi-internal tooling —3 the omnipresent bunch of random scripts I am not proud of and which would desperately need a rewrite but ain’t nobody got time for that. Just slop ‘em. If it works, it works. If it doesn’t, roll-back. Nobody needs to see this code anyway. Excellent for AI — I am still kinda killing the planet but at least I don’t shove it in your face.
  • Reporting to management — somehow people keep asking me what I did. There’s no dilemma in providing AI-generated reports to the same people who asked me to use AI. If nothing else, it demonstrates how progressive I am with it.
  • Reviews for me — when I don’t use AI to generate code, but rather ask it to review my design and implementation, nobody is forced to deal with my AI usage. For example, I wrote this blogpost myself, then asked AI for feedback on typos, grammar, tone, voice, argument, rhetoric, structure, flow…4

  1. And perhaps even more so, my mortgage and the food on my table. ↩

  2. And precisely because of that I choose to not link those cases here. This is not about naming and shaming. ↩

  3. This m-dash was copy-pasted from websearch results by a human. ↩

  4. If nothing else, at least the model pretends it appreciates my sarcasm. ↩

I am not a tool

Posted by Miro Hrončok on 2026-07-07 00:00:00 UTC

I work at Red Hat in the Python Maintenance team mostly taking care of the Python ecosystem in Fedora. For the past year or so, I’ve been motivated by my employer to use agentic AI to deliver my work. Clearly, we are not the only ones.

At the beginning, I struggled to find reasonable use cases for this tool. I maintain software, which involves a lot more communication and coordination than actually writing code. When people ask me what I do, I often half-jokingly reply that I read and write a lot of emails. How can AI boost my productivity when I spend 80% of my time essentially talking to people? Where is the fun in replacing the remaining 20% of actually crafting code with more talking, this time to half-competent robots?

In time, I found ways to use AI that felt productive. And, ever so hypocritically, not only at work. But at what cost? I am supporting an industry that regularly harms open source projects such as Fedora, helps destroy the planet and uses stolen data. Moreover, I’ve become reliant on a proprietary tool. Is my AI-boosted contribution to Fedora worth it?

Despite my moral dilemma, I still love my job. I am a long-standing, well-known Fedora contributor, working for the most part on whatever I feel is needed, earning a competitive salary. In theory, I could go look for another job where I would not be motivated to do this, but I wouldn’t be able to keep doing the thing I love. I try to make the best out of this situation and, despite my initial distaste, use the tool to improve the project. So at the end of the day, I close my eyes and think of Fedora1.

However, the implications of embracing AI are not just impacting me. The nature of my work means I’ve made hundreds (thousands?) of small open source contributions here and there. And sometimes, when I use AI to deliver those, it kinda feels like bringing a chunk of meat to a vegan BBQ. The people on the receiving end of my contribution for the most part don’t care about my job sustainability or IBM shareholders, nor should they.

Once, I used AI to contribute to a Fedora packaging project. It was reluctantly reviewed by another long-standing, well-known Fedora contributor (who happens not to be employed by Red Hat and is not well-compensated for this work). When talking to them, I realized that they were uncomfortable reviewing such a change. I made them uncomfortable by choosing to use AI for this. My employer made me uncomfortable; I passed it on to a volunteer. What an outstanding open source citizen.

I appreciate the irony of this; and yet, I am no slop generator. I understand what I submit and I put my name on it. I disclose the usage for transparency, because it matters. I don’t just drop a vibecoded patch on an open source project. If you have an AI policy, I read it and respect it. So it pains me deeply when our carefully considered contributions are outright branded AI slop or LLM hallucinations, and the person bringing them is evaluated solely on the basis of the tool they used. Especially when such judgment is made by people I respect2.

No, I am not a tool. Please don’t treat me as such.

PS On a lighter note, here are some examples of AI usage that somehow eliminate this problem for me:

  • Debugging a problem — in our team we’ve been very successful in showing a failing test to Claude and telling it that it started failing with Python 3.15. While burning thousands of tokens and wasting gallons of drinking water it can usually successfully determine what caused the failure. We were able to determine this ourselves in the past, but this actually boosted our productivity. We can then report the problem to upstream after we have verified the find.
  • My own/my team’s semi-internal tooling —3 the omnipresent bunch of random scripts I am not proud of and which would desperately need a rewrite but ain’t nobody got time for that. Just slop ‘em. If it works, it works. If it doesn’t, roll-back. Nobody needs to see this code anyway. Excellent for AI — I am still kinda killing the planet but at least I don’t shove it in your face.
  • Reporting to management — somehow people keep asking me what I did. There’s no dilemma in providing AI-generated reports to the same people who asked me to use AI. If nothing else, it demonstrates how progressive I am with it.
  • Reviews for me — when I don’t use AI to generate code, but rather ask it to review my design and implementation, nobody is forced to deal with my AI usage. For example, I wrote this blogpost myself, then asked AI for feedback on typos, grammar, tone, voice, argument, rhetoric, structure, flow…4

  1. And perhaps even more so, my mortgage and the food on my table. ↩

  2. And precisely because of that I choose to not link those cases here. This is not about naming and shaming. ↩

  3. This m-dash was copy-pasted from websearch results by a human. ↩

  4. If nothing else, at least the model pretends it appreciates my sarcasm. ↩

Bots de Telegram: La consola de ChatOps definitiva para Sysadmins

Posted by Rénich Bon Ćirić on 2026-07-06 21:15:00 UTC

Hoy te vengo a hablar de una herramienta que, para muchos, nomás sirve para mandar memes o jugar trivias en chats grupales. Pero la neta, si eres sysadmin o te late el desmadre del self-hosting y la administración de servidores, la API de Bots de Telegram es una mina de oro. Es, sin temor a equivocarme, la consola de ChatOps más barata y potente que te puedes echar a la bolsa.

Dejate de andar batallando con pasarelas de SMS de paga o configurando servidores de correo SMTP que de todos modos van a terminar en la carpeta de spam. Con un bot de Telegram tienes un canal de comunicación directo, encriptado y gratis para controlar tus fierros desde cualquier lugar.

Aquí te cuento las características clave y ejemplos bien prácticos para que los corras tú mismo:

Alertas automáticas en caso de fallos

Para notificaciones rápidas, no necesitas montar ninguna infraestructura compleja. Puedes crear un script de notificación para systemd que te avise de volada si algún servicio importante se cae.

Primero, creas el script que hace el envío:

# /usr/local/bin/systemd-telegram-notify.bash
#!/usr/bin/bash
set -euo pipefail
IFS=$'\n\t'

readonly BotToken="123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
readonly ChatId="987654321"

main() {
    local -r service_name="${1:-}"
    if [[ -z "$service_name" ]]; then
        printf "Usage: %s <service_name>\n" "${0##*/}" >&2
        return 1
    fi

    local message
    message=$(printf "❌ *Servicio Caído*\n*Host:* %s\n*Servicio:* \`%s\`\n*Hora:* %s" \
        "$(hostname)" \
        "$service_name" \
        "$(date '+%Y-%m-%d %H:%M:%S')")

    curl -s -X POST "https://api.telegram.org/bot${BotToken}/sendMessage" \
         -d "chat_id=${ChatId}" \
         -d "parse_mode=MarkdownV2" \
         -d "text=${message}"
}

main "$@"

Luego, creas un archivo de unidad de servicio genérico para systemd:

# /etc/systemd/system/telegram-notify@.service
[Unit]
Description=Enviar alerta de Telegram al fallar %I

[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-telegram-notify.bash %i

Ahora, en cualquier servicio que quieras vigilar (como nginx.service), nomás agregas la directiva OnFailure=telegram-notify@%n.service en la sección [Unit]. Si el servicio truena, ¡te llega el pitazo al celular de inmediato!

Comandos de control y autenticación segura

Puedes programar tu bot para que escuche comandos y te regrese el estado del sistema. Lo mejor es que la API de Telegram hace la autenticación por ti. Cada mensaje entrante contiene el ID numérico verificado del usuario.

Aquí tienes un micro-daemon en Crystal, sin dependencias externas, que escucha comandos de diagnóstico de forma segura:

# /usr/local/bin/telegram-bot.cr
require "http/server"
require "json"
require "process"

ADMIN_ID = 987654321_i64
BOT_TOKEN = "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"

server = HTTP::Server.new do |context|
  if context.request.method == "POST" && context.request.path == "/webhook"
    if body = context.request.body
      payload = JSON.parse(body.gets_to_end)
      msg = payload["message"]?
      sender_id = msg.try(&.["from"]?.try(&.["id"]?.try(&.as_i64?)))
      text = msg.try(&.["text"]?.try(&.as_s?)) || ""

      if sender_id == ADMIN_ID && text.starts_with?("/status")
        # Ejecuta un comando rápido de diagnóstico
        stdout = IO::Memory.new
        Process.run("df", args: ["-h", "/"], output: stdout)
        disk_res = stdout.to_s

        reply = "Estado de discos:\n<pre>#{disk_res}</pre>"
        send_reply(msg.not_nil!["chat"]["id"].as_i64, reply)
      end
    end
  end

  context.response.content_type = "application/json"
  context.response.status = HTTP::Status::OK
  context.response.print({status: "ok"}.to_json)
end

def send_reply(chat_id : Int64, text : String)
  client = HTTP::Client.new(URI.parse("https://api.telegram.org"))
  payload = {
    chat_id: chat_id,
    text: text,
    parse_mode: "HTML"
  }.to_json

  client.post(
    "/bot#{BOT_TOKEN}/sendMessage",
    headers: HTTP::Headers{"Content-Type" => "application/json"},
    body: payload
  )
end

address = server.bind_tcp "0.0.0.0", 8443
puts "Escuchando en http://#{address}"
server.listen

Local Bot API Server: Control local sin límites

Esta característica es una joya para sysadmins. Si no quieres que tu tráfico de red salga a los servidores en la nube de Telegram, puedes correr tu propio Local Bot API Server.

Aquí tienes un archivo de servicio de systemd para tener tu pasarela local corriendo como servicio del sistema:

# /etc/systemd/system/telegram-bot-api.service
[Unit]
Description=Telegram Bot API Local Server
After=network.target

[Service]
Type=simple
User=telegram
ExecStart=/usr/local/bin/telegram-bot-api --local --api-id=tu_api_id --api-hash=tu_api_hash --dir=/var/lib/telegram-bot-api --working-dir=/var/lib/telegram-bot-api/temp
Restart=always

[Install]
WantedBy=multi-user.target

Una vez activado, nomás apuntas tus peticiones de curl o Crystal a http://localhost:8081/bot<token>/ y listo. Ya puedes subir respaldos de hasta 2GB directamente usando la ruta local (ej. file:///var/backups/dump.sql).

Mensajería enriquecida para reportes detallados

Con el motor de Rich Messages (Bot API 10.1), ya no estás limitado a bloques de texto plano feos. Puedes mandar reportes detallados usando plantillas HTML avanzadas que se renderizan de forma nativa en la app de Telegram.

Aquí tienes un ejemplo de cómo estructurar y mandar un reporte que contiene una tabla de estados y un bloque colapsable para logs de error:

# /usr/local/bin/send-report.cr
require "http/client"
require "json"

BOT_TOKEN = "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
CHAT_ID = "987654321"

# Plantilla HTML que entiende el motor Rich HTML de Telegram
rich_html = <<-HTML
<h1>Reporte del Servidor srv01</h1>
<hr/>
<p>Estado de los servicios críticos de la infraestructura:</p>
<table bordered striped>
  <tr><th>Servicio</th><th>Estado</th></tr>
  <tr><td>Nginx Webserver</td><td>🟢 Activo</td></tr>
  <tr><td>MariaDB Cluster</td><td>🟢 Activo</td></tr>
  <tr><td>Podman Daemon</td><td>🔴 Inactivo</td></tr>
</table>
<br/>
<details>
  <summary>Ver logs de error de Nginx</summary>
  <pre>2026/07/06 15:30:12 [error] 1234#0: *5 open() "/var/www/html/favicon.ico" failed</pre>
</details>
HTML

payload = {
  chat_id: CHAT_ID,
  rich_message: {
    html: rich_html
  }
}

response = HTTP::Client.post(
  "https://api.telegram.org/bot#{BOT_TOKEN}/sendRichMessage",
  headers: HTTP::Headers{"Content-Type" => "application/json"},
  body: payload.to_json
)

puts "Respuesta: #{response.status_code} - #{response.body}"

Tip

Usa el método sendRichMessageDraft para streamear salidas de terminal largas o procesos lentos en tiempo real con la etiqueta animada <tg-thinking>. ¡Parece magia!

Conclusión

A final de cuentas, los bots de Telegram dejaron de ser solo una herramienta recreativa para convertirse en una interfaz de control de sistemas sumamente flexible. La neta, integrarlos en tus scripts de administración te ahorra un montón de desveladas y te da el control de tu infraestructura en la palma de tu mano.

¿Y tú, ya usas Telegram para monitorear tus servidores o sigues dependiendo del correo?

From June 29 to July 05

Posted by Aurélien Bompard on 2026-07-06 06:59:00 UTC

Across the various Fedora working groups, the primary focus is actively preparing for the upcoming Fedora 45 release cycle, marked by a large influx of system-wide Change Proposals such as GNU Toolchain updates, Fontconfig 2.18, and the transition to oo7 as the default secrets provider. Concurrently, a major infrastructure modernization effort is underway, with multiple teams—including Infrastructure, Release Engineering, and Docs—coordinating the final stages of the repository migration from Pagure to Forgejo, alongside the adoption of Konflux for unified container builds and Zabbix for system monitoring. On the governance front, leadership has indefinitely paused the Community Initiatives process to design a new Technology Innovation Lifecycle (Sandbox) for incubating large, experimental features. Despite the resulting closure of the AI Developer Desktop proposal, artificial intelligence remains a strong technical focus across the project, with groups exploring local LLM integrations like the "Anthony" voice assistant and expanding AI/ML framework packaging. Finally, security and compliance are key priorities, as teams ramp up policy preparations for the EU Cyber Resilience Act (CRA) and push necessary incompatible package updates to mitigate high-severity vulnerabilities.

Announcements

The Fedora Council has paused the Community Initiatives process, closing the AI Developer Desktop proposal until a new strategic direction mechanism is designed, and is actively seeking community feedback on a proposed Technology Innovation Lifecycle Process (this statement was also cross-posted to the announce and devel-announce lists). In community news, the F44 Election Results have been announced for the Council, FESCo, Mindshare, and EPEL Steering Committee. Additionally, maintainers are urged to review the list of long-term FTBFS (Fails To Build From Source) packages scheduled for retirement in early August ahead of the Fedora 45 branch so they can be fixed or exempted.

A large batch of Change Proposals has been submitted for Fedora 45. System and security updates include enabling Shadow Stack by default on x86_64, switching to oo7 as the default Secrets Service Provider to replace KWallet and GNOME Keyring, and disabling DNF5 vendor changes by default to prevent unexpected package overwrites in multi-vendor setups. Core software updates feature a GNU Toolchain update (GCC 16.2, glibc 2.44, binutils 2.47, GDB 17.2), Ruby on Rails 8.1, and Fontconfig 2.18. Finally, user experience improvements are proposed with Stratis Storage support in Anaconda and a highly customizable Bash Color Prompt 1.0.

Council

The Council made a significant shift in project governance this week by suspending the Community Initiatives process indefinitely. As a result, the Fedora AI Developer Desktop Initiative proposal was closed, though contributors are strongly encouraged to continue this work through collaborative spaces like the AI/ML SIG. Leadership is now directing community feedback toward the proposed Fedora Innovation Lifecycle (Sandbox) to establish a better framework for incubating large, experimental features. In other news relevant to the broader Linux ecosystem, the Council officially approved extending the "Fedora Atomic" branding to encompass Fedora's bootable container base images.

To improve contributor engagement and clarity, a new community policy document was merged to help manage user expectations around volunteer response times. The Council also finalized the F44 Council election interview questions, shifting the focus toward candidates' strategic visions and governance experience. Furthermore, new discussions are underway regarding improvements to Fedora's public-facing presence to better attract new contributors, alongside a forum thread clarifying trademark guidelines for regional community sites migrating their infrastructure.

Learn more about the Council team.

FESCo

This week, FESCo reviewed a large batch of Fedora 45 Change Proposals, including updates to the GNU Toolchain, LLVM 23, Ruby on Rails 8.1, Fontconfig 2.18, Bash Color Prompt 1.0, and libxml2. Major system-wide feature discussions included enabling Shadow Stack by default on x86_64, disabling DNF5 vendor change by default, switching the default secrets service provider to oo7, and adding Stratis storage support in Anaconda. The committee also debated policy and infrastructure topics, such as the upcoming Forgejo distgit migration, handling pre-built binary content in node_modules, and whether to drop signoff requirements from the defunct Fedora crypto team to unblock modern cryptography libraries like aws-lc.

In terms of contributor engagement and process, FESCo is looking for volunteers to co-own an upcoming Change Proposal to make 2FA mandatory for all packagers. During their weekly meeting, members clarified that the proposed "technology innovation lifecycle" (sandbox) process is not intended to bypass FESCo approval. Finally, the non-responsive maintainer process was initiated for the ledger package, opening the door for new co-maintainers to take over.

Decisions

  • Council Representative: It was agreed that decathorpe will continue as FESCo's Council representative until the end of his current term.
  • ELN Draft Builds: FESCo approved permitting the ELNBuildSync (EBS) service to use draft builds in Koji sidetags inherited from eln-build for ELN rebuild batches. The Kojihub policy will be updated to grant the eln-buildsync user permissions to tag and promote these draft builds.

Learn more about the FESCo team.

Mindshare

This week, the Mindshare group discussed using Fedora trademarks with 3rd party projects. A representative from the Polish Fedora community, which has been active since 2003, sought guidance on compliance regarding their fedora.pl domain, automated emails, logos, and favicons after losing their infrastructure sponsor. Respondents directed the inquiry to the official Fedora trademark guidelines, highlighting that the community's usage likely falls under the allowable provisions for "Community Sites and Accounts."

Learn more about the Mindshare team.

Workstation / GNOME

The Fedora Workstation Working Group discussed "Anthony," a voice-driven desktop assistant utilizing local large language models (LLMs) for task automation and accessibility. The team explored hardware constraints, security improvements—such as transitioning from TCP ports to D-Bus portals for flatpak sandboxing—and leveraging existing accessibility trees. Contributors are encouraged to test the project and help with internationalization efforts by aligning it with IBus speech-to-text initiatives. Additionally, the upcoming Fontconfig 2.18 release was noted, which may require a rebuild of all font packages due to cache format changes.

On the forums, a community proposal to merge GNOME Software and DNFdragora into a single, unified package manager for all Fedora editions was met with skepticism. Respondents highlighted that GNOME Software must remain distro-agnostic, the merger would not suit environments like KDE Plasma, and maintaining a strict separation between GUI application management and CLI package management remains the preferred, less confusing approach for users.

Decisions

  • The group decided to explore integrating the Anthony voice control project into Fedora Workstation as a default feature.
  • A dedicated meeting will be organized to discuss collaboration between the Anthony project and general IBus speech-to-text efforts.
  • The regular meeting schedule will be paused for the month of July to accommodate summer travel and the GUADEC conference, with plans to reconvene in August.

Learn more about the Workstation / GNOME team.

Server

The Server Working Group met on July 1, 2026 to coordinate early testing for the upcoming Fedora 45 release and to advance the new Fedora Home Server spin-off. To proactively catch virtual machine and networking issues, the team is starting F45 Rawhide testing ahead of schedule, with an immediate focus on VM images and NFS client connections. A dedicated project board will soon be established to organize these F45 testing efforts, providing a clear and accessible way for community contributors to get involved.

Significant progress was also made on the Fedora Home Server spin-off. The group finalized the core application stack for the upcoming alpha release, prioritizing essential home lab services, privacy, and self-hosted management. Furthermore, the team discussed the image development process, comparing KIWI and Image Builder. To lower the barrier to entry for new contributors, they opted for a local-first development philosophy, ensuring anyone can build and test the spin-off images on their own machines.

Decisions

  • The alpha version of the Fedora Home Server spin-off will initially include Samba, NFS, Mail service (IMAP/POP3 storage), Cockpit, Calendar and to-do server, Apache reverse proxy, and Ansible.
  • The working group will use the home server repository to share all configuration data and installation instructions, allowing interested contributors to easily set up their own local image development environments.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team focused heavily on monitoring modernization, officially removing Nagios and Collectd in favor of Zabbix, while actively refining Zabbix triggers, predictive disk space checks, and SLA structures. Significant progress was also made on OpenShift migrations, including standardizing openshift-apps playbooks to use a new deployment role and migrating ELNBuildSync. Routine maintenance continued with careful RHEL 10 virthost reinstalls to avoid outages, and testing Forgejo 15.0.3 in staging. The team also resolved several minor service disruptions, including a Postorius 500 error caused by missing email bodies and Anubis proxy lockouts.

In the forums, a helpful discussion clarified the roles of Bugzilla, Forgejo, and Dist-Git for users confused by the ongoing transition away from Pagure. Contributors also explored the possibility of shared LLM inference services for community applications like Log Detective, and proposed restoring pre-commit hooks in the infra/ansible repository to gradually improve code quality. For contributors looking to get involved, the ongoing Zabbix template refinements and Ansible playbook conversions offer excellent, low-risk entry points into infrastructure work.

Decisions

  • Nagios and Collectd are officially deprecated and are being removed from Ansible and servers.
  • Pagure.io will become read-only at the end of July, with Fedora-related projects migrating to the new Forgejo instance (forge.fedoraproject.org).
  • Old openQA Proof-of-Concept instances running in AWS will be deleted to save resources.

Learn more about the Infrastructure team.

Release Engineering

The Fedora 45 release cycle is officially ramping up, with the Mass Rebuild scheduled for July 15th and the creation of F47 release signing keys due shortly after. The Release Engineering team is currently reviewing several F45 system-wide changes, including Stratis Storage in Anaconda, Fontconfig 2.18, and disabling DNF vendor changes by default. In broader news, investigations into building a Fedora container base image using Konflux are ongoing, and an updated respin of Fedora 44 featuring Linux kernel 7.1 is planned for the coming weeks.

Infrastructure migrations from Pagure to Forgejo are continuing, prompting active architectural discussions on whether to process fedora-scm-requests using native Forgejo Actions or by extending the existing Toddlers infrastructure. During their weekly meeting, the team also clarified procedures for stalled EPEL requests and coordinated prep work for the upcoming mass rebuild. Furthermore, a significant pipeline improvement was unblocked when FESCo approved a policy to allow draft builds for ELN, which will allow the ELNBuildSync process to safely restart after crashes without prematurely consuming NVRs.

Decisions

  • FESCo approved a policy permitting the ELNBuildSync service to use draft builds in Koji sidetags inherited from eln-build for ELN rebuild batches (Ticket #13374).
  • The team clarified that users requesting to take over stalled EPEL packages must already be official package maintainers (in the FAS packager group) before they can be added as repository collaborators (Meeting).

Learn more about the Release Engineering team.

Quality

The Quality team saw active discussions and tool developments this week, highlighted by a community proposal to eliminate Fedora's version numbering in favor of automatic, version-less updates. The community largely pushed back on the idea, noting that the current release model is necessary for users who prefer to delay updates for stability, and that rolling-release alternatives already exist. In broader ecosystem news, a new GTK4 frontend for DNF5 called DNF UI has reached its 0.3.x series and is actively seeking user feedback. Behind the scenes, Quality Engineering (QE) advanced their compose-critical package script to an MVP state, progressed on the Dist-git PR test feature, and investigated significant bugs, including a grub2 issue breaking image builds and a haveged update causing boot failures.

There are several immediate opportunities for contributors to get involved in testing. The team is calling for participation in the Linux Kernel 7.1 Test Days (running June 28 to July 4) for Fedora 43 and 44, which was also announced on the test mailing list. Additionally, testers are invited to validate the latest Fedora 45 Rawhide 20260630.n.0 nightly compose to help ensure the stability of upcoming releases.

Learn more about the Quality team.

Design

The Design team is finalizing the F45 default wallpaper following the end of its feedback period, and is actively working on several branding initiatives, including simplified icons for Fedora Messaging tools, Artemis, and various Matrix bot avatars. Infrastructure and asset management were also key topics, with discussions on migrating the fedora-logos package from pagure.io and whether to archive old Community Blog and Fedora Magazine image repositories. Additionally, preparations are underway to automate Flock 2026 YouTube thumbnails using Inkscape extensions and schedule data.

A major focus this week is the development of a Contributor Onboarding Video Series to help newcomers navigate Fedora's systems. To make these videos more authentic, the team has launched an open call for horizontal video footage from past Fedora events to replace stock assets. Contributors are also invited to help design Community Personas that visually represent different types of Fedora participants, offering a highly creative way to get involved.

Decisions

  • Community Event Footage: The team aligned to solicit horizontal video footage from Fedora events via an open call on Fedora Discussions to replace stock assets and enhance future video content.
  • Icon Design Refinement: The Datagrepper interface icon will be simplified, moving away from complex line art to utilize color blocks and shading for improved visual clarity at smaller sizes.

Learn more about the Design team.

Docs

The Fedora Docs team is actively modernizing its infrastructure and continuous integration pipelines. A major focus is refactoring the local preview script (docsbuilder.sh) and exploring a shared Forgejo Actions workflow that utilizes a pre-built container image to enable fast, cross-referenced CI builds for individual pull requests. To address security issues in outdated containers, the team plans to transition container builds to Konflux and Quay.io, aligning with broader Fedora infrastructure practices. Additionally, the team is finalizing its migration to Forgejo ahead of the July 31 Pagure.io sunset, investigating monitoring solutions for staging build failures, and evaluating tools like CryptPad for collaborative draft writing.

To better distribute documentation maintenance and empower subject matter experts, the team launched a "Fedora Docs Captain" pilot program to embed documentation liaisons within specific groups, starting with the Kernel, Multimedia, and AI/ML SIGs. There are immediate opportunities for contributors to help refactor multiple contribution guides—including those for Quick Docs and new modules—to emphasize the modern local authoring workflow. The team is also working to unblock and refine the documentation translation processes alongside the localization team.

Decisions

  • Repository PR and Forking Guidelines: During the June 30 meeting, the team agreed that pull requests should normally be submitted via a fork, particularly for changes requiring lengthy discussion and refinement. However, organization owners and content owners who maintain an article on an ongoing basis may submit pull requests from upstream branches or push directly. Repository settings will be adjusted to enforce branch protections, ensuring only owners can push to main and requiring at least one review approval before merging.

Learn more about the Docs team.

Internationalization

In a recent discussion, returning contributor Javier Blanco inquired about the current activity levels on the translation mailing lists. The community welcomed him back and clarified that the mailing lists are currently quiet because the majority of localization work is now handled upstream, with contributors often utilizing alternative communication channels such as Matrix and forums.

To provide deeper context on the state of the localization community, Jean-Baptiste shared two presentations detailing the structural health and tooling of open-source translation efforts. These included an analysis of language community health using 20 years of Fedora translation data and a proposal for new tools to improve translator efficiency. Contributors interested in improving localization workflows and community collaboration are encouraged to review these resources.

Learn more about the Internationalization team.

EPEL

This week, the EPEL team focused heavily on addressing security vulnerabilities through necessary incompatible updates and package retirements. Notably, caddy was updated across multiple branches to resolve 22 CVEs, and an incompatible update for routinator was proposed to address several high-severity vulnerabilities. Contributors are also discussing a proposal to drop the rust-rpki binary subpackage to simplify package maintenance. Furthermore, early planning discussions for EPEL 11 have begun, with current conversations centering around the challenges of maintainer ownership and content resolver workflows.

Decisions

Learn more about the EPEL team.

ELN

The ELN SIG meeting on June 30, 2026, was brief due to low attendance and participants being occupied with other tasks, such as debugging EBS with Fedora Infrastructure. Consequently, no major subjects were discussed, and no formal decisions were made during this session.

For those looking to engage with the group, contributors are encouraged to bring topics for discussion to the next scheduled meeting, which will take place on Tuesday, July 7, 2026, at 12:00 EDT.

Learn more about the ELN team.

Atomic

The Fedora Atomic Initiative discussed a draft Change Proposal to unify all atomic and bootc variant pipelines into a single monorepo using Konflux. This consolidation aims to streamline infrastructure across teams by establishing a shared atomic tenant for bootc base images, Atomic Desktops, and potentially Fedora CoreOS. To manage the scope and avoid disrupting existing workflows, the migration will be iterative. The immediate focus is moving bootc images to the new forge to verify builds, which will be followed by dedicated change requests for official artifact signing and the broader pipeline unification.

In community discussions, interest continues to build around the proposal to create a systemd-sysexts SIG. This initiative presents a great opportunity for contributors to help design the official building, distribution, and documentation of systemd system-extensions, which are crucial for extending atomic systems with software that doesn't run well in containers or Flatpaks.

Decisions

  • The team agreed to pursue a unified atomic Konflux tenant and monorepo to house current bootc base images, Atomic Desktops, and potentially future variants.
  • The pipeline unification will be broken down into smaller, sequential change requests, starting with migrating bootc images to the new forge and establishing artifact signing before fully transitioning other variants.

Learn more about the Atomic team.

CoreOS

In the CoreOS meeting, the team reviewed upcoming Fedora 45 changes, noting that a GoLang update and an RPM 6.1 version bump will require dedicated tracking issues and investigation, while the adoption of PURL metadata is not expected to affect Fedora CoreOS. Contributors interested in packaging can engage with the ongoing work to support passing Butane configs directly to instances, which prompted a restructuring of how Ignition and Butane are maintained. For the broader Linux community, Podman 6.0 has officially landed in Rawhide and is ready for testing. Additionally, the forum proposal to create a systemd-sysexts Special Interest Group (SIG) continues to gather support from developers interested in building and distributing systemd system-extensions.

Decisions

  • The team agreed to combine the Ignition and Butane spec files, making Butane a subpackage of Ignition and archiving the standalone Butane spec.

Learn more about the CoreOS team.

AI & ML

During their July 2nd meeting, the AI & ML SIG discussed upcoming packaging and testing plans, noting that the ollama 0.30.x update will likely be delayed until Fedora 46 due to upstream instability with llama-cpp. The group is actively seeking testing and packaging help to diversify supported llama-cpp backends, particularly for the upcoming Vulkan transition. In broader community news, there is an active proposal to evolve the SIG into the "Fedora AI Working Group" to better reflect its expanding scope in both hardware enablement and open AI best practices. Additionally, there is a large backlog of open tickets for packaging major AI frameworks and tools—including TensorFlow, Bazel, and various Python libraries—alongside early discussions about proposing a dedicated Fedora AI Spin and building hardware-enabled inferencing images.

To boost contributor engagement, the SIG is revamping its documentation to create a more welcoming onboarding experience and is forming a new "Skills Reviewers" sub-team to curate shared AI skills using the Agent Skills specification. The group also addressed the management of donated AMD GPU nodes (like gpu01), emphasizing the need for public documentation to clarify hardware allocation and CI usage. This initiative aims to ease bureaucratic friction, provide transparency on how community hardware is utilized, and make it easier for contributors to understand how they can leverage these resources.

Decisions

  • @jflory7 will open a ticket to propose a new "Hardware" module for the documentation site to track and manage hardware donated for Fedora Infrastructure.
  • @jflory7 will chair the next SIG meeting on July 16, 2026.

Learn more about the AI & ML team.

RISC-V

The RISC-V group focused heavily on expanding infrastructure and hardware support this week. Discussions are underway with the cloud vendor Scaleway to host potential Fedora Koji builders in their Paris datacenter, an effort being coordinated through RISE. Hardware availability for developers is also improving: the newly released Milk-V Titan boards are currently shipping to RISC-V engineers for Fedora use, which will further aid platform optimization and broader Linux ecosystem integration.

On the software front, active development continues on the Fedora Omni kernel to expand support for devices like the Muse Pi Pro and K3, while steady progress is being made on the Fedora RISC-V tracker. To avoid disruptive surprises, contributors should note ongoing 'fedora-devel' discussions regarding potential improvements to the Changes Process, as well as internal deliberations about implementing two-factor authentication (2FA) for packagers.

Decisions

  • It was decided to provision an additional "K3" hardware unit (sponsored by CLE) to maintainer DavidA to serve as a new Fedora RISC-V Koji builder.

Learn more about the RISC-V team.

Security

The Security SIG held a meeting this week to welcome new members from Red Hat's Product Security and Open Source Office. The expanded team will focus on navigating the upcoming EU Cyber Resilience Act (CRA) and implementing practical, developer-centric security measures. The group also initiated a debate on the scope of the Security Docs repository, specifically whether it should consolidate all Fedora security topics or strictly house documentation actively maintained by the SIG to prevent stale content. This documentation discussion will continue in upcoming meetings.

For contributors looking to get involved, the SIG noted that help is needed with defining security policies, which are obligatory for the CRA Steward role. Community members can follow the published meeting agendas to see when topics of interest are being discussed or drop into open office hours to participate.

Decisions

  • Agendas for upcoming meetings will be published in advance. If there are no agenda items, the scheduled time will serve as informal open-floor office hours.
  • Formal decisions within the SIG now require a quorum of at least three member votes.

Learn more about the Security team.

Go

During the Go SIG meeting, members discussed the upcoming Go release and shared that a mass prebuild of Go 1.27rc1 has been completed; contributors are encouraged to review the prebuild results report to catch any potential regressions. The team also highlighted ongoing work on a new Go utility designed to test Kubernetes installations locally on VMs, which will help validate new Fedora Kubernetes releases (like 1.36) before deployment. Furthermore, participants praised Fedora's current approach to vendored Go packages, noting it provides a smoother packaging experience compared to other ecosystems.

In terms of packaging standards, the SIG reviewed Issue #67 regarding CGO_CFLAGS. A contributor proposed establishing default values for these flags that are consistent with Fedora's standard build practices, as some packages currently require manual configuration to build correctly. The team will investigate past configurations and work toward defining sensible defaults that packagers can easily override if necessary.

Learn more about the Go team.

Perl

This week's activity in the Perl group centered around package maintenance and compatibility pull requests. Notably, a pull request for perl-Module-Starter-Plugin-CGIApp was submitted to fix compatibility with Module::Starter 1.80+ author arrayrefs. Additionally, contributors opened PRs to prevent building Class::Storage::Debug in bootstrap mode for perl-SQL-Abstract and to utilize -any virtual provides for MariaDB/MySQL dependencies within perl-Test-mysqld.

Decisions

  • The maintainer for perl-Module-Starter-Plugin-CGIApp decided against adopting the %autorelease and %autochangelog macros, requesting their removal from the pending compatibility pull request.

Learn more about the Perl team.

Rust

Michel Lind submitted a Request for Comments (RFC) to drop the rpki binary subpackage from the rust-rpki crate. These unneeded programs were accidentally shipped due to a bug in older versions of cargo2rpm (< 0.3.0) and unnecessarily complicate package maintenance by requiring frequent license audits for statically-linked dependencies.

Since the crate is currently only used by routinator, Lind proposed retiring the binary packages to simplify ongoing maintenance. As this counts as a package retirement, Lind is seeking clearance on the EPEL side and noted that the removal could be gated to only affect Fedora 45 and newer if required.

Learn more about the Rust team.

Other Discussions

Orphaning packages

Package updates

New contributor introductions

  • Self Introduction: Simone: Simone (tollsimy), a computer engineer with a background in electronics, embedded systems, and cloud infrastructure, introduced themselves and expressed a desire to give back to the Fedora community.

misc fedora bits: start of july 2026

Posted by Kevin Fenzi on 2026-07-04 19:35:58 UTC
Scrye into the crystal ball

"Today's the fourth of july. Another june has gone by."

(appologies to Amiee Mann).

Here's another short recap of the last week from me. I was off Thursday, and Friday was a holiday, and I'm off next monday too, so this was a short week.

aarch64 builders and vmhosts reinstalls

I spend a bit of time reinstalling our aarch64 bvmhosts. These are the machines that run all our buildvm-a64 instances. You would think this would be a trivial task, but of course not.

When we got these machines as part of the datacenter move last year, we couldn't get them to pxe boot from their 25G network. So, we ended up patching some 1G connections to them to provision them. Then those links were removed. So, I needed to fix the issue this time.

Turned out it was just some settings in the network card eeprom/settings. To adjust it, I had to build a kernel module, load that, then poke at the settings with a tool. Quite a pain, but luckily only a one time thing.

After that, they pxe booted fine and were easy to reprovison with rhel10. Except, then I hit the next thing: One of them had a bad memory stick in it. We had hit this before, but after reseating all the memory it came up ok, but that memory just decided to croak this time.

So, dc operations folks did a bunch of testing and isolated the bad memory. Should be on the way in to get a replacement now. Until the replacement arrives that machine is down memory, so a few buildvm's on it are shutdown. Shouldn't matter too much.

Staging openshift workers network

Last week we moved a number of servers to balance power in racks. That went fine, but networking folks noticed that 3 of the machines were not properly using 802.3ad/lacp. That is, they were only connected on one interface. These machines were our staging openshift workers.

It took me quite a lot of poking around to see what happened and how to fix it. Openshift has a lot of ways it configures network and it was not clear at all to me the flow. I did finally figure it out though: I had installed them with net.ifnames=0 set. This meant they had eth2 and eth3 interfaces that were the active ones. After the install, they booted without that and so the interface names changed. The new ones didn't have any config, so it just picked the first one and ran it's ovh setup on. So, I had to go in and setup NetworkManager to know about the new interface names so it would bond them, then the openshift setup script would just take that bond device and setup on it.

I wish openshift made it easier to tweak this.

Off on monday, see everyone tuesday!

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

Transmission: Córrelo como servicio de usuario

Posted by Rénich Bon Ćirić on 2026-07-03 16:45:00 UTC

Hoy me dió por tener corriendo mi daemon de BitTorrent preferido: Transmission, como un servicio de sistema. La neta, correrlo de manera global con el usuario transmission por defecto está chido si estás en un servidor dedicado, pero en mi compu personal (mi Fedora 44 de diario) es una lata. Yo quería que leyera mis configuraciones locales, que las descargas cayeran directo en mi carpeta personal (~/Downloads/torrents) y, sobre todo, que se levantara nomás cuando yo inicio mi sesión de usuario.

Así que me di a la tarea de crearle un servicio de usuario a nivel de systemd para quitarme de broncas. Aquí te cuento de volada cómo lo armé pa' que no le batalles.

Procedimiento

Para lograr que jale como un servicio local y lea tus configuraciones de usuario, el proceso está bien pleada. Nomás sigue estos pasos:

  1. Crear el archivo de servicio de usuario: En lugar de modificar el archivo global en /usr/lib, copié la base del servicio y creé un archivo local en tu $HOME.

    # ~/.config/systemd/user/transmission-daemon.service
[Unit]
Description=Transmission BitTorrent Daemon
Wants=network-online.target
After=network-online.target
Documentation=man:transmission-daemon(1)

[Service]
Type=notify-reload
ExecStart=/usr/bin/transmission-daemon -f --log-level=error -g %E/transmission

# Hardening
CapabilityBoundingSet=
DevicePolicy=closed
KeyringMode=private
LockPersonality=true
NoNewPrivileges=true
MemoryDenyWriteExecute=true
PrivateTmp=true
PrivateDevices=true
ProtectClock=true
ProtectKernelLogs=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectSystem=true
ProtectHostname=true
ProtectKernelTunables=true
ProtectProc=invisible
RestrictNamespaces=true
RestrictSUIDSGID=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictRealtime=true
SystemCallFilter=@system-service
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM

[Install]
WantedBy=default.target

    Note

    Le quité la directiva User=transmission porque los servicios de usuario de systemd ya corren con tu propio UID de cajón. Además, agregué la opción -g %E/transmission (usando el especificador de systemd %E que apunta al directorio raíz de configuración del usuario, que por defecto es ~/.config o el valor de $XDG_CONFIG_HOME) para que lea los mismos archivos que usa la interfaz gráfica (GTK) de Transmission y no se me haga un desmadre con directorios separados.

  2. Recargar systemd y arrancar el servicio: Una vez guardado el archivo, dile a systemd que recargue tu configuración de usuario y levanta el daemon de volada.

    systemctl --user daemon-reload
systemctl --user enable --now transmission-daemon.service

  3. Evitar que se te sobreescriban los cambios: Si necesitas cambiar alguna configuración en el settings.json (por ejemplo, habilitar la interfaz web o el RPC), ten mucho cuidado. Si editas el archivo con el daemon corriendo, al momento de reiniciarlo o apagar la compu el daemon va a vaciar su estado en memoria y te va a mandar tus cambios a la chingada.

    Para evitar esto, el flujo correcto es detener el servicio antes de meterle mano al archivo:

    systemctl --user stop transmission-daemon.service

# Edita tu ~/.config/transmission/settings.json ahora sí

systemctl --user start transmission-daemon.service

¿Cómo quedó el cotorreo?

Una vez que el daemon arranca con la ruta de tu configuración local, la integración es transparente y bien chingona:

  • Descargas automáticas: Todo cae directamente en tu directorio configurado (por ejemplo, ~/Downloads/torrents).
  • Directorio de monitoreo: Si dejas caer un archivo .torrent en la carpeta de watch (en mi caso, la misma carpeta de descargas), el daemon lo detecta y lo empieza a bajar de volón.
  • Control Remoto: Como habilité el RPC, puedo administrar mis descargas desde el navegador entrando a http://localhost:9091/ o usando clientes como transmission-remote-gtk sin que me consuma recursos tener la interfaz gráfica de Transmission abierta todo el día.

Warning

¡Cuidado con correr ambos al mismo tiempo! Si tienes el daemon activo en segundo plano e intentas abrir la interfaz gráfica de Transmission (GTK), van a chocar por el puerto de red (generalmente el 51413) y pueden corromper los archivos de estado. Te recomiendo usar la interfaz web o una herramienta remota para controlar el daemon. La ventaja es que te vas a ahorrar un buen de memoria RAM.

Conclusiones

La neta, configurar Transmission como servicio de usuario es un paro enorme si eres de los que deja descargas corriendo en segundo plano pero no quieres configurar un servidor dedicado para eso. Con unos cuantos minutos y systemd de tu lado, dejas tu Fedora 44 bien optimizada y lista para el jale pesado.

¿Cómo la ves? A poco no está bien suave tener el control total de tus torrents sin desmadres de permisos, no?!

Community Update – Week 27

Posted by Fedora Community Blog on 2026-07-03 11:00:00 UTC

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

Week: 29 June – 3 July 2026

Fedora Infrastructure

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

CentOS Infra including CentOS CI

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

Release Engineering

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

  • Continued investigation into building a Fedora container base image using Konflux.
  • Continued work on remaining Pagure -> Forgejo migrations.
  • F45 release cycle is set to begin soon, starting with Mass Rebuild in the middle of July. This will require some prep work next week.

RISC-V

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

  • Discussion with Scaleway (a cloud vendor in France) for potential Fedora Koji builders in their Paris datacenter.  To be coordinated via RISE.
  • Hardware
    • Coordinated shipping another “K3” hardware to DavidA (one of the Fedora RISC-V maintainers). This will be used as another RISC-V Koji builder.  Sponsored by CLE.
    • Milk-V Titan hardware is now available to buy.  A handful of machines are being shipped to a couple of  RISC-V engineers, including for Fedora use.
  • Community work
    • Fedora Omni kernels for Muse Pi Pro hardware discussion with Trevor from Baylibre and Jason (Fedora RISC-V kernel)
    • Marcin (hrw) Juszkiewicz continues to chip away at the Fedora RISC-V tracker
    • Fedora Omni kernel work continues, with support for Muse Pi Pro, K3, and more: Jason Montleon and Jennifer Berringer
  • Other:
    • Discussions on ‘fedora-devel’: “How can we improve the Changes Process?” thread
    • A lot of internal discussion about 2FA for packagers
    • Several internal  and upstreams meetings

AI

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

  • Aurelien Bompard improved the This Week in Fedora script to include the CLE status reports

QE

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

Forgejo

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

  • Forge 15.0.3 in staging
  • New runner for koji organization
  • Continued work on Private Issues: public/private comments
  • Zabbix template developed to monitor health of runnerhost VM, moving onto the  forge instance next.

EPEL

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

  • Updated caddy in f44, f43, epel10.3, and epel10.2 resolving 22 CVEs
  • EPEL 11 planning discussions

UX

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

  • Open Call for Fedora Event Video Footage! [discussions post]
  • Feedback period for F45 wallpaper has just ended. Here is the current iteration.

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

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

🎲 PHP 8.6 as Software Collection

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

Version 8.6.0alpha1 has been released. It's still in development and will soon enter the stabilization phase for the developers and the test phase for the users (see the schedule).

The RPMs of this upcoming new version of PHP 8.6, are available in remi repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) in a fresh new Software Collection (php86) allowing its installation beside the system version.

As I (still) strongly believe in SCL's potential to provide a simple way to allow installation of various versions simultaneously, and as I think it is useful to offer this feature to allow developers to test their applications, to allow sysadmin to prepare a migration or simply to use this version for some specific application, I decide to create this new SCL.

I also plan to propose this new version as a Fedora 46 change (as F45 should be released a few weeks before PHP 8.6.0).

Installation :

yum install php86

⚠️ To be noticed:

  • the SCL is independent from the system and doesn't alter it
  • this SCL is available in remi-safe repository (or remi for Fedora)
  • installation is under the /opt/remi/php86 tree, configuration under the /etc/opt/remi/php86 tree
  • the FPM service (php86-php-fpm) is available, listening on /var/opt/remi/php86/run/php-fpm/www.sock
  • the php86 command gives simple access to this new version, however, the module or scl command is still the recommended way.
  • for now, the collection provides 8.6.0-alpha1, and alpha/beta/RC versions will be released in the next weeks
  • some of the PECL extensions are already available, see the extensions status page
  • tracking issue #342 can be used to follow the work in progress on RPMS of PHP and extensions
  • the php86-syspaths package allows to use it as the system's default version

ℹ️ Also, read other entries about SCL especially the description of My PHP workstation.

$ module load php86
$ php --version
PHP 8.6.0alpha1 (cli) (built: Jun 30 2026 11:28:16) (NTS gcc x86_64)
Copyright © The PHP Group and Contributors
Built by Remi's RPM repository  #StandWithUkraine
Zend Engine v4.6.0-dev, Copyright © Zend by Perforce
    with Zend OPcache v8.6.0alpha1, Copyright ©, by Zend by Perforce

As always, your feedback is welcome on the tracking ticket.

Software Collections (php86)

🛡️ PHP version 8.2.31, 8.3.31, 8.4.21 and 8.5.6

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

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

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

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

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

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

ℹ️ The packages are available for x86_64 and aarch64.

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

Version announcements:

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

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.5 as Software Collection

yum install php85

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

On Enterprise Linux (dnf 4)

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

On Fedora (dnf 5)

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

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

⚠️ To be noticed :

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

ℹ️ Information:

Base packages (php)

Software Collections (php83 / php84 / php85)

🎲 PHP version 8.4.23RC1 and 8.5.8RC1

Posted by Remi Collet on 2026-06-19 03:59:00 UTC

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

RPMs of PHP version 8.5.8RC1 are available

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

RPMs of PHP version 8.4.23RC1 are available

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

ℹ️ The packages are available for x86_64 and aarch64.

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

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

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

Update of system version 8.4:

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

ℹ️ Notice:

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

Software Collections (php84, php85)

Base packages (php)

⚙️ PHP version 8.4.22 and 8.5.7

Posted by Remi Collet on 2026-06-05 04:40:00 UTC

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

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

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

ℹ️ The packages are available for x86_64 and aarch64.

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

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)

 

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

Securing agentic identity

Posted by Matthew Garrett on 2026-07-03 00:38:23 UTC

As is the case for many people working in the security industry, the last few months of my life have been focused on dealing with people wanting to use LLMs everywhere. From an enterprise security perspective that’s not an inherent problem - what’s more of a problem is that people want those agents to have access to resources like their calendar and email and so on, and now we have somewhat non-deterministic agents that seem very enthusiastic to achieve what you asked whether that’s a good idea or not, and we’re combining this with credentials that give them access to sensitive data, and leaving those credentials on disk where they can be committed into git repos or exfiltrated to some other service to make use of them on the agent’s behalf or well just any other number of things, at which point your CEO’s email is suddenly readable by everyone and you’re having a bad day.

As I mentioned in my last post, pretty much every strong mechanism for keeping credentials in place is just not supported in the wider world. We can imagine a universe where agents use hardware (or at least hypervisor) backed certificates to obtain credentials and any that end up leaking are worthless as a result. But, sadly, that’s not an option for most people using existing identity providers. The state of the art is that you use the device code flow and a human authenticates and the token ends up back inside the agent environment and then it proceeds to do whatever it wants with it and you just hope that you wake up the next morning without an awful infoleak occurring.

(An aside: I do not like the device code flow as used in enterprise environments, and I never will. The identity provider doesn’t have a real opportuity to inspect the security posture of the system asking for the token, and as a result some identity providers will restrict tokens that are issued in this way. The common alternative of doing stuff using a more standard flow and having a redirect URI pointing at localhost works fine for local systems and is a pain for remote ones, even if you can commit crimes with SSH forwarding. I’m going to suggest something that I think is better, and you are free to disagree)

I’m not in a position to get every identity provider and service provider to change their security posture, so I’m somewhat stuck in terms of the tokens they’re willing to issue me - largely either JWTs or opaque access tokens, with no support for any mechanism of binding that token to an instance. The token that’s going to have to be provided to the remote service is something I have little influence over. But that doesn’t mean I can’t influence the token that lands inside the agent’s environment. I can issue a placeholder token to the agent, and force it to communicate via a proxy that swaps out the placeholder for the real thing. The worst the agent can do is exfiltrate the placeholder token, and as long as malicious actors don’t have access to that proxy, it doesn’t matter - nobody else can do anything with the placeholder.

This isn’t a terribly novel insight, and it seems like almost everybody has reinvented this on their own. But a lot of these implementations involve you somehow obtaining the real token in advance and then pasting that into something that generates a placeholder that you provide to your agent environment somehow, and it’s all a bit clunky and awkward, and it also means that you need to deal with something that keeps track of the mapping between placeholders and real tokens and oh no we’ve just invented a secret store, and if you want this to work at scale and reliably you’re just invented a high availability distributed secret store, and a lot of people who’ve read that are now shaking their heads and reaching for gin. Can we simplify this, and improve security at the same time? I think we can!

Remember when I said “as long as malicious actors don’t have access to that proxy, it doesn’t matter”? What if they do? What if they compromise one machine inside your environment and are then able to email a bunch of employees and convince their agents to send more tokens back to them and then delete the email before a human reads it? Now you have someone inside the wall with access to those tokens, and presumably with access to the proxy, and now they can be anyone whose agent was gullible enough to think sending them a token was a good idea. This isn’t good!

So, I thought for a while, and I came up with a new idea. We can have a broker service that obtains credentials for us. We can run that centrally, away from the agents. A client in an agentic environment can request a token, and that can result in a URL being generated and the user being directed to open a URL in a browser and authenticate. When the user authenticates, the authentication flow redirects the confirmation back via the broker, and the broker obtains the real auth token. The obvious thing to do now would be to return the auth token to the client in the agentic environment, but we don’t do that. Instead, we mint a new JWT, and add a new claim - one that contains an encrypted copy of the token. In the process we can copy over all the original claims, because those aren’t secret - and now even if the client inspects the token to figure out what access it has, it’ll get a correct answer. We sign the new token with our own signing key, and pass that back to the client. The client now has a legitimate JWT that is utterly useless, because the signature isn’t trusted by anyone other than us.

How does it use it? It makes an API request via a proxy, including the new token in the Authorization: header. The proxy verifies the signature on the token, and then decrypts the original token and swaps out the fake token for the real one. The remote API sees what it expects, and everyone is happy. There’s never a real token in the agentic environment, but also we don’t need to store anyting anywhere. The only state is the encryption keys, and those can be injected into the environment at startup. You need to scale? Just start more of these processes. You need to support multiple availability zones? Just start more of these processes in different places. No persistent data is ever held in the broker or the proxy. You don’t need to care about distributed databases or secret stores.

This felt wonderfully elegant and I felt smug about coming up with a better idea, and then I went to a bar earlier this week and sat down to read RFC 8705 and the guy next to me saw that over my shoulder and asked what I was reading and I explained why I was interested and we talked about agentic identity and then he mentioned that fly.io had something that sounded very similar and I read that and gosh yes it is very similar, so damn you fly.io for stealing my ideas 3 years before I even had them. Anyway. Now I need to do better.

Remember that there’s still a risk around anyone who has access to the proxy having access to the encrypted keys? We can remove that risk as well. It’s not uncommon for agentic environments to have an identity issued via something like SPIFFE, at which point they have a client certificate. You can probably guess where I’m going with this. If we require that an agent present a client cert to the broker when requesting a token, we can embed a representation of that client cert into the token we mint. The proxy can then require mTLS for the client connection, and can verify that the presented certificate matches the one represented in the token. If it does then whoever’s using the token has access to the private key associated with the environment it was issued to. If we then ensure that the private keys backing these certificates are either hardware or hypervisor backed, and as such tied to a specific instance, we now have a high degree of confidence that the token can only be used in its intended environment. Even if our identity provider doesn’t support RFC 8705, we can.

This is fairly straightforward where you’re using a platform where your identity provider is also the environment that’s consuming your tokens, and more annoying for third parties. The broker potentially needs some amount of third party vendor knowledge to make that work for everyone. This is even more the case where login isn’t via your identity provider (thanks, github), but none of this is insurmountable - just annoying. And where vendors issue opaque tokens rather than JWTs, this still isn’t a problem; we can just mint a new JWT that includes the opaque token as an encrypted claim, and include the same certificate binding. The opaque token ends up being the thing that’s presented to the third party, but only after we’ve verified the mTLS binding.

In an ideal world none of this would be necessary - someone would spin up a new agentic environment, a user would prove their identity, and a certificate embodying that identity would be issued to the environment with a private key that can’t be exfiltrated. That certificate would be sufficient to obtain new certificates associated with the same private key, and we could still bind that into mTLS identity. This would be much simpler, but browsers don’t support it, so it’s not likely to happen any time soon.

Anyway. Even if we can’t have the best thing, we can do better than we are at the moment, and also it would be lovely if we could standardise on this rather than have everyone build their own thing. The end.

Friday Links 26-22

Posted by Christof Damian on 2026-07-02 22:00:00 UTC
The Little Mermaid statue on a rock in Copenhagen harbour, with the industrial harbour skyline behind it

Rand’s perspective on All Hands is worth a read this week. I did enjoy the interview with the airline pilot.

Quote of the Week
The first rule is that a measurement—any measurement—is better than none.
High Output Management
Andrew S. Grove

Leadership

In defense of AI mandates (xpost) - interesting perspective. You will lose people obviously, in some way or another.

What size project needs a code of conduct?

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

I’m part of a project that’s been hibernating longer than many projects have existed. As part of awaking from slumber, the project’s leadership decided to adopt a code of conduct. Like me, they believe that it’s a necessary starting point for a community in 2026 (or whatever year you read this) and a rare exception to the “don’t add policies until you need them” rule.

Some people, as is usually the case, questioned the need for a code of conduct this early. The project is small, barely active, and fairly collegial. Why bother? As I’ve written before, planning ahead is the most important part of code of conduct enforcement. The worst time to figure out how to deal with bad behavior in your community is while you’re trying to deal with bad behavior in your community.

But how large does a project really have to be before it needs a code of conduct? I’m tempted to say “one person. Maybe two.” That’s a justifiable answer because a code of conduct defines the acceptable behavior for everyone who interacts with the project. It’s not just for core contributors; it’s for everyone who stops into a chat channel, files an issue, submits a pull request, and so on. As long as there’s one person for someone to interact with, a code of conduct is a reasonable part of the project’s governance.

A better answer might be “three people”. This means that if two people are having trouble, there’s one person to address the issue.

As I said above, a code of conduct should be part of the initial foundation of a project. It’s just as important as git init to building a healthy, sustainable open source community. This means that no project is too small to have a code of conduct.

This post’s featured photo by krakenimages on Unsplash.

The post What size project needs a code of conduct? appeared first on Duck Alignment Academy.

How Flock to Fedora Gets Organized

Posted by Justin Wheeler on 2026-07-02 08:00:00 UTC
How Flock to Fedora Gets Organized

Flock to Fedora is the flagship contributor community event for the Fedora Project. A lot of work goes into Flock, with planning efforts usually kicking off ten months before the conference target dates. This is often the invisible work which the community rarely gets a window into seeing.

This blog post pulls back the curtain on what it actually looks like to organize Flock. It is the second post in a three-part series on Flock to Fedora 2026. The first post covers the highlights of what happened at the event. The third post shares my personal reflections on the experience.

The FCA Role and Flock

Flock to Fedora is a key part of the Fedora Community Architect (FCA) role at Red Hat. It is the flagship event of the Fedora Project community, and all three FCAs before me played pivotal roles in the organization of Flock to Fedora. However, Flock is the only event of its kind that I organize in the calendar year. While I support other events in the Fedora community, I do not take the role of a core organizer in any other event like I do with Flock.

There is a structural tension in the FCA role when it comes to Flock. There are several months of the year where the Flock event planning workload is light, and we are working through small steps at a time. But in the two to three months before Flock, the workload ramps up significantly. The team is working together more often and there are more tasks to coordinate. Meanwhile, the rest of the FCA’s responsibilities — supporting the community, budgeting, coordinating with Red Hat — do not scale down to make room.

This is not a new challenge; it is endemic to the role. All four years I have been involved as a core Flock organizer, this dynamic has been present. Perhaps there is a way to streamline and schedule Flock in a more programmatic way, so certain steps can happen earlier and others can get involved and help out. It is worth noting for anyone who inherits or reshapes this role in the future.

The Flock Organizing Team

Flock to Fedora would be nothing if not for the people who put in the time, effort, love, and care to make it the community event that it is. It is because of the amazing colleagues and teammates in the Flock core planning team that we pull off the high-quality, engaging event we do. I am incredibly grateful to the various folks who contribute various levels of time into the Flock event planning process. So, this section of my post is where I give some sincere thank-yous to Fedora Friends who take up an exceptional share of the planning work. All names are in alphabetical order:

  • Allison d’Amboise: Operations support, sponsorship & legal support

  • Ananya Nalavathu: Foundations Wall, social media support, #CommitHistory interview campaign

  • Aoife Moloney: Event Co-Lead

  • Dorka Volavkova: Event Co-Lead

  • Emma Kidney: Design, print, & brand/identity support

  • Greg Sutcliffe: Matrix virtual experience support

  • Jason Brooks: Operations support

  • Jef Spaleta: Strategic support

  • Jennifer McGinnis: Operations support

  • Jennifer Schimmoller: On-site event support, logistics, and event execution

  • Jess Chitas: Flock website UI/UX improvements

  • Jona Azizaj: Event Co-Lead

  • Joseph Gayoso: Social media support

  • Juliana Furlow: Sponsored Travel coordinator

  • Kevin Fenzi: Matrix virtual experience support

  • Lidija "Lydia" Balija: CfP lead, ops support

  • Madeline Peck: Design, print, & brand/identity support

  • Shaun McCance: Event Co-Lead

A photograph of four smiling Flock to Fedora organizers posing together at the Monday night social reception. They are standing in front of a warmly lit bar area and a large blue Fedora graphic banner. Left to right: Jennifer Schimmoller, Dorka Volavkova, Jona Azizaj, Aoife Moloney.
Figure 1. Four Flock to Fedora organizers standing together and smiling at the Monday night social reception. Y’all are amazing! Left to right: Jennifer Schimmoller, Dorka Volavkova, Jona Azizaj, Aoife Moloney.

There are even more people who have contributed something to Flock. But these are the people who went above and beyond to contribute to the success of the event. I could not do Flock without each and every one of them!

Workflow Experiment: Public Issue Tracking

I also tried out a new approach to public project management for Flock 2026. There is a new Fedora Forge repository under the Fedora Council organization, council/flock. I attempted to use this as a way to track ongoing work and have more public-facing project management to demonstrate what actually goes into executing Flock.

A screenshot of a dark-themed issue tracker for the "council/flock" Fedora Forge repository, displaying a list of seven open and 119 closed tasks. The visible open issues include post-event tasks such as processing reimbursements and publishing session recordings, each detailed with color-coded area and priority labels, the "2026 Post-Event" milestone, progress bars, assignee avatars, and comment counts.
Figure 2. A screenshot of a Fedora Forge issue tracker for the council/flock repository displaying various open and closed Flock 2026 event management tasks.

I rate the use of this experimental repository as a mixed success. Its biggest issue was that it was incorporated late into the planning cycle and I did not involve other Flock team members in the repository workflow. So, it was largely a tool that I used alone. I provided few and sparse updates until May on the various issues.

I did use AI-assisted workflows to help process meeting summaries and transcripts into issue updates. Our Flock 2026 organizer team was already using AI assistance for note-taking and generating transcripts from our regular video meetings. After Flock ended, I used a structured interview format with an AI agent to review all open issues in the Fedora Forge API, answer follow-up questions about their status, and create a record of what was accomplished and what remained.

While this tool was not directly useful to planning Flock 2026, it could be a useful starting point for other tools to analyze, plan, and suggest timelines for various Flock planning and execution work. The final goal in using the repository after Flock 2026 was to get unwritten institutional knowledge into a public issue tracker so it could be referenced in the future when we actually need to look back and remember what we did before and what lessons we learned.

Paperwork: Sponsor Contracts

It is the most boring thing ever, perhaps, but Red Hat Legal approved an updated Flock to Fedora sponsor contract. This is something that me and my colleague Shaun McCance have been working on for years, as part of the CentOS Connect and Flock to Fedora event planning. The challenge with our old sponsor contract was that it had requirements which did not actually make sense for Flock. For example, a sponsor had to provide a proof of insurance with a significant deductible for their event sponsorship. This is actually somewhat standard for corporate events where companies rent big, expensive exhibit booths. But Flock does not have, and never had, sponsor booths. Our community is always too immersed in the hallway track, and we encourage sponsors to send their reps to participate in the hallway track to get more out of their sponsorship.

While the insurance requirement was one of the most notorious challenges, especially for smaller companies and organizations, there were other changes made as well. I will not list them all, but the greatest advantage of this was the ability to bring back some past sponsors due to less corporate verbiage in the contract, and more community-friendly language. We did not add anything new to the contract; we only removed lots of content and sections. All in all, this made our contracts shorter, leaner, more aligned with the actual event we produce, and importantly, easier for other company’s legal teams to review, process, and sign.

We got these updated contracts in January, which was part of why we were delayed somewhat in our sponsor outreach. However, now that we have the updated contract, we can start earlier on the sponsor outreach since we will only have to get an approval next year on a contract update which mostly changes dates, years, and not much else.

More in this series

Preventing token theft

Posted by Matthew Garrett on 2026-07-02 02:23:45 UTC

When you log into a service you’re given an authentication token. Each further request to the site includes that token, allowing the server to figure out who you are and ensuring that you have access to your data. Depending on site policy, this token may either be stored in memory (and so vanish if you restart your browser) or disk. The token is the proof of your identity. As far as the site is concerned, anyone with your token is you. These tokens may be traditional browser cookies, but they may also be stored in either site local storage or (if you’re not using a browser) in some other storage location.

In recent years we’ve seen infostealer malware (like LummaC2) gain the ability to exfiltrate user tokens, allowing attackers to gain access to the user’s data without needing to retain access to the user’s machine. This attack is viable even if the site has strong MFA requirements, so passkeys don’t help. Encrypting the tokens on disk doesn’t prevent the malware from scraping them out of the browser’s RAM or obtaining whatever key is used to encrypt them. This feels like a pretty hard problem to solve.

But that hasn’t stopped people from trying! Dirk Balfanz wrote an IETF draft describing a mechanism for using self-signed certificates for TLS authentication. This uses the mutual authentication feature of the TLS protocol that requires both sides prove their identity to each other. In regular TLS, the remote site presents a signed certificate that tells you who it is. When performing mutual authentication, you then present a certificate to the remote site telling it who you are. These client certificates are largely unused outside enterprise environments because they’re a huge pain to deploy. It’s not so much that this has sharp edges, it’s that it’s entirely made of sharp edges. Managing certificate deployment to your devices is hard. Browsers get confused if the certificates change under them. You have one certificate and it lives forever, so sites you present it to can track your identity. Users are prompted to choose a certificate to authenticate with, and if they pick the wrong one everything breaks and is hard to recover. I’ve deployed this and I did not have a good time.

But Balfanz’s idea was simple. Rather than require certificates to be deployed, browsers would simply generate a certificate on the fly. The goal wasn’t to prove the device or user’s identity in any global way - but it would associate a TLS session with a specific certificate. You could then, for example, include a hash of the certificate in the cookie, and if someone tried to use that cookie without presenting that certificate then the cookie could be rejected. If the browser used a hardware-backed private key for the certificate then it would be impossible for an attacker to steal it. Sure, you could still steal cookies, but you wouldn’t be able to use them.

This was written almost 15 years ago, and seems simple, elegant, and functional. It didn’t happen. Part of the reason for that is that, well, it wasn’t quite so simple. One problem was privacy related. Cookies are only sent after the TLS session is established, so anyone monitoring the network doesn’t know anything about the user identity. A naive implementation of this approach would have meant the client certificate being sent before session establishment, and now user identity can be tracked (no longer an issue if this was implemented on top of TLS 1.3, but this was a log time ago). This was avoided by reordering the client handshake, but that meant having to modify the TLS specification and implementations would have to be updated to support this. Another was that figuring out the granularity of the certificates was difficult. You’d want to use different certificates for every site to avoid them effectively becoming tracking cookies, but you need to provide the certificate before cookies are set, and you don’t know what origin the site is going to set in its cookies. If you generate a certificate for a.example.com and a different one for b.example.com, and a.example.com sets a cookie for *.example.com and includes the certificate you used for a.example.com, that cookie isn’t going to work on b.example.com and things are broken. This meant supporting it wasn’t as straightforward as it seemed - you’d need to ensure that your cookie scope was compatible with the certificate scope. You could probably make this work well enough by aligning it with the Public Suffix List, but there was still some risk of expectations not being aligned.

And, perhaps most importantly, TLS session resumption (replaced by pre-shared keys in TLS 1.3) somewhat defeats the purpose of the exercise - clients store state that allows them to re-establish a TLS connection without performing certificate exchange (this reduces overhead if a connection gets interrupted or you switch to a new network or anything along those lines), and anyone in a position to steal cookies could steal that state as well.

The followup attempt was channel IDs. This simplified the implementation somewhat - rather than certificates, a raw public key would be sent, along with proof of possession of the private key in the form of a signature over a portion of the TLS handshake. This was required even in the event of session resumption, which avoided having to worry about theft of session secrets. The timing of the exchange was after the encrypted session had been established, so user identity couldn’t be leaked that way either. Cookies could then be bound to this identifier. Unfortunately it didn’t really deal with the problem of scoping keys in a way that would match cookie requirements, and the spec suggests that the right way of handling this is to scope keys to TLDs, which would enable user tracking across sites (Chrome’s implementation apparently restricted it to eTLD+1, which would match the third party cookie policy and avoid the tracking risk).

Chrome added support for this, but it was removed in early 2018. The discussion of some of the pain points in that message is interesting, explicitly calling out problems with connection coalescing across domains and the incompatibility with zero-RTT TLS1.3. The overall consensus at the time seems to be that trying to solve this entirely at the TLS layer has too many rough edges, and a different approach should be taken.

And so almost 7 years after the initial draft for origin bound certificates, we come to token binding. This ended up being a rather more complex endeavour, covering 3 different RFCs describing how it impacts TLS, how to incorporate it into HTTP, and how to manage all the various parties involved in the process. The short version is that it’s pretty similar to channel ID, except that there’s also a documented mechanism for allowing tokens to be bound to one party and consumed by another, avoiding any need for widely scoped keys. Token binding effectively solved all the issues in the original proposal, but at the cost of somewhat more complexity.

The RFC was finalised in October 2018. Chrome removed its (incomplete, draft) support for token binding in November 2018. Edge carried support until late 2024. Despite getting all the way through the RFC process, it’s functionally dead.

The process up until this point had been largely initiated by Google, with Microsoft contributing significantly to the token binding standards. The work had been focused on identifying a generic solution to the problem rather than tying it to any specific authentication flow. The next step was in a different direction - rather than trying to fix this for the entire internet, how about we try to fix it for OAuth?

RFC 8705 is titled “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens”. This is basically the 2011 approach, but (a) with an explicit definition of how the certificate should be incorporated into issued auth cookies, and (b) with a proviso that well uh if you’re going to use tokens issued by your IdP to authenticate to someone else then well you’re going to need to use the same cert for both. This is probably fine for the company-owned-laptop case where you’re actually fine with multiple sites being able to tie identities together (that’s kind of the point here!), and also works for “I am using an app and not a browser”, but doesn’t work for more generic scenarios. It also doesn’t seem to take the session resumption case into account at all? Support for RFC8705 seems poor, as far as I can tell of the big players only Auth0 implements it. In theory it works fine with self-signed client certs but in reality that’s going to be almost as difficult to support across multiple platforms as just issuing proper client certs in the first place, so deployment is going to be kind of a pain. But the good news is it doesn’t rely on any TLS extensions or custom browser behaviour, so at the client side it works fine with any browser.

Which brings us on to RFC 9449, “Demonstrating Proof of Possession”. This goes even further than RFC8705 in terms of reducing the burden of deployment - it works fine with existing browsers, and it doesn’t even require any certs. The client generates a keypair and provides the pubkey when requesting the cookie. The cookie contains the pubkey. Every request to the service now provides the cookie with the pubkey and also provides a signature over the URI and HTTP method. If the signature matches the pubkey in the token then clearly the signature came from the machine the token was issued to, and everything is good.

This does come with some downsides, though. The first is that it uses browser interfaces to generate the keys (typically crypto.subtle.generatekey()) and as far as I can tell there are no browsers that guarantee that that key is going to be generated in hardware even if it’s marked non-exportable, so anyone able to steal the cookies can also steal the keys. The second is that the signature only covers the URI and HTTP method, and not the message content or any other headers, so anyone able to exfiltrate a valid signature can replay it against the same URI with different message content. The recommended way to handle this is to reject any signatures that weren’t generated within the last few seconds, which is a wonderful additional way to allow clock skew to give you a Bad Day. And the third is that every single request has to be separately signed, which is not intrinsically a problem because computers are fast and have multiple cores, but if you’re trying to solve the first problem by sticking the key in a TPM then you’re dealing with something that’s slow and single threaded and that’s maybe acceptable if you’re using client certificates (because there’s going to be one signature per session and you can use the same session for multiple requests) but probably not if you’re dealing with a user opening a browser that restores previous tabs and each of those is a webapp that fires off 100 requests in parallel.

In case it wasn’t clear, I don’t like DPoP. It doesn’t feel like it actually solves the underlying problem that we see in the real world (malware running in a context where if it can grab the tokens it can grab the keys), it adds a massive amount of overhead, and it has baked in replay vulnerabilities. I don’t know why it exists and I’m incredibly suspicious of vendors telling me that it fixes my problems, because if they’re telling me that then I’m going to end up assuming that they either don’t understand my problems or they don’t understand their technology, and neither of those is good.

Still. Then we get to the thing that prompted me to write this - Chrome’s announcement that they had launched device-bound session credentials. This is interesting because it’s a Chrome feature that’s explicitly intended to counter on-device malware, which was one of the things that was out of scope in 2018 when token binding was being removed. Since this is entire web level it doesn’t have to be an RFC, and so is instead defined by W3C. I’m going to handwave all the complexity and say that it’s basically a way to register a public key when a cookie is issued, and then prove possession of the private key when it’s time to renew the cookie. By making the cookies shortlived and having support for rotating them in the background, user impact is basically zero and while it’s still possible for an attacker to exfiltrate and use a cookie they’ll only be able to do so for a short window before it needs to be refreshed - something the attacker can’t do, since they don’t have the private key. This avoids the DPoP overhead because you only need to do signing once per cookie per cookie lifetime, and not on every single request. I don’t like this due to the window where exfiltrated tokens can be used, but it feels like a strict improvement over the status quo. An extension called device-bound session credentials for enterprise allows pre-enrollment of device keys, so even though the actual runtime DBCE flow doesn’t involve certificates, certificates can be used for device registration in enterprise environments and you can make sure that auth cookies only go to trusted devices. Unfortunately this is Chrome-only, and so we’re going to need to wait for it to be backported to all the random app frameworks for it to have widespread support on mobile or for almost everyone’s desktop app that’s actually three websites in an Electron wrapper. Mozilla’s current position is that they’re not in favour of it, so I guess we’ll see where Safari lands in terms of broad uptake.

The last thing on my list is another client cert/OAuth binding, this one still in draft state at the time of writing. This one is aimed primarily at the use of agent-driven tooling, where you have something running in the background using a whole bunch of tools that are each acting on your behalf. Authenticating to all of them separately isn’t a fun time, but giving broadly scoped access tokens to a non-deterministic agent and trusting that it’ll never post them somewhere public also isn’t a fun time. The key distinction between it and RFC8705 is that it’s aimed at connections rather than sessions, which avoids the worries about session resumption. This is done with TLS Exporters, which in TLS 1.3 should be unique to the connection even over session resumption (TLS 1.2 may reuse some of the same key material for exporters over session resumption, so it’s recommended to enforce 1.3 for this). By providing a new signature alongside the cookie on every new connection, the client proves that it still has access to the private key. This is a very new spec and I haven’t had much time to work through it yet, but my naive understanding is that unlike RFC8705 this would require some additional client support to be able to regenerate the client signature on every TLS reconnection.

This doesn’t avoid all the problems that RFC8705 has, including how to scope certificates. For the agentic use case that probably doesn’t matter - all these tools are acting on behalf of the same user, it’s fine if all the sites involved know they’re the same user. But it doesn’t solve the general purpose user use case, and right now DBSC seems like the best we have there.

But. Part of me still wonders whether Dirk Balfanz’s approach was the right one. Yes, there’s risk associated with TLS session resumption, but in the worst case you could just switch that off for high risk setups. The cookie scope argument is real, and also in cases where it could violate privacy the site owner could already choose to broaden their cookie scope and violate your privacy, and in cases where it breaks things you could just not make use of it. The other problems are largely fixed by TLS 1.3, and then we’re just left with “Browsers handle client certificates badly” to which my answer is “Yes, and we should fix that anyway”.

Despite having a pretty good answer to this solution over a decade ago, the closest we have to actual deployment is something that offers strictly worse security guarantees. And tokens keep getting stolen, and compromises keep occurring, and for the most part people shrug and get on with things.

O nome da capital da Noruega

Posted by Avi Alkalay on 2026-07-01 11:29:29 UTC

Mais um nome de lugar que, em português, falamos errado porque herdamos uma grafia estrangeira.

Kristiania era o nome desta cidade de 1624 a 1925 porque o rei dinamarquês Cristiano IV queria se auto-homenagear quando a reconstruiu após um grande incêndio. 20 anos após a Noruega conquistar sua independência da Suécia, o parlamento decidiu voltar ao seu gracioso, simples, elegante e também imponente nome original medieval.

A forma sonora como os noruegueses chamam sua capital é:

ÚSSLU

No transporte público, ouvi anunciado assim:

ÔSHLÔ

Contaram-me também que em certas rodas mais “frescas” se fala também:

ÚSSLO

Então, da mesma forma que achamos estranho quando estrangeiros falam, erradamente, “braçill” ao invés de “brazil”, também deveria ser considerado estranho quando falamos “ózlo”.

Agora que sei disso, devo continuar falando “ózlo” ou o correto “úshlu”? Há quem diga que se eu ficar só no “úshlu” vão me achar um fresco e exibido. Então acho que vou ficar variando. No mínimo para gerar conversas curiosas em festas.

Flock to Fedora 2026: What Happened

Posted by Justin Wheeler on 2026-06-30 08:00:00 UTC
Flock to Fedora 2026: What Happened

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

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

Note

This is the first post in a three-part series on Flock to Fedora 2026. The second post covers how Flock gets organized behind the scenes. The third post shares my personal reflections on organizing Flock as Fedora Community Architect.

The Hallway Track

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

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

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

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

"Generational Switchover" and Packager Data Trends

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

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

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

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

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

Record-Breaking Sponsor Engagement

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

  • We have a diverse group of engaged sponsors, mostly from downstream products and companies, which care about the sustainability and well-being of Fedora.

  • We are growing the amount of sponsorship for Flock to Fedora, which can enable us to think on a bigger, grander scale for future editions.

  • Our processes are getting better at selling Flock sponsor packages, and processing contracts, purchase orders, and invoices.

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

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

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

Fill Out the Flock 2026 Post-Event Survey!

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

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

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

More in this series

This post covered the highlights of what happened at Flock 2026. But there is more to say about how Flock gets organized and what the experience means on a personal level.

A DNS Record That Existed Everywhere Except CI

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

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

Posted by Francois Gonothi Toure on 2026-06-29 20:08:29 UTC

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

Image promptly created with Google Gemini’s Nano Banana

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

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

So what have I done and contributed so far?

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

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

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

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

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

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

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

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

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

What I am most proud of building so far:

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

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

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

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

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

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

Adjustments to scope, timeline, and tasks:

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

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

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

Regards,
Gonothi

Your _get_type() function is not G_GNUC_CONST: Part Two

Posted by Michael Catanzaro on 2026-06-29 15:32:49 UTC

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

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

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

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

From June 22 to June 28

Posted by Aurélien Bompard on 2026-06-28 23:14:00 UTC

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

Announcements

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

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

Council

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

Learn more about the Council team.

FESCo

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

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

Decisions

Learn more about the FESCo team.

Packaging Committee

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

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

Learn more about the Packaging Committee team.

Mindshare

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

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

Learn more about the Mindshare team.

Ambassadors

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

Learn more about the Ambassadors team.

Workstation / GNOME

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

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

Learn more about the Workstation / GNOME team.

KDE

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

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

Learn more about the KDE team.

Server

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

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

Learn more about the Server team.

Infrastructure

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

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

Decisions

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

Learn more about the Infrastructure team.

Release Engineering

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

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

Decisions

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

Learn more about the Release Engineering team.

Quality

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

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

Decisions

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

Learn more about the Quality team.

Design

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

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

Decisions

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

Learn more about the Design team.

Docs

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

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

Decisions

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

Learn more about the Docs team.

Internationalization

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

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

Learn more about the Internationalization team.

COPR

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

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

Learn more about the COPR team.

EPEL

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

Decisions

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

Learn more about the EPEL team.

ELN

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

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

Learn more about the ELN team.

Atomic

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

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

Learn more about the Atomic team.

CoreOS

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

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

Decisions

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

Learn more about the CoreOS team.

IoT

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

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

Learn more about the IoT team.

Cloud

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

Learn more about the Cloud team.

AI & ML

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

Learn more about the AI & ML team.

RISC-V

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

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

Learn more about the RISC-V team.

Security

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

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

Learn more about the Security team.

Gaming

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

Learn more about the Gaming team.

Perl

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

Learn more about the Perl team.

Other Discussions

New contributor introductions

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

Orphaning packages

Package updates

misc fedora bits: end of june 2026

Posted by Kevin Fenzi on 2026-06-27 18:22:49 UTC
Scrye into the crystal ball

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

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

RHEL10 migrations

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

  • Using a remote console I can't hold down shift to get a grub menu, so I had to hit escape at the right time.

  • rdp for Fedora is not great still. gnome-connections is still the winner, but even it has quirks.

  • The /boot/efi partition still did not want to let me reformat it as part of the install. I thought it was because there was a spare in the raid1 for it, but I grew it to use that spare and it still didn't help. So, I ended up just deleting it and recreating it.

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

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

2fa in Fedora

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

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

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

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

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

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

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

s390x builds backup and koji session bug

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

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

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

  • One I had set to only do kernel builds a while back when we were trying to get security updates out fast.

  • One was a compose host, but I think we can be fine with one less compose host.

So adding those two helped process the backlog too.

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

Some PTO next week

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

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

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

onak 0.6.5 released

Posted by Jonathan McDowell on 2026-06-27 15:44:00 UTC

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

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

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

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

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

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

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

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

Available locally or via GitHub.

0.6.5 - 27th June 2026

  • Lots of fixes/improvements around length checking
  • Added extra basic tests for maxpaths/sixdegrees/CGI
  • Correctly end transactions in the stacked backend
  • Ensure the file backend avoids stale key data on updates
  • Fix decoding of v2/3 signature creation times
  • Fix EdDSA signature parsing when r < 249 bits long
  • Fix migration of bools from old to new config style
  • Fix parsing of new config details for DB parameters
  • Fix problems with linking + dynamic backends
  • Fix RSA-SHA2-384 signature checking
  • Fix sixdegrees parsing of keyids with high bit set
  • Handle failures in maxpath more gracefully
  • Make new style config path match old path

© 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