/rss20.xml">
fedora

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

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

How I'm Solving Local Inference

Posted by Chris Short on 2026-06-19 04:00:00 UTC
How I bridged my MacBook Air and Framework 13 using LM Studio's LM Link to run powerful local models, avoid token costs, and gain portability.

New badge: DevConf.cz 2026 Attendee !

Posted by Fedora Badges on 2026-06-18 11:59:07 UTC
DevConf.cz 2026 AttendeeYou attended the 2026 iteration of DevConf.cz, a yearly open source conference in Czechia!

From June 08 to June 14

Posted by Aurélien Bompard on 2026-06-18 08:37:00 UTC

Across the project, the dominant focus was on preparing for the upcoming Fedora 45 release. This involved FESCo debating significant Change Proposals like a system-wide libxml2 update and a new GRUB package for Confidential Computing, while the Quality and ELN teams were busy testing and integrating major updates like Python 3.15 and preparing for OpenSSL 4. A key strategic initiative discussed by the Council and Atomic groups is the plan to use Konflux to build and ship bootc base images for the F45 cycle. Another common theme was the upcoming Flock conference, which impacted meeting attendance and served as a central point for planning, presentations, and resolving blockers. Concurrently, several groups were managing infrastructure changes, including the completed migration from Nagios to Zabbix and the ongoing move of repositories from Pagure to Fedora Forge.

Announcements

The F44 election cycle has concluded, with results announced for the Fedora Council, FESCo, Mindshare, and EPEL Steering Committee. This followed a final reminder to vote earlier in the week. In the lead-up to Flock 2026, the "#Commit History" campaign continued to highlight contributor stories, featuring interviews with speakers Jaroslav Reznik, Jona Azizaj, Justin Wheeler, and Peter Boy. The campaign also encouraged community members to share their own first commit stories, and an election-period interview with Council candidate Tomáš Hrčka was also published.

On the technical front, two change proposals for Fedora 45 were announced: a system-wide update to libxml2 that will require a mass rebuild, and the creation of a minimal GRUB EFI package for Confidential Computing. An important announcement explained the upcoming Microsoft Secure Boot certificate expiration, assuring users that Fedora is prepared and there is no need to panic. For testers and developers, non-official Fedora 44 RISC-V images are now available, and a new guide details how to onboard a Forgejo-hosted project to Fedora Konflux for CI/CD.

Council

This week, the Council's activity centered on the "Atomic This Week - 2026-06-09" update, which summarized the progress of the Atomic Initiative (formerly the bootc initiative). Key discussions focused on the plan to use Konflux for building and shipping the Fedora bootc base image, targeting the Fedora 45 release. The main blocker identified is securing approval from Fedora releng for a managed namespace, a topic to be discussed in person at Flock. The group also addressed the need for a clearer governance structure and contribution ladder to improve contributor access to Konflux. For the initiative's long-term future, the consensus is to create a new, permanent "Atomic SIG" dedicated to bootc base images, rather than merging with the Atomic Desktops SIG. Interested contributors are invited to join the #bootc:fedoraproject.org Matrix channel to participate.

Learn more about the Council team.

FESCo

Several new Change Proposals for Fedora 45 were introduced and discussed this week. A proposal to update libxml2 to version 2.15.3 was submitted, which is notable as it includes an ABI change requiring a system-wide mass rebuild and deprecates the python3-libxml2 subpackage. Maintainers of packages using the old Python bindings are encouraged to migrate to alternatives. Another new proposal aims to create a minimal GRUP EFI package specifically for Confidential Computing environments to boot Unified Kernel Images (UKIs). This proposal generated significant debate, with many contributors questioning the decision to create a new GRUB variant instead of using the existing systemd-boot, and challenging the rationale provided for its rejection.

In other news, the long-running Protobuf 5.x/6.x update was reported as complete and is now available in Rawhide. For those interested in testing upcoming changes, the NodeJS metapackage change is now available in a COPR for preliminary testing. Finally, the proposals for Erlang 27 and RPM 6.1 were formally submitted to FESCo for voting.

Learn more about the FESCo team.

Packaging Committee

During their weekly meeting, the Packaging Committee approved a change to make the Web bundling guidelines consistent with a prior FESCo decision (PR#1539), although they plan to revisit that underlying decision in a separate ticket. A significant open-floor discussion revolved around the process for packaging new cryptographic libraries, where a packager has been unable to get a required public response from the crypto team for over a year. The current plan is to escalate this to FESCo after the Flock conference if it remains unresolved. The committee also debated a proposal for using file triggers to generate shell completions but postponed a decision due to concerns about its compatibility with immutable systems (like rpm-ostree) and containers.

Learn more about the Packaging Committee team.

Mindshare

In the final Mindshare meeting of the current term, the committee focused on transitioning responsibilities and a major new proposal. Discussions covered the off-boarding process for the appointed representatives from CommOps and Marketing, highlighting an opportunity for new contributors to step into these roles. The primary topic was an experimental initiative proposed by the Fedora Council to use Open Collective for community fundraising to support event travel, starting with BalCCon. This aims to create a more agile reimbursement process outside of Red Hat's corporate systems. The committee showed broad support for the experiment, emphasizing the need for careful messaging to avoid misperceptions about Red Hat's funding commitment.

A significant forum discussion this week centered on a contributor's frustration with a non-responsive package maintainer, which sparked a broader conversation about the contributor experience. The thread highlighted the challenges volunteers face and the negative impact that a lack of feedback can have on contributor retention, a key area of concern for the Mindshare committee.

Learn more about the Mindshare team.

Workstation / GNOME

The Workstation Working Group held its bi-weekly meeting, covering several topics. Discussions included a proposal to drop Libcanberra and move sound handling into GNOME Shell, the use of AI for static analysis and duplicate bug detection, and the potential replacement of the Seahorse password manager with a more modern application like Key Rack. On the forums, a call was made for Fedora GNOME users to test a new open-source AI usage tracker called OpenUsage Community, providing an opportunity for community involvement. The ongoing conversation about a potential Fedora edition for NVIDIA's RTX Spark AI hardware also continued.

Decisions

Learn more about the Workstation / GNOME team.

KDE

This week, the KDE SIG prepared for the final release of Plasma 6.7.0. The COPR repository for the Plasma 6.7 beta was decommissioned as the testing phase concluded ahead of the official release. This marks a key milestone for users and testers looking forward to the new stable version.

A discussion was also started regarding a user experience issue in KDE Discover, where the interface provides no progress indication during immediate updates, unlike the behavior for offline updates. The user was advised to report this feedback upstream to the KDE community, presenting an opportunity for contributors to engage with developers to improve the software.

Learn more about the KDE team.

Infrastructure

This week, the Infrastructure team announced two major milestones. First, the long-running migration from Nagios to Zabbix for monitoring is now complete, and Nagios has been shut down. The focus now shifts to refining the new Zabbix checks, reducing alert noise, and onboarding other teams to consume their own monitoring data. You can read the full announcement here. Second, Akashdeep Dhar and Lenka Segura were welcomed into the sysadmin-main group, granting them root access in recognition of their extensive contributions. The announcement and congratulations can be found on the discussion forum and the mailing list.

With several team members traveling for the Flock conference, availability may be reduced. During the week's meetings, the team triaged tickets related to dead mirror links and crypto spam, and discussed ongoing work to protect repositories against malicious pull requests. The monthly AWS usage report prompted a discussion about cleaning up unused QA instances to reduce costs. A new contributor was welcomed during the weekly meeting, and opportunities for community involvement include helping with open tickets and collaborating on the new Zabbix monitoring system.

Decisions

  • The Nagios monitoring system has been officially decommissioned and replaced by Zabbix. Nagios services on noc01 and noc02 were stopped.
  • Akashdeep Dhar and Lenka Segura were added to the sysadmin-main group, which has root access to the infrastructure.
  • A patch to fix a FedoraMessaging issue on the wiki (#13395) was merged.
  • The team will investigate and potentially delete unused QA instances in AWS to reduce costs.

Learn more about the Infrastructure team.

Quality

The Quality team's weekly meeting focused on the status of Fedora 45, particularly the recent landing of two major Changes: kmscon consoles and Python 3.15. These have introduced some known issues, such as broken kickstart installs and console problems on IoT and CoreOS, which require attention from testers. A call was made for a volunteer to organize Test Days for the F45 cycle, and the next kernel test week is expected in about three weeks. On the mailing list, a plan was proposed to simplify CI infrastructure by discontinuing legacy .ci. messages.

On the forums, a new version of the community-driven DNF UI tool was released, now using the official dnf5daemon for transactions. A significant discussion was sparked by a contributor asking "Is it worth contributing to the Fedora Project?" due to an unresponsive maintainer. This led to a broader conversation about the challenges of a volunteer-driven project and the processes for handling such issues. The team also welcomed a new potential contributor, Ephraim Kaov, who requested to join the QA group.

Decisions

Learn more about the Quality team.

Design

The Design team's meeting this week was centered on preparations for the upcoming Flock conference. The team discussed progress on the presentation slideshow, beta wallpaper, and livestream splash screen. They also reviewed high-quality promotional videos from a new contributor, ProducerRob. Other key topics included the design for the Flock party badge, where they considered reusing existing assets, and a discussion on the Datagrepper icon, weighing the use of pre-made SVGs against custom designs to ensure recognizability at small sizes.

Decisions

  • The general attendee badge for Flock will be awarded automatically through a web hook connected to the Pretix ticketing system, so a QR code poster for claiming it is no longer needed. The party badge will likely still require a manual claim process.
  • A new ticket regarding labels will be postponed until the next ticket refinement meeting.
  • Madeline Peck will host a meeting next week for team members who are not attending the Flock conference.

Learn more about the Design team.

Internationalization

The Internationalization team held its weekly meeting to discuss upcoming Fedora 45 changes. The team is considering postponing the variable fonts change for fonts-rpm-macros and is planning a new change to package upstream LibreOffice dictionaries as alternatives to the current Fedora hunspell dictionaries. On the mailing list, there was a call for Kurdish speakers to help correctly identify and tag existing translations that use the generic "ku" language code. The team also welcomed back a returning contributor, Javier Blanco, who will be assisting with Spanish translations.

Learn more about the Internationalization team.

COPR

This week, the COPR team published the release notes for the copr-backend server update that was performed during a planned outage on June 2nd. The announcement provides details and context for users and contributors about the changes implemented.

Learn more about the COPR team.

EPEL

During the weekly EPEL meeting, the main topic was repository lifecycle management. The steering committee discussed the timing of minor version retirement and decided to maintain the current policy, closing the related issue. The practical effects of this policy were highlighted in a mailing list thread concerning the recent retirement of EPEL 10.1, where users were reminded that EOL content is available from the archive mirrors. For packagers, a forum discussion clarified that requests for new branches should still be filed against pagure.io instead of the new Fedora Forge instance.

In other news, a final notice was sent to the epel-announce and epel-devel mailing lists regarding the impending retirement of python-django3 from EPEL 8 and 9. The package is end-of-life and has unpatched security vulnerabilities, and since no one has volunteered to maintain it, it and its dependents will likely be retired. The committee also agreed to find a new time for its weekly meetings to improve attendance.

Decisions

  • The issue regarding EPEL minor version retirement timing was closed. The current policy will remain unchanged.
  • The EPEL Steering Committee will find a new time for its weekly meeting. A poll will be sent to committee members to determine the best time.

Learn more about the EPEL team.

ELN

This week's ELN meeting covered several major upcoming changes and ongoing work. The Python 3.15 update has largely landed in ELN, a significant milestone as this is the version RHEL 11 will branch with. Preparations are also underway for the migration to OpenSSL 4, which is planned for next week in Rawhide and will subsequently land in ELN. Most of the ELN package set has been tested against the new version, and a compatibility package for OpenSSL 3 will be provided to ease the transition. Other discussions included resolving a packaging dependency issue for bootc images, following up on the Hyperscale kernel configuration problem with a new contact in the Red Hat kernel team, and the upcoming migration of the ELNBuildSync service to Fedora Infrastructure hosting.

Decisions

  • The meeting scheduled for 2026-06-16 will be skipped due to the Flock conference. The next meeting will be held on 2026-06-23.

Learn more about the ELN team.

Atomic

The Atomic group's weekly meeting focused on the proposal to use Konflux for building and shipping the bootc base image, with the goal of having this in production for the Fedora 45 release. The main challenge identified is convincing Fedora Release Engineering to support the required managed namespace for signing and pushing artifacts. This topic will be a key discussion point at the upcoming Flock conference, where a presentation is being prepared. The group also discussed improving contributor access to Konflux and the long-term governance of the initiative's work, which will likely involve creating a new SIG to maintain the base images after the initiative concludes post-F45.

In the forums, user support discussions continued. One thread saw a user ask for updates on a Konsole TTY error on F44, suspecting an issue with Flatpak integration. Another conversation clarified why a locally installed RPM for Proton VPN on Silverblue is not updated via the Software Center and must be managed manually with rpm-ostree.

Decisions

During the Atomic meeting, the group formally agreed on the following points regarding the move to Konflux:

  1. The group confirmed its consensus that using Konflux is the desired direction for building the bootc base image.
  2. The primary blocker is convincing Fedora Release Engineering of the need for a managed namespace and artifact signing.
  3. A change proposal for this move needs to be drafted in parallel with these discussions.

Learn more about the Atomic team.

CoreOS

In this week's CoreOS meeting, the team reviewed the Fedora 45 release schedule and confirmed that no immediate actions are required. The open floor session included a technical discussion about the boot-time flow of base.platform.d entries and the ignition-fetch.service, prompted by an Afterburn pull request. Another key topic was the status of a proposal to integrate Butane functionality directly into Ignition, as tracked in issue #2006, with the goal of targeting it for the Fedora 45 release. The team also noted which members will be attending the upcoming Flock conference.

Decisions

  • spresti will investigate the operational ordering related to the Afterburn pull request.
  • spresti will update issue #2006 with previous feedback and follow up with dustymabe regarding the proposal to integrate Butane into Ignition for Fedora 45.

Learn more about the CoreOS team.

IoT

During the weekly IoT meeting, the main topics were the upcoming migration from Pagure to Fedora Forge and the status of release testing. The team is preparing for the repository migration, which is considered urgent as Pagure's decommissioning is imminent. Regarding release engineering, a refresh of the Fedora 44 images is planned but is currently blocked waiting for an update to image-builder. A critical issue was discussed for Fedora 45 (Rawhide), where all OpenQA tests are failing across all architectures. This bug is a key focus for the team, and contributors are encouraged to help investigate the problem.

Learn more about the IoT team.

Alternative Images

In the weekly Alternative Images meeting, discussion focused on RISC-V progress and the migration from Pagure.io to GitLab. The final recompile of CentOS Stream 10 for RISC-V is nearly complete after resolving a %dist tag conflict by changing it to .el10rv. The team hopes to begin building the RISC-V images next week, aided by configurations provided by the RHEL team. This progress is significant for the broader community interested in RISC-V on CentOS.

The migration of key repositories to GitLab is complete as Pagure.io is being decommissioned. While internal documentation has been updated, there is an opportunity for contributors to help by updating the public docs.centos.org website to reflect these changes, as tracked in this work item. This ensures that contributors are not disrupted by the platform change and can easily find the new repository locations.

Decisions

  • The following repositories were migrated from Pagure.io to GitLab, with the rest being archived: kiwi-descriptions, sig, spin-bugs, and anaconda-liveinst.

Learn more about the Alternative Images team.

Cloud

The Cloud SIG held its weekly meeting and discussed the recent successful migration of the cloud-sig to forge.fp.o. Thanks were given to the contributors who made this transition possible. The primary focus of the meeting was planning for the upcoming Flock conference.

A significant portion of the discussion was dedicated to organizing a Cloud-SIG meetup at Flock. This provides a key opportunity for contributors to connect in person. The group brainstormed several important topics for this meetup, including a strategy for handling image customizations, creating a formal release checklist, developing a 3-year strategic plan, and exploring the creation of a dedicated AI/ML cloud image.

Decisions

  • A Cloud-SIG meetup will be held at the Flock conference. The time is still to be determined, but the location will be Room 1003.

Learn more about the Cloud team.

AI & ML

This week, the AI & ML group's activity focused on the ongoing effort to figure out NPU support in Fedora for the F43 release. A significant step forward was shared by Alessandro Lattao, who posted a link to a working COPR for FastFlowLM. This project enables running Large Language Models (LLMs) on AMD Ryzen AI NPUs. This provides a concrete opportunity for contributors to get involved by testing the new packages and helping to advance NPU enablement within the distribution.

Learn more about the AI & ML team.

RISC-V

This week, the RISC-V group announced the availability of non-official Fedora 44 images for community testing. These images feature a new "Omni" kernel variant intended to support a broader range of hardware. During the weekly meeting, the team noted that while the package delta for F44 is minimal, some boot issues have been reported. Work has now begun on Fedora 45, with the immediate priority being the integration of Python 3.15. Hardware updates included the addition of a Spacemit K3 board to the Koji build system. A decision was also made to establish a new SCM structure for RISC-V specific packages.

Decisions

  • A new namespace for RISC-V specific package forks will be created on forge.fedoraproject.org. The repository structure will be /riscv/packagename (e.g., /riscv/gcc), forking from the main /rpms/ repositories.

Learn more about the RISC-V team.

Security

The Security SIG held a brief meeting this week, with low attendance as many contributors were traveling to the Flock conference. The group reviewed the open tickets in the main Security Forge and the Security Docs Forge, and contributors are encouraged to vote on ticket #8. A discussion arose about the meeting's weekly frequency, with suggestions to either move to a bi-weekly schedule or cancel meetings when there are no topics. This will be discussed further in a future meeting when more members are present.

Learn more about the Security team.

Go

A discussion was initiated on the mailing list regarding a packaging issue where the %{gosource} macro failed for the checkmake package. The macro generated a URL for the source tarball that resulted in a 404 error. The packager found a manual workaround by constructing the URL differently and questioned whether the problem stemmed from the upstream project's release process deviating from the norm. This thread presents an opportunity for Go packaging experts to clarify the expected behavior of the macro and best practices for handling such upstream inconsistencies.

Learn more about the Go team.

Perl

This week's activity for the Perl group focused heavily on package maintenance, including version updates and proactive compatibility fixes. Several packages were updated to be compatible with upcoming releases, such as perl-BDB for Perl 5.43.2+, perl-re-engine-RE2 for Perl 5.43.11, and perl-Net-SSLeay for OpenSSL 4.0. Additionally, several modules received version bumps, including perl-HTTP-Daemon, perl-HTTP-Message, and perl-Locale-Codes.

A key ongoing discussion revolves around the large number of orphaned Perl packages resulting from a maintainer's inactivity. A list of packages still needing adoption was circulated, presenting a significant opportunity for contributors to take ownership and help maintain the Perl ecosystem within Fedora.

Decisions

Learn more about the Perl team.

Other Discussions

  • Aoife Moloney announced the results of the F44 Elections Cycle for the Fedora Council, Fedora Mindshare Committee, FESCo, and EPEL.
  • In a discussion about the Fedora Mentor Summit at Flock 2026, Jona Azizaj announced the planned activities. These include daily "Lunch & Learn" sessions for informal networking, a sticker matching icebreaker to connect attendees, and a session to highlight the Fedora Contributor Recognition Program and its winners.
  • A new topic was created to discuss including upstream branch information in Fedora packages. The main use case is to help developers easily find the correct branch for submitting bug reports and fixes. The conversation weighed the benefits of a dedicated field for this information against concerns that a branch name is mutable and less reliable than a commit hash.
  • Yann Collette provided an extensive update on the Audinux repository for May 2026, detailing the addition of 32 new packages and 88 package updates for audio production software. In response to the detailed post, it was suggested that a Fedora Magazine article would be a great way to increase visibility, an idea which was well-received.
  • In the "If you're on the kernel mailing list (LKML), aren't you concerned about AI?" discussion, the conversation continued about plagiarism and AI-generated code. Participants suggested using plagiarism detection tools similar to those in academic publishing. Frustration was also expressed regarding the high volume of automated commits on the LKML, which makes it difficult to follow human discussions.
  • The discussion on how to include upstream URLs in Fedora packages continued, with a note that a previous proposal for a RepoURL tag in RPM was rejected in favor of using the existing VCS tag. An example was shared from the Hummingbird project, where for packages without a traditional upstream, the VCS field points to the package's location in Fedora's infrastructure.
  • Adam Williamson proposed a plan to stop sending .ci. messages on the Fedora message bus. This change aims to simplify the CI infrastructure, as the system is considered legacy and its few consumers can be adapted to use other message sources like resultsdb directly.
  • Gordon Messmer is seeking a reviewer for a new security analysis tool in Fedora CI. The proposed generic test uses "got-audit" to attach to running systemd services and check for unusual symbol resolutions, which could help detect issues like the XZ backdoor.
  • Zbigniew Jędrzejewski-Szmek announced a change in Rawhide's systemd package regarding the autogeneration of library dependencies. The new method improves handling of soft dependencies for libraries loaded with dlopen(), allowing binaries to adapt their functionality based on which libraries are installed.
  • Fabio Valentini announced that he is beginning to implement the Changes/Versioned_libgit2_packages proposal. The first step involves retiring the unused libgit2_1.8 package in Rawhide, with further changes and rebuilds planned for after Flock.
  • Other discussions this week included a heads-up about fixes for dracut DHCP issues, a conversation about the civetweb package being retired in Rawhide, a clarification that repository composes use efficient hardlinks instead of copying RPMs, a new F45 Change Proposal to update libxml2, a discussion on a UTF-8 parsing issue in Java manifests, testing and feedback for the new Node.js Metapackages, continued discussion on the F45 Change Proposal for RPM 6.1, a query about using sidetags in Pull Requests, and a note on a similar security incident in Arch Linux in the context of the compromised Fedora account.

New Contributor Introductions

  • Kevin Thomas (kevtt) introduced himself as a newcomer looking to get involved with the Join SIG, testing, and documentation to learn more about Linux and the community.
  • Henry (henrymmey), a teenager from Germany, introduced himself with an interest in infrastructure, systems management, and Linux development, and is seeking guidance on where to contribute.

Package Updates

  • Benson Muite announced an upcoming update for ThorVg in F44 and F43 to address a CVE.
  • Frantisek Zatloukal confirmed that the mass rebuild for the icu 78.3 update is now complete.
  • Sandro Mani announced plans to update gdal to version 3.13.1, which includes a soname bump, but was asked to hold off until the ongoing OpenSSL 4.0 rebuild is finished.
  • In the thread about the fmt library soversion bump, Frantisek Zatloukal offered to handle the required mass rebuilds for both fmt and the dependent spdlog package in about two weeks.

Orphaning packages

  • Jerry James orphaned spec-version-maven-plugin and jakarta-json as they are no longer required by antlr4-project. He noted that spec-version-maven-plugin is still a dependency for other packages and will need a new maintainer.
  • Adam Williamson briefly orphaned xterm-console before quickly re-adopting it after realizing it was still needed.
  • Viktor Erdelyi provided an updated build for the orphaned package wavemon. After encouragement to become the maintainer, Iñaki Ucar stepped in to formally adopt the package and start the un-retirement process, as Viktor was not yet a packager.

Ten + 1 Reasons to Avoid the Immutable Desktop

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

Lately, it seems the industry is aggressively pushing immutable, image-based operating systems for the desktop. Shipping a cryptographically sealed, read-only root filesystem sounds super fancy and elegant on paper, but in reality, it's a solution looking for a problem, unless you're running a smart fridge or a corporate kiosk.

Let me be perfectly clear: immutable systems are the correct choice for single-purpose appliances, point-of-sale terminals, and sealed server nodes. If your hardware only needs to run a fixed set of remote directives without any user intervention, then yes, a mutable root filesystem is just begging for trouble.

But trying to force this architecture onto a general-purpose desktop? That is a spectacular regression. It wraps the user in a straitjacket, offloads system complexity onto you, and strips away ownership, performance, and actual security in the process.

Here is the engineering reality of why the immutable desktop fails the general user.

The Decentralized Trust Fallacy

In a traditional mutable distribution (like Fedora or Debian), the supply chain is centralized. A dedicated, paranoid security team audits and patches the core repositories. Immutable desktops, however, force you to rely on containerized app stores (Flatpak or Snap). This shifts your trust from a central team to thousands of random, unvetted package maintainers. If a developer gets tired of maintaining a popular app and a malicious actor takes over the namespace, they can silently push a credential stealer directly to your machine. It gets delivered instantly via background updates, completely bypassing distribution-level QA.

Furthermore, standardizing the exact same OS image across millions of installations creates a beautiful, uniform monoculture. If a zero-day is found in that specific image, every single user on Earth gets compromised by the exact same payload. Congratulations! On a mutable system, your messy "state drift" (different library versions, weird compiler flags, custom packages) acts as a natural defense system, frequently causing exploit payloads to crash and burn. Diversity is security, compa! ;)

Weaponized Negligence (Zombie Dependencies)

A security disaster doesn't require active malice; simple developer laziness works just as well. If a developer using Flatpak to distribute an app bundles an outdated version of libwebp or openssl in their container and forgets about it, that vulnerability is now permanently camped out on your system. Because your host OS is read-only, your central package manager is completely powerless to patch it.

While common base libraries might get updated in shared runtimes, modern desktop software is dominated by Electron, Node, Python, and Rust. These apps bundle their own massive piles of NPM packages, Cargo crates, and entire copies of Chromium inside their container. When a critical vulnerability drops in one of these nested dependencies, your shared runtime does absolutely nothing to save you. You are completely at the mercy of the upstream developer rebuilding their app. Until they do, you are left running a collection of isolated zero-day vulnerabilities while basking in a false sense of security. Sweet dreams!

The Sandbox Illusion

Advocates love to claim containerized apps protect you via sandboxing. This is, plain and simple, an architectural lie. To make complex applications actually work, maintainers routinely ship containers with massive filesystem overrides (like --filesystem=home). The moment a compromised application updates, it has immediate access to your SSH keys, browser session cookies, and cloud tokens. Securing /usr/bin while leaving /home wide open to unvetted third-party containers is a spectacular failure in threat modeling.

Besides, malware doesn't even need write access to /usr to stick around. It can easily drop a systemd user service (systemd --user) or a simple autostart entry in your home directory. Bam! Permanent persistence achieved without ever needing to touch root. The read-only system partition didn't even notice.

Note

Sure, you can install Flatseal to manually restrict these overrides. But honestly: who has the time to audit permissions for dozens of apps every time they update? Nobody.

Memory Exhaustion on Modest Hardware

Immutability decouples applications from the base system, which completely kills the memory-saving benefits of dynamic linking (shared libraries). Forcing a machine with 4GB or 8GB of RAM to load multiple massive runtimes (like GNOME 45, GNOME 46, and the Freedesktop SDK) into memory simultaneously is a crime against efficiency. The immutable model assumes your RAM and storage are infinite, actively punishing users who aren't running high-end rigs.

The Bandwidth and Storage Tax

Atomic updates sound cool until you realize they require downloading massive OS image deltas alongside gigabytes of duplicated container runtimes. If you are on a metered internet connection, an unstable power grid, or a mechanical hard drive, a simple security patch turns into a multi-gigabyte download and a system-crippling I/O bottleneck. This architecture was clearly designed by developers with gigabit fiber, completely ignoring real-world infrastructure.

The Hardware Enablement Nightmare

When you hit a hardware edge case, like needing a proprietary Wi-Fi driver, compiling a custom DKMS module, or setting up a legacy printer, a mutable root lets you fix it in five minutes. An immutable system tells you to get lost. The root is read-only! Trying to layer kernel modules with tools like rpm-ostree adds massive fragility to the boot process and frequently leaves you rebooting into a broken state.

Warning

STAY AWAY! If your hardware needs out-of-tree drivers, immutable desktops can cause silent failures during kernel updates. Always verify your hardware compatibility unless you like playing Russian roulette with your boot loader.

The Destruction of POSIX Debugging Workflows

If you're a developer or sysadmin, get ready for a headache. Running a containerized user space on an immutable host completely breaks standard POSIX troubleshooting. Classic CLI tools like strace, perf, or gdb fail to work cleanly when processes are wrapped in read-only ostree layers and container namespaces. You are forced to jump through hoops; entering specific debug shells or bypassing namespaces, just to do basic system profiling. Talk about unnecessary friction!

The False Premise of Fragility

The loudest argument for desktop immutability is that traditional package managers break during updates, especially if your power cuts out. But in reality, this is a tiny edge case. Modern mutable package managers handle transactions with incredible reliability. Over-engineering your entire operating system just because someone might forget to plug in their laptop battery is solving a non-existent problem while ruining usability for everyone else.

More importantly, you do not need a read-only root to get atomic updates and boot rollbacks. Distributions like openSUSE (with Btrfs and Snapper) and SerpentOS prove that you can have a fully writable, standard mutable filesystem while enjoying transactional upgrades and snapshot recovery. Immutability is a massive, unnecessary straitjacket that over-engineers a problem already solved by smart snapshotting.

The Container Vulnerability Matrix

Don't forget that sandboxing frameworks add their own complex code—and therefore, their own security bugs. When the container manager itself gets hit with a CVE (like sandbox escapes allowing arbitrary code execution), your supposedly "secure" environment is instantly compromised. Adding endless layers of abstraction doesn't magically eliminate bugs; it just moves them to a place that's much harder to debug and, guess what? There are potentially millions of systems with your exact same configuration now. The attacker's wet dream!

Loss of Technological Sovereignty

An operating system should empower you to own your hardware, not treat you like a guest. Immutability demotes the system administrator to a mere consumer of upstream images, stripping away granular, read-write control of the filesystem. For any engineer or developer, this feels like a straightjacket, fundamentally contradicting the core ethos of Free Software and technological sovereignty.

Oh, but my favorite is, by far, "Now ma Grand ma' cannot destroy the installation"... I mean, who gives root to their grandma? Sheesh!

Unnecessary Indirection

Sure, some immutable desktop defenders will tell you that I'm wrong; that you can easily get around these limitations by spinning up a container, tweaking config files, and rebooting. But do you see the catch? Indirection! You are introducing a Matryoshka doll effect. Now, you have to dig through logs inside the container, correlate them with logs outside the container, and pray nothing breaks when the container is rebuilt. You've just tripled the effort required to debug a simple issue. No thanks!

And honestly: you don't need a locked-down host to run containers. You can run Flatpaks, Podman, and Distrobox on Arch Linux or Debian today, keeping your application lifecycle decoupled from the host OS without surrendering control of your own system binaries.

Conclusion

Look, immutable systems have won the server room and the appliance market, and they deserved to. But until the desktop ecosystem can solve the supply chain, memory bloat, and hardware enablement crises inherent to containerized delivery, forcing a read-only root onto the general public is just academic arrogance over practical engineering. Keep the desktop mutable, keep it open, and keep owning your hardware!

Cómo convertir AlmaLinux 10 a CentOS Stream 10

Posted by Rénich Bon Ćirić on 2026-06-17 22:10:00 UTC

La neta, a veces el internet te da sorpresas chidas. Hace unos días, un compa en la red me ofreció donar dos servidores virtuales para mi proyecto de MxOS. ¡Un parote, la verdad! Pero como en todo, siempre hay un "pero": las únicas opciones de sistema operativo que me ofrecía eran Rocky Linux o AlmaLinux.

Y ahí estuvo el detalle. Para MxOS, tener CentOS Stream 10 es un requerimiento a huevo. Así que, en lugar de ponerle peros a la donación, me puse a investigar cómo cambiar el alma de esos servidores. Al final, encontré el caminito para convertir AlmaLinux 10 a CentOS Stream 10 de volada.

El Script Salvador

Para no andar haciendo todo a mano y arriesgarme a que algo valiera madres, me armé un script de Bash bien perro. Aquí te comparto el cotorreo de cómo quedó:

Note

¡Mucho ojo con las versiones! Las URLs de los paquetes en el script apuntan a la versión 10.0-23.el10. Como CentOS Stream 10 se actualiza de manera continua, es muy probable que esas versiones ya hayan cambiado en el mirror. Antes de correr el script, échale un ojo a mirror.stream.centos.org para verificar los nombres exactos de los archivos RPM más recientes de centos-gpg-keys, centos-stream-repos y centos-stream-release.

#!/usr/bin/bash

# download almalinux release, repos and gpg-keys rpms
# just in case
dnf download almalinux-{release,repos,gpg-keys}

# install cs10's repos and gpg keys
dnf -y install \
     https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/Packages/centos-gpg-keys-10.0-23.el10.noarch.rpm \
     https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/Packages/centos-stream-repos-10.0-23.el10.noarch.rpm

# remove the almalinux files
rpm -e --nodeps almalinux-release almalinux-repos almalinux-gpg-keys

# install the cs10 release
dnf -y install \
     https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/Packages/centos-stream-release-10.0-23.el10.noarch.rpm

# sync
dnf -y distrosync --allowerasing

# fix SELinux labels
fixfiles onboot

# reboot
reboot

Explicación del Jale

A primera vista parece magia, pero la neta es pura lógica de administración de paquetes de Red Hat. Deja te explico paso a paso qué hace cada comando de esta rola:

  1. Respaldar por si las dudas: El comando dnf download baja los paquetes de release, repos y llaves GPG de AlmaLinux al directorio actual. Si todo sale mal, tener estos archivos a la mano es un salvavidas por si tenemos que dar reversa.
  2. Inyectar los repositorios de CentOS Stream 10: Instalamos directamente las llaves GPG y la configuración de los repositorios oficiales de CentOS Stream 10 apuntando a los mirrors de CentOS. En este punto, el sistema conoce los repos de ambos mundos.
  3. Desinstalar AlmaLinux sin romper dependencias (La Táctica): Aquí está el verdadero truco. Como almalinux-release es un paquete protegido, DNF jamás te dejará removerlo ni cambiarlo por las buenas. Usamos rpm -e --nodeps para saltarnos la protección de DNF y quitar quirúrgicamente la identidad de AlmaLinux sin que intente llevarse de encuentro medio sistema.
  4. Instalar la identidad de CentOS Stream 10: Instalamos el paquete centos-stream-release usando DNF. Ahora el sistema se reconoce a sí mismo como CentOS Stream.
  5. La gran sincronización: Aquí es donde ocurre la magia real. Al correr dnf distrosync --allowerasing, le ordenamos a DNF que sincronice todos los paquetes instalados con las versiones disponibles en los repositorios de CentOS Stream 10, permitiendo borrar cualquier paquete conflictivo que ande estorbando.
  6. Alinear SELinux: ¡Mucho ojo con esto, compa! Como cambiamos la distribución y muchos paquetes cambiaron de dueño, los contextos de archivos de SELinux pueden quedar hechos un desmadre. Correr fixfiles onboot asegura que en el siguiente arranque se haga un re-etiquetado completo de todo el disco, evitando que SELinux nos bloquee servicios clave.
  7. El reinicio final: Reiniciamos la máquina para entrar limpiecitos con el nuevo kernel y con las etiquetas de SELinux bien alineadas.

Conclusiones

Hacer este tipo de migraciones antes daba mello, pero con las herramientas modernas la neta es que es un proceso bastante noble. Aunque la persona que ofreció los servidores se me desapareció y no tengo los servidores todavía, estuvo bueno el reto para aprender a hacer esto si nos vuelven a ofrecer esto para MxOS.

¿Cómo la ves? Si alguna vez te donan servidores y no vienen con tu sabor preferido de Linux, ya te la sabes: ¡todo tiene solución, no?!

Warning

Esto se pudiera complicar si usas repositorios externos o instalas paquetes que no vienen en los repositorios. Es de sabios hacer pruebas primero, carnal.

Taking a break is good

Posted by Ben Cotton on 2026-06-17 12:00:00 UTC

Earlier this week, curl project lead Daniel Stenberg announced the “curl summer of bliss“. For just over a month, the maintainers will be taking a break. This includes not accepting any vulnerability reports. This is a good thing.

Most open source software relies in part or in total on the work of volunteers. Nothing can cause burnout quite like never getting a break. Even when someone is being paid to maintain software, they still need some time away. Taking time off is an investment in the long-term sustainability of the project.

“But this is bad for security!” you say. Yes, some vulnerabilities may go unaddressed. You get what you pay for sometimes. Stenberg made clear in his post that people with support contracts will still receive their agreed level of service. If the security of the project is important enough to you, there’s something you can do about it. curl has seen a large increase in security reports this year. If a month off buys extra years of maintenance, that seems like a good trade.

It’s easy for open source contributors to get wrapped up in the project. It becomes part of their identity and they sometimes feel like the project couldn’t run without them. In some cases, that’s true. But we’re all still people and we need time to regroup. If you find yourself overwhelmed, you can take a break.

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

The post Taking a break is good appeared first on Duck Alignment Academy.

Web-Based Remote Installation for Fedora Linux: Here’s What We’re Building

Posted by Fedora Magazine on 2026-06-17 08:00:00 UTC

If you’ve ever needed to install Fedora Linux on a headless server, a Raspberry Pi, or any machine without a monitor attached, you’ve probably reached for VNC or RDP. They work – but as the installer moves to a web-based interface, there’s a new opportunity to do something more native to that model. We’re building it, and we want your input before we go too far down a path that’s hard to reverse.

Why This Is Happening

The Anaconda installer’s Web UI first landed in Fedora Linux 42 Workstation and was extended to all Live spins in Fedora Linux 43. It’s a full graphical installer built on Cockpit tooling and using PatternFly widgets. The GUI is rendered in a fullscreen browser window – but until now, that browser had to be running on the same machine you’re installing onto.

Here’s the thing: VNC and RDP were built around the GTK interface. While RDP could technically work with the Web UI too (it operates at the display level), a remote browser is a much better fit – orders of magnitude less data and much lower UI latency. As the Web UI becomes the primary installer interface across Fedora Linux editions, it needs its own native remote access story.

On top of that, there are two more forces pushing in the same direction.

As browsers move toward Flatpak packaging – already the reality for atomic desktops and derivatives like Bazzite – remote installation opens an opportunity for shipping focused, smaller boot images that don’t need to bundle a local browser at all. A lightweight ISO aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine.

And once you have a browser-rendered installer, serving it to a remote browser is the natural next step anyway. A headless ARM SBC doesn’t need to run a GPU-accelerated browser locally just to show you a disk partitioning screen. Your laptop can do that for it.

What It Actually Is

The concept is pretty straightforward: Anaconda’s Web UI, already built on Cockpit, gets served over HTTPS. You point a browser at the machine you’re installing, authenticate with a PIN, and you’re controlling the installation remotely. No VNC client, no RDP client, no X forwarding. Just a browser.

If you’ve used Cockpit to manage a server, you already have a feel for the experience. The difference is that the machine you’re connecting to is mid-install, not running a full OS.

Use Cases

The ones we’ve talked through most:

Headless servers – You’re installing onto a server in a rack with no attached display. You expose the Web UI over the network and control everything from your workstation.

Lightweight ARM SBCs – Devices like Raspberry Pi have limited resources. With remote rendering, the Pi just runs the installer backend; all the UI rendering happens on whatever machine you’re connecting from.

Remote monitoring – Even if you’re not fully headless, being able to watch an installation from another machine is genuinely useful. Kick off a server install, go make coffee, check progress from your laptop.

The Design Decisions So Far

We’ve had some meaty discussions about how this should work, and a few things are now settled.

Authentication: You set a PIN through kickstart or boot options, and type it into the browser login page. Same pattern as VNC and RDP – the user provides the password, not the system.

TLS with self-signed certificates: The connection is encrypted, but the certificate is generated on the fly at boot. That means your browser will show the “this certificate isn’t trusted” warning. We’ve accepted this tradeoff – shipping a private key on installation media is a security risk, and the IP address isn’t known ahead of time, so standard PKI doesn’t really apply. For environments that need proper certificates (say, a university deploying at scale), Image Builder is likely the right path to embed custom certs. That’s a later problem.

Single connection only: Only one browser session can connect at a time. Two concurrent sessions could genuinely conflict – one session starting installation while another changes the storage configuration. So: one connection, full stop.

Reconnection behavior: If you disconnect and reconnect, what happens depends on where the installation was. Before the review screen – the point of no return – you start from step one. After the review screen (installation actually running), you land on the progress view. Simple two-state model, covers the critical cases.

Config isolation and port: All Cockpit configuration specific to remote installation lives in /etc/anaconda/cockpit/, not the default Cockpit paths – otherwise the config could leak into the installed system. We’re leaning toward port 443 by default so you can just point your browser at the machine’s IP without specifying a port, but the port will also be configurable.

How This Compares to VNC and RDP

VNC has been around in Anaconda for years; RDP support was added more recently. Both work by screen-sharing the GTK interface. Technically, RDP could work with the Web UI too – it operates at the display level, scraping pixels from the screen. But a remote browser is simply better: you send orders of magnitude less data and get much lower UI latency compared to streaming a full desktop.

Beyond performance, there are practical advantages. No client is required – any modern browser works. No VNC viewer to install, no RDP client to configure, no protocol quirks across platforms. And it’s the same Web UI we’re already actively developing, so features and fixes automatically benefit the remote experience. With VNC or RDP, you’re screen-sharing a separate GTK codebase – a separate maintenance burden.

VNC and RDP aren’t going away for now – they still work with the GTK legacy interface. But as the Web UI becomes the default across more Fedora Linux editions, browser-based remote access is where the investment goes.

Where We Are Right Now

This is a developer preview. Here’s what’s working:

  • Custom login page with PIN-based authentication
  • Separate socket-activated systemd unit for auth (clean separation from the main Cockpit process)
  • Session cookies that survive tab closes, require re-login on browser close
  • Cockpit config in an isolated, anaconda-owned path

Here’s what’s still open:

  • Single-connection enforcement (this will likely require close collaboration with the Cockpit team)
  • Backend detection of whether installation is already running (this is needed for proper reconnection behavior)

If you want to see the PoC in action, there’s a draft PR at rhinstaller/anaconda-webui#1274 with the authentication setup – custom login page, pin-based auth script, socket-activated systemd units, and the Cockpit config override. To try it yourself, clone the PR branch, build an updates image, and boot it with virt-install:

git clone -b poc-remote https://github.com/bruno-fs/anaconda-webui.git
cd anaconda-webui
make create-updates.img

virt-install \
  --name anaconda-remote-test \
  --ram 4096 \
  --vcpus 2 \
  --disk size=20 \
  --location /path/to/Fedora-Everything-netinst-x86_64-Rawhide.iso \
  --extra-arg "inst.updates=http://your-host:port/updates.img" \
  --extra-arg "inst.webui.remote"

This is a proof of concept, not production-ready code. The PIN is hardcoded to 1234, there’s no TLS, and single-connection enforcement isn’t in place yet. Don’t use this for real installations – it’s meant to show the direction and let you poke at the approach. Once the installer boots, point a browser at the VM’s IP and enter 1234 on the login page. It’s rough, but it runs.

What We Want to Hear From You

We’re sharing this now because some of these decisions are hard to unwind once the feature ships, and community input is more useful now than after the fact. A few things we’re genuinely thinking about:

Remote installation is opt-in – you enable it through boot options or kickstart. But here’s a question we’re genuinely considering: should we ship a lightweight boot ISO without a local browser, with remote installation enabled by default? A minimal image aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine. Would that be useful to you? And if you’re using VNC or RDP for remote installation today, would this replace them? What would it need to do that it doesn’t yet?

Come talk to us on Matrix (#anaconda:fedoraproject.org), or leave a comment on this article. You can also follow the work on the anaconda-webui GitHub repo. We’re looking forward to hearing from you.

Flock to Fedora report 2026

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

This post is tough to write because Flock to Fedora is my favorite conference, and last year’s Flock might have been the best conference I’ve ever been to. I love the Fedora community, Prague is beautiful, the venue is nice, we always have so many interesting talks and workshops, the organizers do an amazing job preparing this event for us, so I feel really guilty saying that I did not have much fun this year. That is 100% on me, though. Flock bears no blame.

It wasn’t exactly the wisest decision ever to run my first half-marathon the very evening before the conference, and then waking up early to commute to Prague. It must have hit me much more than I was willing to admit. I feel fine physically, but I can’t pay attention to anything because nothing feels exciting. That is the most lifeless I’ve felt in a long time.

So, in case anyone is wondering … it was me, not you.

Highlights

Despite all that, these were the highlights of the event for me.

Forging Fedora Project’s Future With Forgejo

Great job on the migration from pagure.io to forge.fedoraproject.org. It was handled exceptionally well. Next, we look forward to the migration of src.fedoraproject.org to Forgejo, which can’t come soon enough. Tomáš Hrčka teased us that this migration may take considerably less time than the previous one because they already know how to do things (e.g., deploy Forgejo, etc).

DIY AI: Build a Private, Customizable Chatbot on Lean Hardware

Ellis Low showed us how to run an LLM on our laptops through Llama and how to interact with it. I really appreciated him saying that, except for this one small text-in, text-out magic black box, everything else is standard software engineering as we know it.

Fedora Council Strategic Proposals + FESCo Q&A

Most of the discussion revolved around a decline of new contributors and us failing to connect with the next generation. “They talk about changing wallpaper, we talk about burnout” – Aleksandra Fedorova.

What’s Cooking in Copr, Testing Farm, tmt, Packit and Log Detective

I found Pavel Raiskup’s return to the stage hilarious.

Scrapers gotta scrape scrape scrape

As presentations go, Kevin Fenzi’s talk about AI scrapers was the best. It started with minor A/V dificulities, which is a nice reminder to not feel bad, the next time it happens to you, because it happens to everybody. Even the main infra guy. Semi-joking aside, I enjoyed the brief history of web scraping and Kevin’s taxonomy of scrapers, clearly showing that not all scrapers are the same (e.g., web.archive.org). However, the current AI scrapers are the plague of the internet, and I am so glad the Fedora Infra team fights them as best as they can to keep our services running.

Chat with Adam

I ran into my former Copr team mate Adam Šamalík in the hallway, and we had a nice chat about life. When we still worked together (10 years ago, oh how the time flies), I randomly asked him what he did on a weekend. “We had no plans, so we bought plane tickets and went on a date to Amsterdam with my girlfriend”. Fucking what?! That was the coolest response ever. Since that day, I remember it every time my creaking, lazy bones struggle to do something spontaneous. Why am I telling it now? Adam is now happily living in the Netherlands full-time. Funny how one impromptu decision can completely change your life.

Chat with Emmanuel

Made friends with Emmanuel Seyman. He said hello after seeing the Fedora Podcast episode with me as a guest. I really enjoyed our chat, and I am going to follow up online because I think he’ll really like Sundaram Krishnan’s project coprtree.

Chat with Miro

Miro Hrončok shared some of his ideas about improving the Fedora Package Review Process with me. This deserves an article on its own, so stay tuned.

What’s Next for Pagure.io?!

Posted by Fedora Magazine on 2026-06-16 14:59:15 UTC

At the Flock 2026 Birds of a Feather session, poetically named FFFwF (or, for us lazy people, Forging Fedora’s Future with Forgejo), we discussed the current state of our migration effort to the new forge. I asked the obligatory question: Who still has things on pagure.io?!

A few brave contributors raised their hands, some with an uneasy look in their eyes. Miro swiftly pointed out that everybody is affected by one particular repository; looking at you, `fedora-scm-requests`. Luckily, the RelEng folks have it in their sights. Sure, there are a few other repos lying around the old faithful, but it is time for the Fedora Project to move on and embrace the Forge.

Our new home is currently running on the LTS branch in v15.0.2. We are going to stick with it in production, and our next LTS upgrade will be to v19.

What is going to happen next?

Pagure itself as a project is hosted on pagure.io, and that service is going to be decommissioned at the end of July 2026. What does that mean for you? Well, that depends on when you are reading this.

If you just came back from Flock 2026 and you still have active repositories on pagure.io, here is what you need to do:

  • Check out the existing organizations in the Forge. If your project fits into any of the existing ones, ask its owners for a migration.

Some of us have commits in projects that point back to pagure.io. Don’t worry, we are not going to break your links, for foreseeable future. We will explore options for implementing redirects so your historical links successfully point to their current locations.

The best way to handle the transition after your move, right now, is to inform your users about your new home. Add a BIG BOLD ANNOUNCEMENT to your README, close all open issues, and create a single pinned issue with your migration announcement.

Note: Do not expect to be able to log in to pagure.io after July 2026.

Wait… and what about `dist-git`?

Well, that is the next target in the scopes of the Forge team. As I showed you in the room, we have 11 Features that define the transition. The biggest task at hand is a bit more sneaky. We are missing multiple enhancements to the upstream project that will require a lot of coordination and Go code. So, if you find yourself in possession of spare cycles and a particular need to help us make it better and faster, Forgejo is waiting for you!

A road-map with all the tasks for the move will land in the Forge soon. (See resource list below.)

Important Links & Resources

  • Check out the new home: Browse existing organizations on the new Fedora Forge
  • Want to write some Go? Contribute to the upstream Forgejo project.
  • Track our progress: Migration roadmap will be posted here soon

AI Disclaimer: Grammar and formatting were done with the help of robots; all the original brain-farts are my own.

syslog-ng 4.12.0, syslog-ng PE 8.2.0 and SSB 7.8.0 are now available

Posted by Peter Czanik on 2026-06-16 14:50:23 UTC

Today, the syslog-ng team released three different syslog-ng versions, which provided a good opportunity to wear my “Release is coming” t-shirt. This coordinated release is due to an SQL injection security bug fix, even if most likely it affects less than a handful of people (I mean, is there anyone who still uses SQL to store logs in 2026…?)

Release is coming

What’s new?

  • syslog-ng OSE 4.12.0 arrives with performance optimizations, making syslog-ng more scalable in several situations. Many user-reported bugs were fixed as well. RPM-based containers are now available, utilizing Alma Linux under the hood.
  • syslog-ng PE 8.2.0 focused on bug fixes and now also allows users to use extremely complex configuration files.
  • SSB 7.8.0 adds support for Proxmox and Nutanix virtualization.

What’s next?

For more details, check the respective release notes. The syslog-ng OSE release notes are available at https://github.com/syslog-ng/syslog-ng/releases/tag/syslog-ng-4.12.0 Release notes for the commercial products should be available soon at https://docs.oneidentity.com

syslog-ng logo

From Contributor to Outreachy Intern: My Fedora Journey Begins

Posted by Fedora Community Blog on 2026-06-16 12:00:00 UTC

Introduction

Hi, I’m Aman, a software developer and open-source enthusiast who enjoys backend development, APIs, and building tools that are useful to others.

I recently started my Outreachy internship with the Fedora community, and this is my first blog as an intern. In this post, I want to share what my first two weeks have been like, what I’ve learned so far, and what I’m looking forward to in the next phase of the internship.

I’m working on the Fedora Release Schedule Planner API, a project focused on improving Fedora’s release planning workflow by moving away from older XML-heavy processes and strengthening the current FastAPI-based API through better tests, authentication, and infrastructure integration.

About the Fedora Community

Fedora is a global open-source community behind Fedora Linux and many related projects. People contribute in many areas, including packaging, infrastructure, design, documentation, testing, and release engineering.

One thing I’ve enjoyed learning about Fedora is its Four Foundations: Freedom, Friends, Features, and First. These values reflect Fedora’s focus on free and open-source software, community, innovation, and adopting new technologies early.

What I like about Fedora is that it is not only about writing code. Communication, documentation, reviews, and helping new contributors are also important parts of the community.

Through this internship, I’m also getting a better understanding of Fedora’s release process and how different contributors work together to improve the tools used by the community.

About My Project

My Outreachy project is Enhancing the Fedora Release Schedule Planner API.

Fedora’s traditional release planning workflow relied heavily on manually edited XML files, which made the process difficult for newcomers, harder to scale, and less connected to modern tooling.

The Fedora Release Schedule Planner API is a modern FastAPI-based project hosted on Codeberg. It has already moved from Flask to a modular FastAPI architecture, uses Pydantic for data validation, provides auto-generated Swagger documentation, and relies on Forgejo Actions for CI/CD testing.

The goal of my internship is to help make this API more production-ready. My work will focus on improving the test suite, strengthening CI reliability, adding secure authentication with OpenID Connect, integrating the API with Fedora infrastructure data, and preparing it for deployment.

Learning More About the Community

I had already started contributing to the Fedora Release Schedule Planner API during the Outreachy contribution period. During that time, I joined the project’s Matrix chat, went through issues and pull requests, and became familiar with the basic project structure.

So, during the first two weeks of the internship, my focus was more on understanding the project in depth. I followed discussions in the Matrix chat, worked through issue and pull request conversations, and learned how mentors and maintainers review changes.

We also have a weekly Google Meet call with the mentors. These calls are helpful for discussing progress, asking questions, and understanding what to focus on next.

Alongside exploring the codebase, I spent time reading Fedora documentation and project-related resources to better understand the release planning workflow.

I also explored the FastAPI codebase, tests, CI setup, and previous pull requests more closely. This helped me understand how tools like Pydantic, Swagger documentation, and Forgejo Actions are being used in the project.

Challenges and Wins

One of my biggest challenges in the first two weeks was understanding the codebase beyond its basic structure. During the contribution period, I had already become familiar with the main parts of the project, but during the internship, I started understanding how different layers work together, including API routes, database models, Pydantic schemas, services, templates, and tests.

Another challenge was making sure my changes did not affect existing behavior. I had to run tests, check formatting, and verify things locally before updating a pull request.

My biggest win was becoming more confident with the project workflow. I was able to work on issues, raise pull requests, respond to review feedback, and understand the expectations around code quality and maintainability.

I also became more comfortable with the tools used in the project, including FastAPI, SQLAlchemy, Pydantic, Jinja2, HTMX, tests, and CI checks.

A small win for me was getting some of my pull requests merged. For example, PR #425 and PR #427 helped me understand the review process better and gave me more confidence while working on the project.

Plans for the Next Month

In the next month, I want to continue building on the work from the first few weeks. Currently, we are focusing on fixing UI-related issues, improving the code structure, and aligning the codebase with the project’s expected structure.

Along with that, I want to keep improving the test suite and make sure the API works correctly with the current FastAPI and Pydantic structure.

I also want to start preparing for the authentication part of the project. Since OpenID Connect is an important goal of this internship, I plan to spend time understanding how Fedora authentication works and how it can fit into the Release Schedule Planner API.

After that, I want to gradually learn more about how this API can connect with Fedora infrastructure data. This is important because the long-term goal of the project is to move away from the older XML-based workflow and make the release planning process more modern and maintainable.

Conclusion

These first two weeks have helped me understand the project better. I now have a clearer understanding of the Fedora community, the Release Schedule Planner API, and how people collaborate in open source.

I still have many things to learn, but I feel more comfortable with the project now than I did at the beginning of the internship.

I am thankful to Outreachy, Fedora, and my mentors for this opportunity, and I am looking forward to continuing the work in the coming weeks.

PS: Cover image generated with the help of an AI tool.

The post From Contributor to Outreachy Intern: My Fedora Journey Begins appeared first on Fedora Community Blog.

Deux nouvelles versions majeures pour SeedboxSync et SeedboxSyncFrontend

Posted by Guillaume Kulakowski on 2026-06-15 18:55:11 UTC
Ce week-end marque la sortie de deux versions majeures de mes projets SeedboxSync et SeedboxSyncFrontend. Au programme : support FTP, optimisations de performances, suivi en temps réel des téléchargements, administration depuis l'interface web et plusieurs améliorations de l'expérience utilisateur.

Sandbox AI coding agents with microVMs on Fedora Linux

Posted by Fedora Magazine on 2026-06-15 08:00:00 UTC

AI coding agents such as Claude code or Codex get more capable every month. This is great for productivity, but approving all commands gets annoying really quickly. On the other hand, allowing agents to run any command on your work machine is not a great idea. They are really good at exploring your production cluster using kubectl or running remote commands at your production servers over SSH.

Fortunately, Linux distributions come with plenty of options for process isolation. You can run agents as a completely different user, in a container, or in a VM. This article shows how to use microVMs to run coding agents.

Security concerns

Running AI agents in unattended mode is like running untrusted code. Companies behind these agents, such as Anthropic or Google, are not trying to steal credentials, but people keep coming up with new attack vectors like Slopsquatting or prompt injections virtually anywhere.

The coding agents themselves ship with built-in mitigations that try to refuse prompt injections as described, for example, here.

Lightweight sandboxing technologies are another layer of defense in coding agents. On Linux, bwrap is one of the possible implementations. This raises the bar, yet sandbox escapes are still a problem. Take a look at CVE-2026-39861 as an example of multi-platform sandbox escape.

You could use containers to isolate the agent in their own namespace, but they still share the host kernel. Some of the the recent kernel vulnerabilities resulted in privilege escalation (switching from regular user to root) suggesting that containers are not enough as a security boundary.

In the rest of this article, I describe how to use microVMs to easily sandbox coding agents on your Fedora Linux.

Exploring microVMs

First of all, let’s take a look at what microVMs are. Just like any VM, they have their own kernel, one per each microVM. Compared to traditional VMs they start in very short time (hundreds of milliseconds) but don’t offer all the features of full VMs.

This article explains usage of krun runtime for podman. This approach offers the same well-known workflow as containers, but simply runs every container as a microVM.

Start by installing the runtime:

dnf install crun-krun

To run a microVM, simply run podman with –runtime=krun in your terminal:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

Things to watch out for

A microVM is not a regular container, so a few things might behave differently. First, allocate enough CPU and RAM with krun annotations. The defaults are too small and might result in OOM (Out Of Memory) kills. Second, make sure you have libkrun version >= 1.8. Older versions have a bug which prevents you from pressing Enter in your coding agent. Third, the microVM ignores the USER set in the Dockerfile and always boots as root. Either switch to the correct user manually or put the switch into an entrypoint script.

Case study: sandboxing Claude Code for a Python project

This section outlines a simple setup for a Python project managed by uv. It uses podman-compose to mount the project into the microVM. Compared to containers, this podman compose needs additional annotations for UID/GID translation, SELinux labeling, and HW resources. The final setup is very similar to what you would need for containers.

To install podman compose from official Fedora repositories, run:

dnf install podman-compose

The setup has 3 parts:

  • Dockerfile
  • docker-compose.yaml
  • entrypoint.sh

Dockerfile

As mentioned above, podman with krun runtime still runs containers, but spawns each of them in a microVM. This example container includes uv package manager, claude code and a few additional RPM packages. Define your own container based on your project dependencies and programming language.

Make sure to create an unprivileged user and use it for running the agent.

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Create group and user matching host UID/GID
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Rarely-changing tooling. Kept above the dnf layer so editing the RPM list
# below does not invalidate (and re-run) these installs.
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# Frequently-changing RPMs. Kept last so adding a package only rebuilds from here down.
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

# This is needed because entrypoint does not have .local/bin in the PATH
ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

docker-compose.yaml

The compose file defines how to mount the project directory into the microVM. This is where most of the magic happens, because podman needs to translate UID/GID and manage SELinux labels, otherwise the files would not be accessible inside of the microVM or they would end up being owned by a different user.

services:
  claude:
    container_name: project-name-claude
    annotations:
      run.oci.handler: krun
      krun.ram_mib: "4096"
      krun.cpus: "4"
    user: "${HOST_UID}:${HOST_GID}"
    userns_mode: keep-id  # optional, for rootless host
    build:
      context: .
      args:
        HOST_UID: "${HOST_UID}"  # use UID and GID from the host so that files created in the container have correct permissions
        HOST_GID: "${HOST_GID}"
    volumes:
      - ../:/app:U,z  # bind mount your project
      - project-name-venv-cache:/venv:U,z
      - claude-config:/home/appuser/.claude:U,z  # persistent claude credentials/config
    working_dir: /app
    stdin_open: true
    tty: true
    environment:
      - CLAUDE_CONFIG_DIR=/home/appuser/.claude
      - UV_LINK_MODE=copy
      - UV_PROJECT_ENVIRONMENT=/venv/env  # This is inside the cached volume
      - UV_PYTHON_INSTALL_DIR=/venv/python  # So that uv-managed python installations are not in home but cached in /venv
      - TERM=xterm-256color
      - COLORTERM=truecolor

volumes:
  project-name-venv-cache:
  claude-config:
    external: true
    name: claude-config

There are 3 key parts:

  • annotations – these select krun as a runtime and specify HW requirements
  • user and userns_mode – this tells podman to translate UID/GID so that the files created in the microVM end up owned by your user on the host
  • volume labels – z tells podman to relabel the files with a shared SELinux label. Otherwise SELinux would prevent the process inside the microVM from touching the files in the volume. U tells podman to recursively chown all files.

entrypoint.sh

The entrypoint creates a virtual environment for the Python project, because we don’t want dynamic dependencies baked into the container image. It also runs the switch from root to regular user because podman with krun runtime ignores the USER directive from the container.

#!/bin/bash
set -e

echo "Sandbox started as user: $(id -un) in directory: $(pwd)"

if [ "$(id -un)" != "appuser" ]; then
  runuser -u appuser -- uv sync
  echo "Running ${@} as appuser"
  exec runuser -u appuser -- "$@"
fi

uv sync
exec "$@"

Run the setup

First, build the container:

$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml build
STEP 1/18: FROM fedora:44
...
Successfully tagged localhost/agent-sandbox_claude:latest

Then create the external volume and run the claude container interactively:

$ podman volume create claude-config
$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml run --rm claude
Sandbox started as user: root in directory: /app
Resolved 3 packages in 6ms
Checked 3 packages in 1ms
Running /bin/bash as appuser
tty: ttyname error: Inappropriate ioctl for device
[appuser@3bd1234b9a77 app]$

You can now check that the kernel is different by running uname -a inside of the microVM.

Putting it together: single script to create the whole setup

Creating the same setup manually for every project is not the greatest user experience, but you can automate the setup using a simple script like this. It installs a new sbx command that wraps the setup described above into 3 simple command options: init, build, and run.

A word of caution — microVM is not a bulletproof boundary

A microVM raises the bar considerably, but it is not perfect isolation, and it would be irresponsible to present it as such. Take a look at the libkrun git repository to read more about the security model.

If you want to run software that might be dangerous, prefer using a full VM or even cloud VM.

Conclusion

MicroVMs seem like a sweet spot for running AI Agents. They provide a familiar workflow of containers, but the agents run on their own kernel behind a hypervisor. This article describes workflow based on podman and krun runtime because Fedora Linux ships both of them natively, but there are plenty of other options available for any platform (for example dockersandbox).

Note about AI usage: I wrote this article myself. I used Claude (Anthropic) to significantly refine the grammar, wording, and sentence structure; the technical content and all claims are my own and tested.

F44 Election Results

Posted by Fedora Community Blog on 2026-06-13 16:16:29 UTC

The F44 election cycle has concluded. Below are the results. We are posting the results early this year as we are currently on the eve of Flock to Fedora 2026 and the results were ready. Thank you to all candidates and voters, and congratulations to the newly elected members!

Results

Council

Two Council seats were open this election. A total of 204 voters participated in this election.

# votesCandidate
958Miro Hrončok
788Aleksandra Fedorova
744Fabio Valentini
637Tomáš Hrčka
509Vít Smolík
451Akashdeep Dhar
337Hristo Marinov

FESCo

Five FESCo seats were open this election. A total of 199 voters participated in this election

# votesCandidate
771Neal Gompa
700Fabio Valentini
662Michel Lind
604Maxwell G
549Simon de Vlieger
537Adam Miller

Mindshare

Four Mindshare seats were open this election. A total of 154 voters participated in this election.

# votesCandidate
419Samyak Jain
396Akashdeep Dhar
395Luis Bazan
351Mat H (Mat Holmes)
214Kenz S (Makenzie Stewart)

EPEL Steering Committee

Four EPEL Steering Committee seats were open this election. As the amount of interviews submitted equaled the number of open seats, candidates who interviewed were automatically elected.

# votes
Candidate
Automatically ElectedCarl George
Automatically ElectedDiego Herrera
Automatically ElectedJonathan Wright
Automatically ElectedTroy Dawson

The post F44 Election Results appeared first on Fedora Community Blog.

Justin Wheeler on Growing Up in the Fedora Community

Posted by Fedora Magazine on 2026-06-12 15:53:38 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

In 2015, an 18-year-old student walked into his first Flock not knowing a single person. He was shy, a little overwhelmed, and had no idea what he was walking into. By the time he walked out, something had shifted. The community had been so genuinely welcoming, so warm and easy to fall into that he left not just curious about Fedora, but hungry to be part of it.

That student was Justin Wheeler. And Flock never really let him go.

What started as one conference became a thread running through his entire open source journey. First he became a Fedora Magazine author. Then editor-in-chief. And now, as Fedora Community Architect, he’s the one standing on stage at the opening and closing looking out at the very kind of room that once changed his life helping shape the event that shaped him.


He’ll be the first to admit it’s a lot. “It’s way more intense and hard work than I ever could have realized,” he says, with genuine respect for everyone who built Flock before him. But that experience of once being the nervous newcomer gives him something no job description could have: an instinct for why people show up and what makes it matter.

For Justin, the answer has always been the hallway track. Not the sessions, the spaces in between them. The moment you bump into the exact person you need to talk to. The lunch conversation that turns into a collaboration. The game night and candy swap where the ice finally breaks and people stop being usernames and start being friends. “It’s the relationships we get to strengthen and build,” he says, “that make us so much more effective in everything we do the rest of the year.”

That’s also what data can’t capture and Justin thinks about this a lot as part of the Data Working Group, where he works alongside Michael Winters and Robert Wright to understand community health. Numbers can tell you a lot. But they can’t show you a first-timer lighting up when they realise they belong here. They can’t measure the moment the community becomes real.

His advice for anyone walking into Flock for the first time? “Don’t be shy. Leave your comfort zone a little. And definitely don’t skip the social events.” He says it like someone who knows exactly what it feels like to need that push and exactly what’s waiting on the other side of it.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Friday Links 26-19

Posted by Christof Damian on 2026-06-11 22:00:00 UTC
A tall wall of bookshelves packed with colorful paperbacks, fronted by leather armchairs, a round wooden table, and an antique globe

Two good engineering podcasts to listen to this week, the one about OpenCode and the one about spec-driven development. I also really enjoyed the video about the Watchmen comic and film.

Quote of the Week
I had not quite realized that the interruptions were the journey.
Jupiter's Travels
Ted Simon

Engineering

Building OpenCode with Dax Raad [Podcast] - I have been trying to use it with local models. Those are just not as good yet.

What you need to know about the Microsoft Secure Boot certificate expiration: Don’t Panic!

Posted by Fedora Magazine on 2026-06-11 08:00:00 UTC

UEFI Secure Boot keys, used to sign the first stage boot loader, are expiring in June 2026 (this month!) But that only means that Microsoft can no longer sign with them. Machines, both bare metal and virtual, will continue to boot long after June is over as long as the current public keys are not removed from the firmware database or revoked via the dbx database. In the meantime, Fedora Rawhide (f45) already contains a first stage boot loader that is signed by multiple keys for maximal compatibility. So there is no need to panic, but action is recommended.

Secure Boot basics

UEFI Secure Boot is a security feature which ensures only trusted (signed) applications run during a computer’s boot up process. This applies to the boot loaders, the operating system kernel, and the kernel modules. Trust is established using asymmetric cryptography. Tested algorithms, like RSA or ECDSA, are used to create asymmetric key pairs. The private key is used to sign the application. A totally different but complementary public key is used to verify the application. The private key is kept secret while the public key is available to anyone who wants to run the application. UEFI Secure Boot is only available for machines that run UEFI firmware, and for Fedora, the key expiration only applies to the x86_64 architecture (Intel, AMD), and to those who have Secure Boot enabled.

The root of trust for Secure Boot is in the firmware. Hardware manufacturers add trusted Secure Boot public keys to their devices’ Secure Boot firmware database (db). Firmware for virtualization, known as edk2-ovmf, is built with similar trusted public keys. In order to simplify the process, there is a central signing authority which signs the first stage boot loader. This is the “shim” whose public key is enrolled pretty much everywhere, and that is Microsoft. Microsoft first started signing shim with their 2011 UEFI Third Party CA, but by the end of June they will no longer be able to do so. Since October 2025, Microsoft began signing with a new 2023 key as well. Once the 2011 key expires, new shims will only be signed with the 2023 key.

The OS maintains the rest of the Secure Boot chain. Fedora’s shim embeds a Fedora Secure Boot public CA key. Private keys on Fedora’s signing server are used to sign the next stage boot loader (grub2), the kernel, and any other applications that need to run during the boot process (like fwupd for firmware updates or unified kernel images– UKIs)

When the kernel is built, kernel modules are signed using an ephemeral key. Only signed kernel modules can be loaded when Secure Boot is enabled.

Action Recommended

The fact is that you don’t really have to do anything about any of this right now. Your computer will continue to boot. New installations of both older and new OSes will continue to be possible.

BUT, we recommend updating your Secure Boot database if and when an update is available. The next deliverable shim update can only be signed by the 2023 key and it is best to be prepared. While there are no known exploitable security vulnerabilities in shim at this time, new ones may be found next month or next year. Below are some commands that will help you determine what state your computer is in, and how to make the correct updates.

How to tell if you have UEFI or legacy BIOS

The presence of the /sys/firmware/efi directory is the clearest way to check whether you are running UEFI firmware or legacy BIOS. The following command will print “BIOS” if the efi directory does not exist:

$ [[ -d /sys/firmware/efi ]] || echo BIOS

How to check if Secure Boot is enabled

$ mokutil --sb-state
SecureBoot enabled

The Secure Boot state may be “enabled”, “disabled”, or the machine may be in “Setup Mode”, which means there are no Secure Boot keys enrolled in firmware.

How to identify which keys are in the firmware db

$ mokutil --db --short
580a6f4cc4 Microsoft Windows Production PCA 2011
45a0fa3260 Windows UEFI CA 2023
46def63b5c Microsoft Corporation UEFI CA 2011
b5eeb4a670 Microsoft UEFI CA 2023

This output is from a VM, and as you can see, it already contains the 2011 and 2023 public keys. Your laptop or desktop will also show other database keys from the manufacturer.

How to update the firmware db

Enable and use fwupd to get your updates from the Linux Vendor Firmware Service (LVFS):

$ sudo fwupdmgr update

If you have an HP or Fujitsu machine, the update will be available soon, after you have updated your firmware. Use either the above command, or the vendor-recommended command at that time.

How to check which key(s) signed the shim

$ sudo dnf install pesign -y
$ sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi
----------------------------------------------
certificate address is 0x7f3fffc11410
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
----------------------------------------------
certificate address is 0x7f3fffc139e0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft UEFI CA 2023 signer
No signer email address.
No signing time included.
There were certs or crls included.
-----------------------------------------------

The output shown here is from the dual-signed Fedora Rawhide (F45) shim. If Rawhide is not installed, the shim will only be signed with the first key, which is the 2011 key.

You can use the same pesign command to examine grub2 (/boot/efi/EFI/fedora/grubx64.efi) and the kernel (/boot/vmlinuz-…).

What NOT to do

If a database update is not available for your system, contact your hardware manufacturer. Do not attempt to force an incompatible update. Do not update your database manually unless you know exactly what you are doing!

Do not remove or revoke the 2011 key. The 2011 key is not compromised, it is only expiring, so there is no need to remove it. Additionally, it was used to sign option ROMs, so removing it could render peripherals on your system inoperable. Likewise, adding the 2011 key to the firmware dbx database (the forbidden database) will affect option ROMs. This will stop the dual-signed shim from booting.

New badge: Czech Mate! !

Posted by Fedora Badges on 2026-06-11 05:35:14 UTC
Czech Mate!You joined the party at Flock 2026 in Prague!

Network issues

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

Switch upgrades were done this morning, and something has gone wrong with them. Networking engineers are working on restoring full service.

ipv6 access to some of our services is impacted, along with possible slowdowns in other services.

Small TLS settings modernization

Posted by Tomasz Torcz on 2026-06-10 11:48:25 UTC

Some time has passed since I've tightened TLS settings on my home server. Let's move it a notch higher, this time including home k3s cluster.

Use ECC certificates

In 2026, using elliptic curves cryptography certificates should be the norm. Fortunately, automatically obtaining them is easy. I'm using cert-manager for kubernetes ingresses. Switching to ECC is a just a matter of adding an algorithm annotation on Ingress:

annotations:
  cert-manager.io/cluster-issuer: "zerossl-production"
  cert-manager.io/private-key-algorithm: "ECDSA"

and removing the secret containing old cert and key.

Small caveat: FreeIPA still lags. While it supports ACME protocol, ECC through it is not possible, yet. I've left my internal domains with RSA certificates.

For the main server, I refresh certificates using small Ruby script. I had the change RSA.new(3072) to an EC key generation, rest happened automatically:

certificate_private_key = OpenSSL::PKey::EC.generate('prime256v1')
csr = Acme::Client::CertificateRequest.new(private_key: certificate_private_key, names: PIPEBREAKER_DOMAINS)

Use TLSv1.3 only

Last time I've limited support of Transport Layer Security to versions 1.2 and 1.3. Today, let's allow the latest only. I don't care about supporting Windows 7-era clients (years out of support).

Ingress on k3s is handled by Traefik. Simplest way to influence its config is by creating a global (named default) TLS configuration option:

apiVersion: traefik.io/v1alpha1
kind: TLSOption
metadata:
  name: default
  namespace: kube-system
spec:
  minVersion: VersionTLS13

That's all!

Change to nginx configuration on the main server is minimal, too. Version 1.2 is removed from the list, leaving only 1.3:

ssl_protocols TLSv1.3;

I have to tune Postfix and few other services TLS settings later.

065/100 of #100DaysToOffload

Jaroslav Reznik on Security, the EU Cyber Resilience Act, and Why You Can’t Do Things From Behind a Desk!

Posted by Fedora Magazine on 2026-06-10 08:00:00 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Jaroslav Reznik has been part of Fedora longer than most people remember. This goes all the way back to Red Hat Linux 5, before Fedora was even known as Fedora. After a brief detour to another distro, he joined the KDE SIG days and went on to build a long career in Red Hat’s Program Management team. But it was the EU Cyber Resilience Act (CRA) that brought him back to the Fedora community.

The moment that changed everything? A scene at FUDCon North America in 2009 watching Fedora’s Program Manager command what looked like a sci-fi control room, scheduling Fedora 13. Jaroslav looked at that and thought: I want that job. Years later, he got it.

On the CRA, Jaroslav is clear and passionate. The regulation is the first to formally acknowledge the existence of open source software in legislation. Thanks to an enormous community effort, it’s actually open-source friendly. Non-commercialised community projects are fully exempt. For a project like Fedora, the concept of open-source stewards formally recognised in the regulation opens up a powerful new model for governance.

The program management team is working to build a stewardship governance model around Fedora. They are making it a welcoming place for anyone who wants to support the project. They are clear about what stewardship should and shouldn’t be: it’s not about monetizing open source or adding burdens, it’s about helping the community raise the bar for security together.

Flock holds a special place for Jaroslav; he co-organised the very first Flock held in Prague back in 2014. Now, more than ten years later, he is returning to Prague for Flock 2026 with Roman Zhukov to not only talk about the CRA but run a hands-on workshop on it. His message is simple: you can’t do things from behind a desk.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Storytelling Analysis - Oshi No Ko (2023) Pilot Episode

Posted by Akashdeep Dhar on 2026-06-09 18:30:42 UTC
Storytelling Analysis - Oshi No Ko (2023) Pilot Episode

I have been appreciating YOASOBI's work for quite a while now. One of the reasons why I chose Oshi No Ko (2023)'s pilot episode as a means to end my long anime media hiatus was because their popular single and the anime series' opening music, Idol, also featured in one of my favourite videogames, Forza Horizon 6 (2026). Reading into the song's lyrics only made me further intrigued to understand just what the show was all about, given how this feature song was purposely composed for this anime series. My upcoming two hour long flight meant that I would end up having nothing but time to delve deeper into uncovering the darker secrets, all while keeping the boredom at bay by watching the show.

Storytelling Analysis - Oshi No Ko (2023) Pilot Episode
Oshi No Ko (2023)

Let me preface this with a disclaimer - I do not write reviews. Or at least, I do not write them until I feel compelled to do so. When I found myself calling up my friend right after landing from my Indigo flight, I realized this was something I would want to talk about. For someone who had sworn off anime media for almost over a couple of years now, I had little reason to return - let alone watch something that was already three years old. With the anime series itself getting refreshed for the fourth (and final) season, I could have watched something else. But for some reason, I stuck to Oshi No Ko (2023)'s pilot episode to keep me entertained on my flight from Pune to Kolkata, and boy, am I glad that I did that.

Storytelling Analysis - Oshi No Ko (2023) Pilot Episode
Gorou Anamiya and Sarina Tendouji - Oshi No Ko (2023)

The oddly long pilot episode wastes no time throwing you into the deep end. Whether it is about finding hope amidst overriding mediocrity (when it came to Gorou Amamiya), seeking life amidst impending despondency (when it came to Sarina Tendouji), or pursuing belonging amidst surrounding insincerity (when it came to Ai Hoshino) - everyone had their motivations. Also, unlike contemporary anime storytelling, the pilot episode was filled with tonal shifts, transitioning the emotional atmosphere from inescapable despair to heartwarming wholesomeness, and from whimsical fantasies to grounded realities. Along with tight pacing, the fifty eight minute long episode had absolutely zero dull moments.

Storytelling Analysis - Oshi No Ko (2023) Pilot Episode
Oshi No Ko (2023)

You know you have struck gold when you find yourself rooting for the side characters too. There was something charming about the likes of Miyako Saitou and Ichigo Saitou, with their personal approach towards nurturing the main characters all while battling their own demons in their desperate struggle. I felt recognized when the narrative trusted my viewing judgement - both when Taishi Gotanda elaborated on the dire state of the show business and when Kana Arima discovered her acting rival during the movie shooting. Every now and then, my inexperience in Japanese forced me to pause playback to take it all in, but the pilot episode had its own ways of rewarding attentive viewers with crucial details.

Storytelling Analysis - Oshi No Ko (2023) Pilot Episode
Miyako Saitou and Ichigo Saitou - Oshi No Ko (2023)

Their (subjectively appealing) stellar artstyle only ended up checking the remaining boxes for me. The evolving portrayals of Ruby Hoshino and Aqua Hoshino, both in their childish moments and precocious dealings, played a major part in establishing them as the bonafide protagonists of the anime series. From the (rather overused) cherry blossoms of the countryside to the (gloomily overcast) concrete jungle of Tokyo, Doga Kobo pulled no punches in ensuring that I moved into their narrative world the moment I pressed the play button. The (restrictively exceptional) environmental storytelling had social media, small talks, crowd discussions, and inner monologues - and honestly, I could not ask for more.

Storytelling Analysis - Oshi No Ko (2023) Pilot Episode
Hoshino Twins - Oshi No Ko (2023)

An Indigo flight changing altitudes is perhaps the worst place to get emotionally shaken, given how you would not want to have a huge lump in your throat all while struggling with blocked ears. If you are a chronic crier, do not watch the pilot episode in public unless you like getting emotionally overwhelmed amidst strangers. Trust me when I say this - the amazing narrative found multiple ways to pull me in by the heartstrings, and even I found my tears welling up in a couple of scenes. I felt weirdly familiar with and equally alienated by the mysterious actions of Ryousuke Sugano, which left me with more questions than answers. If that is what the pilot episode set out to achieve, they sure as heck succeeded.

Storytelling Analysis - Oshi No Ko (2023) Pilot Episode
Ruby Hoshino - Oshi No Ko (2023)

For a Comic Con hobbyist pilgrim making a prodigal return to anime media, there could not have been a better welcome for me. With the pilot episode covering the first couple of decades of (painstakingly detailed) storytelling progression in its narrative world, Oshi No Ko (2023) has a reliable foundation to build its story forward. It really did not make a difference to me that the series themes of show business and divine reincarnation are at odds with each other. I honestly did not care that the pilot episode had been spoiled for me about three years back, or that the anime series did not have an (absolutely logical) match with the Seinen demographic. All I wanted was the fun factor and I have had my fair share.

Storytelling Analysis - Oshi No Ko (2023) Pilot Episode
Aqua Hoshino - Oshi No Ko (2023)

The more I write about Oshi No Ko (2023)'s pilot episode - I am feeling like - the further I stray from writing a review and the closer I come to giving a recommendation. But as the (unfortunately shortened) Idol playback drops at the end of the pilot episode, I realized that that is what reviews are supposed to be – a compass that drives you away from poorly made anime media and closer to the good ones. And I do not state this lightly – the pilot episode has (most definitely) been among the best ones. I am already itching to see how the story progresses with Ruby and Aqua at the helm. Maybe I will get to do just that after I finish the Winter season's Festival Playlist in Forza Horizon 6 (2026), and so should you.

Forgejo's New Commit Page Design Is Here

Posted by Yashwanth Rathakrishnan on 2026-06-09 14:13:08 UTC
This blog covers the complete redesign of Forgejo’s commit page to fix mobile issues and improve usability, sharing the design process, bugs fixed, skills learned, and community collaboration that made it possible.

Onboarding a Forgejo-hosted project to Fedora Konflux

Posted by Fedora Community Blog on 2026-06-09 09:08:39 UTC

We, the Forge team, recently onboarded a Codeberg-hosted repo to the new Fedora Konflux instance.
This is a guide based on the onboarding experience, the steps and UI are similar in Fedora’s Forge.

Useful links

Step 1: Get access to the tenants-config GitLab repo

Konflux configuration is managed through GitOps in the
tenants-config
repo on GitLab. The UI is intended to be read-only — you should do everything through merge requests.

  • Sign in via SAML SSO at https://gitlab.com/groups/fedora/-/saml/sso to get
    group membership.
  • Make sure you have at least a Guest role. Guest lets you approve MRs
    but not merge them. Ask a maintainer to bump your role if needed.
  • Get yourself added to CODEOWNERS for your tenant’s directory
    Example MR.

Step 2: Create your tenant namespace

Konflux namespace.

Follow the instructions in the
tenants-config repo:

  • Run the create-tenant-resources playbook. It generates the namespace, RBAC
    and quota resources.

You end up with three files:

  • ns.yaml — the namespace with a konflux-ci.dev/type: tenant label
  • rbac.yaml — a RoleBinding granting konflux-admin-user-actions to your FAS
    user
  • kustomization.yaml — ties together the quota, RBAC, namespace and your
    applications directory. Quota can be increased later.

Then run the update-tenant-apps playbook to generate an ArgoCD application
manifest per tenant directory and update the ArgoCD kustomization.

Example MR.

Step 3: Define your Applications and Components

Konflux applications.

This is where you tell Konflux what to build. We went with a Kustomize
Configuration-as-Code setup with three layers:

  • A shared base — a generic Component template with the git URL, provider
    annotations (git-provider: forgejo, git-provider-url: https://codeberg.org),
    pipeline config and the build.appstudio.openshift.io/request: configure-pac
    annotation.
  • Per-application bases — an Application CR plus per-variant overrides (e.g.
    rawhide vs. stable).
  • Per-environment overlays (staging/production) — patches for application names,
    component names, context paths and Dockerfile paths.

Open a merge request with everything
Example MR.

Step 4: Add ImageRepository resources

Each Component needs a matching ImageRepository CR. If you don’t have one, the image controller
never provisions a Quay repo, spec.containerImage stays empty on the
Component, and the build service just sits there waiting. No webhook, no PaC PR,
nothing happens.

Example ImageRepository:

apiVersion: appstudio.redhat.com/v1alpha1
kind: ImageRepository
metadata:
  name: forge-rawhide-production
  namespace: fedora-infra-tenant
  annotations:
    image-controller.appstudio.redhat.com/update-component-image: "true"
  labels:
    appstudio.redhat.com/application: forge-production
    appstudio.redhat.com/component: forge-rawhide-production
spec:
  image:
    name: fedora-infra-tenant/forge-rawhide-production
    visibility: public

The update-component-image: "true" annotation is what tells the image
controller to write the Quay URL back to spec.containerImage on the Component.

Example MR. Do not merge yet.

Step 5: Create the SCM secret

Konflux needs a secret to authenticate with your Forgejo/Codeberg instance:

oc create secret generic pipelines-as-code-codeberg 
  -n {namespace} 
  --type=kubernetes.io/basic-auth 
  --from-literal=password={FORGEJO_TOKEN}

oc label secret pipelines-as-code-codeberg -n {namespace} 
  appstudio.redhat.com/credentials=scm 
  appstudio.redhat.com/scm.host=codeberg.org

The Konflux docs
say you need these token scopes:

  • issue: Read and Write
  • organization: Read
  • repository: Read and Write
  • user: Read

Don’t restrict the token to a specific repo — scopes like write:user aren’t
available with repo-scoped tokens on Forgejo. If you set the right scopes and
it still complains about insufficient permissions, try a token with everything
enabled.

Step 6: Merge and verify

With the secret in place, merge your MR. ArgoCD picks it up and syncs the
resources. Wait a few minutes, then check:

# Did containerImage get set?
oc get components -n {namespace} 
  -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containerImage'

# Are the ImageRepositories ready?
oc get imagerepositories -n {namespace} 
  -o custom-columns='NAME:.metadata.name,STATE:.status.state'

# What does the PaC status say?
oc get components -n {namespace} 
  -o custom-columns='NAME:.metadata.name,STATUS:.metadata.annotations.build.appstudio.openshift.io/status'

If spec.containerImage is filled in and the status shows "state":"enabled",
you’re good.

Step 7: Handle the PaC pull requests

Konflux opens pull requests on the source repo.

At this point Konflux opens PRs on your source repo with auto-generated Tekton
pipeline files in .tekton/. Two ways to go:

  • Merge them as-is if you’re happy with Konflux’s defaults.
  • Close them and use your own pipelines. If you already have .tekton/ files,
    update them with:
  • application/component labels matching your Konflux component names
  • output-image pointing to quay.io/redhat-user-workloads/{namespace}/{component}
  • latest task bundle versions (grab the @sha256:... refs from the
    Konflux-generated files)
  • serviceAccountName: build-pipeline-{component}

We went with the second option. We already had pipelines with custom version
tagging that we wanted to keep, so we pulled in the new task bundles and labels
from the generated files and left the rest alone.

Step 8: Re-triggering when things go wrong

The configure-pac annotation gets consumed on the first attempt. If it fails
(token issue, rate limit, whatever), you need to re-add it:

# One component
oc annotate component {component} -n {namespace} 
  build.appstudio.openshift.io/request=configure-pac --overwrite

# All of them
for comp in $(oc get components -n {namespace} -o name); do
  oc annotate $comp -n {namespace} 
    build.appstudio.openshift.io/request=configure-pac --overwrite
done

To sum it up, we created a tenant on Konflux-ci cluster, created applications and components and set a place where the images would be hosted. At the event of push to the codeberg repo main branch – the repo where we store the Forge Containerfiles, the pipeline gets triggered (scoped by the on-cel-expression to only those contexts where the change happened) and a fresh and tagged image appears on quay, ready for further testing and deployment.

Thanks to the Konflux Team for the Forgejo support!

The post Onboarding a Forgejo-hosted project to Fedora Konflux appeared first on Fedora Community Blog.

Peter Boy on Why Fedora Needs More Than Just Technical Contributors

Posted by Fedora Magazine on 2026-06-09 08:00:00 UTC

Peter Boy came to Fedora documentation the way many contributors do, by seeing a gap and deciding to fill it. As a researcher, writing is his daily work. When he looked at how he could meaningfully contribute to Fedora, documentation was the obvious answer. He started with Fedora Core 1, stepped away, and returned in 2020 when both the Server Working Group and the Docs Team were being revitalised at the same time. Since then, his focus has been on the “bigger-picture” content structure, readability, consistency, and inspiring others to get involved.

His first Flock was in Cork, Ireland in 2023, and what struck him most was the collaborative approach combined with open, structured dialogue and the sheer range of personalities all genuinely trying to get to know each other.


For a team like Docs, where so much depends on shared standards and careful communication, Peter sees Flock as irreplaceable. New ideas emerge from spontaneous conversation, something the formal structure of video calls simply can’t replicate. His message to anyone thinking about contributing? Fedora needs far more than technical contributors. Documentation, communication, community building these are all vital, and Fedora needs to do a better job of making that visible. At Flock 2026, he is most looking forward to the working groups and the hallway conversations, the ones that are simply too nuanced to have any other way.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Please Do Not Ban AI-Assisted Issue Reports

Posted by Michael Catanzaro on 2026-06-08 21:30:42 UTC

Many GNOME projects have adopted a policy banning all contributions generated by LLMs. This policy was originally developed by Sophie for Loupe, but is now used in many other notable places:

This project does not allow contributions generated by large languages models (LLMs) and chatbots. This ban includes, but is not limited to, tools like ChatGPT, Claude, Copilot, DeepSeek, and Devin AI. We are taking these steps as precaution due to the potential negative influence of AI generated content on quality, as well as likely copyright violations.

This ban of AI generated content applies to all parts of the projects, including, but not limited to, code, documentation, issues, and artworks. An exception applies for purely translating texts for issues and comments to English.

AI tools can be used to answer questions and find information. However, we encourage contributors to avoid them in favor of using existing documentation and our chats and forums. Since AI generated information is frequently misleading or false, we cannot supply support on anything referencing AI output.

I won’t attempt to argue that you should allow use of AI for writing code. If you wish to ban LLM-generated code, fine. That’s probably inadvisable, but I am not going to object.

But this policy is far stricter than that. Notably, it strictly prohibits AI-generated content in issue reports (except to translate text). Don’t do this! Prohibiting bug reports is stupid and just makes your software worse. Please make sure your project’s AI policy allows for at least AI-generated static analysis results and AI-generated vulnerability reports. Otherwise, you prohibit entirely unobjectionable problem reports.

It’s hard to imagine what could possibly be the value of prohibiting valid bug reports. AI-generated static analysis works well: the AI is able to think about your code, follow execution paths, and automatically discard most false positives to avoid bothering you with them, and the quality of reports is generally pretty high. They are far from perfect, but the same is true of humans.

Here is a typical example of an AI-generated static analysis finding:

2. Resource leak in update_credentials_cb on gnutls_credentials_set failure

  File: tls/gnutls/gtlsconnection-gnutls.c:169-172

  When gnutls_credentials_set() fails, the function returns without calling g_gnutls_certificate_credentials_unref(credentials). The credentials was either freshly allocated or ref-bumped, so it leaks.

Pasting this into an issue report clearly violates the ban on AI-generated content. And yet, why would you not want to receive a clear and concrete bug report for memory leak?

I understand not all maintainers are fond of AI, but is your dislike really so extreme that you would choose to ignore valid problems and intentionally make your software worse? If not, then your AI policy should thoughtfully consider how to handle AI-generated content in issue reports. Certainly do not adopt a policy that outright bans all AI-generated content in issue reports.

As an issue reporter, you could theoretically take the problem found by the AI and rephrase all the words, then claim that it is no longer AI-generated content because it is rewritten. This is a waste of time and usually results in a lower-quality, less-detailed result, but you could plausibly do that. Or, if you want to go above and beyond, you could just jump ahead to creating a merge request. But realistically, if your project does not allow any use of AI in issue reports, it’s more likely that either (a) you won’t receive the issue report in the first place, or (b) you won’t receive such issue reports from experienced developers who read and respect your policy, while users who do not read your policy will continue to submit them.

What about security vulnerability reports? Since the start of this year, I have reviewed well over 100 vulnerability reports that I strongly suspect were generated by AI. To reach the “over 100” claim, I sadly only considered vulnerability reports submitted during a particularly heavy four week period, so this is an extremely loose lower bound. Suffice to say, I have seen a lot of them. The quality varies dramatically. Vulnerability reports are now often better or worse than before: better because an experienced human working with a good AI is able to find vulnerabilities that would have surely gone unnoticed without AI, and worse because an inexperienced human with a bad AI might create some pretty terrible issue reports, a significant proportion of which are just outright spam. Low-quality reports remain a problem, but nowadays most AI-generated issue reports are quite good.

Maintainers do not need to tolerate spammy vulnerability reports. If an issue report is bad, of course go ahead and close it. If it’s really bad, then I sometimes don’t even bother replying. But banning good vulnerability reports solely because some portion of the report was generated by AI is unacceptable. AI-assisted vulnerability reports are the new industry standard, and this is not likely to change. Prohibiting issue reports reduces the quality and safety of your software, punishing your users. This is too extreme.

RIT Unny open source font

Posted by Rajeesh KV on 2026-06-08 11:14:05 UTC

E.P. Unny is a notable Indian political cartoonist, who worked/works with famed Shankar’s Weekly and new papers such as The Hindu and Indian Express.

Since 2020, all his cartoons (also 2025, 2026 so far) are published — every week — open-access by Sayahna Foundation.

Unny was using a font based on his handwriting style for the cartoons, designed by K.H. Hussain of Rachana. Recently, a new font designed by Varshini KVSS & ‘Kandam Collective’ is developed by Rachana Institute of Typography to use in the cartoons, and it is released as open source — see the specimen and download links.

The character set of the font is Latin only. There are plenty of alternate glyphs (for upper case and lower cases of i, j, l, g, etc. — for instance check the double ‘l’ in ‘Intelligence’ on the specimen above). Such characters are rendered alternately to give a feel of the randomness that handwriting evokes.

The source (and issue tracking) are available at RIT fonts repository.

From June 01 to June 07

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

Across the project, a primary focus was on technical modernization and infrastructure migration. This was highlighted by the major mass rebuild for Python 3.15 in Rawhide, the Workstation team's plans to replace several core desktop components like gnome-keyring and dbus-daemon, and the continued migration of services and repositories to the new Fedora Forge platform. Alongside these technical upgrades, there was a strong emphasis on improving governance and community processes, demonstrated by the Council's work on a new "Fedora Innovation Lifecycle," the official release of new forum moderation guidelines, and discussions within the Docs and EPEL teams to refine workflows and policies. Much of this work was contextualized by the upcoming Flock conference, which influenced planning and was identified as a venue for key in-person discussions. Other common themes included the development of new offerings, such as a home server spin-off and a new graphical UI for DNF, and a consistent focus on community engagement through the ongoing Fedora elections and numerous calls for new package maintainers.

Announcements

This week, the Fedora 44 elections voting period opened and will run until June 12th, with candidate interviews available for review (e.g., Vít Smolík, Tomáš Hrčka). For users of the forums, new self-moderation guidelines and rules have been released to improve transparency and formalize community standards. On the technical front, a major mass rebuild for Python 3.15 in Fedora 45 has begun and successfully concluded, and packagers can now safely build in Rawhide again. Contributors were also notified of a planned infrastructure outage for server updates. In news relevant to the broader community, a recent Fedora 43 upgrade helped uncover a 20-year-old security bug in Microsoft Outlook related to unencrypted connections.

In preparation for the upcoming Flock conference, the CommOps team launched the #Commit History campaign, inviting contributors to share their origin stories. Fedora Magazine continued its series of interviews with Flock speakers, featuring insights from Jef Spaleta, Valentin Rothberg, Aleksandra Fedorova, Akashdeep Dhar, and Jona Azizaj. Additionally, the weekly Community Update detailed progress across various teams, including work on Fedora Badges, RISC-V for F44, and QE bug fixes. A helpful guide on installing Fedora across two disks was also published.

Council

In their weekly meeting, the Council discussed several key governance topics. They reviewed the draft for a new Fedora Innovation Lifecycle, deciding to formally introduce it after the Flock conference to allow for more community context-building. The group also approved the new moderation guidelines for the Fedora Discussion forum and initiated a broader conversation about improving the representation of community moderators within Fedora's governance structures. A consensus emerged that the current "Initiatives" framework is ineffective and should be replaced, with further discussion planned. Ongoing forum topics included a proposal for a Fedora AI Ecosystem and the eligibility of teens running for Council.

Decisions

  • The Council agreed that the draft proposal for the Fedora Innovation Lifecycle will be formally proposed to the community after Flock. In the meantime, the Council will work to build more community awareness around it.
  • The Council approved the current moderation guidelines for the Fedora Discussion forum for publication. A new ticket will be created to discuss how community moderators can be better represented in Fedora's governance structures.
  • Regarding a past provenpackager revocation incident, the Council re-affirmed its decision not to publicly disclose confidential details of the incident. The focus will instead be on improving the Conflict of Interest Policy to prevent future issues.

Learn more about the Council team.

Mindshare

The main discussion for the Mindshare group this week continued to focus on the future of surveys within Fedora, specifically the proposal to shut down the LimeSurvey service. The topic was originally raised due to the sole maintainer's burnout, difficult billing changes, and community dissatisfaction with the quality of recent surveys. This week's contribution supported dropping LimeSurvey, suggesting that the Data WG could instead leverage existing, repeatable data sources for analysis. One example was using event data from Pretix via the Fedora message bus to gather insights on attendance, rather than relying on a survey. The idea of a specialized SIG for survey design was also raised to better separate statistical data gathering from simple feedback collection.

Learn more about the Mindshare team.

Workstation / GNOME

This week, the Workstation Working Group laid out plans for several significant technical transitions. Key initiatives include replacing the gnome-keyring daemon with 007, removing the legacy dbus-daemon to standardize on dbus-broker, and modernizing testing infrastructure by replacing xvfb-run with wl-headless-run. These efforts aim to streamline the desktop stack and align with modern practices. Contributor opportunities include finding a new maintainer for the orphaned Showtime package and helping update packages to use the new wl-headless-run testing utility.

In forum discussions, a proposal to undertake a chain of updates related to the mozjs JavaScript engine for the Cinnamon DE in Fedora 44 was debated. The consensus was to prioritize stability for the current release, deferring the larger migration but updating the existing mozjs128 package to include the latest security fixes. Another topic explored the possibility of creating a new Fedora edition for upcoming NVIDIA RTX Spark hardware, with community sentiment leaning towards leveraging existing AArch64 builds and creating documentation rather than introducing a new Spin.

Decisions

  • The gnome-keyring daemon will be replaced with 007 in Fedora Workstation, with work being managed to ensure a smooth transition.
  • A plan was initiated to remove the dbus-daemon package by addressing dependencies that pull it in, such as in the Anaconda installer.
  • The xvfb-run utility will be incrementally replaced with wl-headless-run for testing; this will be added to the package maintenance checklist.
  • Regarding the Cinnamon DE in Fedora 44, the decision was made to update the existing mozjs128 package but not to perform a larger migration to mozjs140 to avoid destabilizing a released version of Fedora.
  • A long-term goal was set to remove the libcanberra dependency from core desktop packages by rerouting sounds directly to PipeWire.
  • Newer LibreOffice dictionaries will be packaged and made available in parallel with existing aspell dictionaries to improve language support.

Learn more about the Workstation / GNOME team.

Server

The Server team held its weekly meeting with a strong focus on the development of a new home server spin-off. The main discussion revolved around user-friendly management and the initial software selection. The group reviewed a draft management guide, which led to a conversation about security practices for home use, including SSH key usage, firewall configuration, and remote access strategies. There was a consensus to leverage Ansible for configuration, with a plan to provide pre-configured playbooks to simplify setup for end-users. Using Cockpit for remote management was also highlighted as a secure and accessible option. The team also discussed which applications should be included by default, agreeing to start with a minimal set from the official Fedora repositories.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team's main operational focus was a planned mass update and reboot outage to apply the latest updates across servers. Significant progress was also made on the migration from Nagios to Zabbix for monitoring; the team is finalizing per-team notifications and is nearing the project's completion, with plans to announce the final switchover soon. Regular administrative tasks included reviewing the monthly AWS usage report and addressing untagged AWS resources.

A key topic of discussion was the future of the now-defunct scm-commits mailing list. A new forum thread was created to gather feedback from the community, especially packagers, on potential replacements. The primary options being considered are a public-inbox service, for which a proof-of-concept is already running, and leveraging the new Fedora Data Working Group (FDWG) platform for analysis and querying of commit data. Contributors are encouraged to join the discussion and share their use cases to help guide the final implementation. Other topics in the weekly and daily meetings included ticket triage and planning around upcoming events like Flock and a Red Hat Day of Learning, which may impact team availability.

Learn more about the Infrastructure team.

Release Engineering

The Release Engineering team's weekly meeting focused on the ongoing migration to the new Forgejo instance. A significant point of discussion was the migration of the fedora-scm-requests repository, which is blocked on updates to the fedpkg tool. This change will require a broad rollout to all package maintainers and is not expected to be completed before Flock. The team also explored opportunities for automation, identifying the release End-of-Life (EOL) process and mass branching as prime candidates for future work. Additionally, a scheduled task related to retiring packages with security issues was reviewed; it was determined that the underlying policy was never fully implemented, and the team decided to request its removal from the schedule.

Decisions

  • The scheduled task "Notifications for retirement of packages with security issues" will be requested for removal from the schedule, as the associated policy was never finalized or implemented.
  • Ticket #10160, a feature request for compose failure reporting, was closed as it is better tracked in the compose-tracker project.
  • Samyak will chair the next meeting on June 8th.

Learn more about the Release Engineering team.

Quality

This week, the main highlight was a community discussion around a new tool, "Dnf-ui is ready for testing", a modern GTK4 graphical frontend for DNF5. The developer is actively seeking feedback on installation, usability, and functionality, providing a great opportunity for contributors to get involved. The discussion has already yielded valuable feedback on performance, transaction handling, and testing on Fedora Silverblue via Distrobox.

Routine activities for the Quality team continued with announcements for Rawhide nightly compose testing and the upcoming weekly meeting. On the mailing lists, discussions included a user report about a missing grub2 menu after kernel updates on Rawhide and a question about the process for closing bugs for Fedora 42, which has now reached its end of life.

Learn more about the Quality team.

Design

The main discussion this week centered on the ongoing effort to create a prototype for a modernized Fedora Media Writer. The original proposer acknowledged the community's continued interest and praised a functional prototype that another contributor developed based on the initial designs. However, the initiative has been temporarily put on hold due to other commitments and the need to investigate the existing codebase to avoid a complete rewrite. The conversation also included ideas about a web-based writer, referencing the Chromebook Recovery Utility as an example, and suggested that contributors could help by exploring the codebases of other popular tools like Rufus and Etcher for inspiration.

Learn more about the Design team.

Docs

The Docs team held their bi-weekly meeting to discuss several housekeeping and process-related topics. A major organizational change was the standardization of issue labels across all Docs repositories and the decision to consolidate project boards at the organization level to improve cross-repository tracking. The team also discussed how to handle outdated content, including an unsupported system upgrade path in Quick Docs and the ongoing effort to retire old Docs pages on the Fedora Wiki. A debate on contribution workflows took place regarding whether to enforce creating pull requests from forks, with the discussion set to continue in the ticket. Help is needed from the community to apply the new standardized labels to issues in the Quick Docs repository.

On the forums, a new discussion began about "AEO" (AI Engine Optimization) and improving the discoverability of Fedora's documentation for newcomers and automated tools. The conversation highlighted the need for better-organized menus and strategic linking to guide new contributors. In an ongoing topic, the new "Fedora Discussion Forum (Self-)Moderation Guidelines and Rules" were officially published on the docs website, replacing the obsolete Ask Fedora SOPs, and have now been added to Weblate for translation. Finally, a discussion about the legality of including NVIDIA driver installation instructions continued, with a user pointing out that Quick Docs already links to RPM Fusion, questioning the consistency of the policy.

Decisions

  • The Docs team meeting on June 16, 2026, is canceled as it overlaps with the Flock contributor conference.
  • All project boards will be consolidated at the organization level instead of being created per-repository. Existing repository-level boards will be migrated.

Learn more about the Docs team.

A discussion was initiated this week regarding the licensing of timidity code, which is bundled within the SDL3_mixer package currently being prepared for Fedora. The timidity README offers a choice between "the GNU GPL, the GNU LGPL, or the Perl Artistic License" without specifying versions, creating ambiguity for packaging. The conversation explored how to interpret this statement, considering the code's history predating GPLv3. The consensus was to assume the author intended versions available at the time, leading to an acceptable license combination for Fedora: GPL-2.0-or-later OR LGPL-2.0-or-later OR Artistic-1.0-Perl.

Learn more about the Legal team.

COPR

This week, the COPR team announced and performed a planned maintenance outage on June 2nd to update the copr-backend server. The outage lasted approximately one hour, during which build queue processing was stopped. Existing DNF packages and repositories remained available throughout the maintenance period. The update was completed successfully.

Learn more about the COPR team.

EPEL

During the weekly EPEL meeting, the main topic was a proposal to delay the retirement of EPEL minor versions. Currently, a minor version is retired on the same day a new RHEL minor version is released, which can surprise maintainers. A two-week delay was proposed to allow in-flight updates to reach the stable repository, but the committee decided to table the discussion to gather more feedback. The results of the Spring 2026 EPEL Steering Committee elections were also announced, with Diego Herrera joining as a new member and Carl George, Troy Dawson, and Jonathan Wright returning. Kevin Fenzi was thanked for 19 years of service as he retires from the committee. On the development mailing list, a discussion about updating OpenColorIO for EPEL 9 highlighted the challenges and general reluctance to introduce updates with library version bumps in stable EPEL releases.

Decisions

  • The discussion regarding the EPEL minor version retirement timing was tabled until the next meeting to allow for more feedback in the issue tracker.
  • The Spring 2026 EPEL Steering Committee elections concluded, with Diego Herrera, Carl George, Troy Dawson, and Jonathan Wright elected to the four open seats.

Learn more about the EPEL team.

CentOS Hyperscale

The CentOS Hyperscale SIG held its weekly meeting to discuss kernel updates, transactional systems, and tooling. After delays due to security work, new kernel updates for CentOS Stream 9 and 10 are planned for the upcoming week. The group discussed the possibility of shipping an LTS kernel but concluded against it for now, citing the benefits of tracking the Fedora kernel and the viability of using the stock kernel with modules from the Kmods SIG. Significant progress has been made on a dnf5 plugin for transactional updates, thanks to community contributions for Kalpa Desktop, which brings the goal of a transactional Hyperscale variant closer. Contributors interested in having specific packages from Fedora tracked and updated can reach out to the SIG.

On the tooling front, the hs-relmon tool now features a new interactive review mode to simplify package promotion, which was used to release wprof 0.4. In community news, Paweł Zmarzłowski announced his resignation from the SIG. The team also noted that their activity report is overdue and they plan to finalize and publish it soon. Finally, a cleanup of stale packages was performed to reduce repository metadata size, and dnsmasq was backported to the el9 branch to address a security vulnerability.

Learn more about the CentOS Hyperscale team.

ELN

The ELN SIG held one meeting this week, providing status updates on ELNBuildSync (EBS) and bootc. The EBS service has undergone a significant reorganization: its source code has been migrated to a new GitHub repository, its deployment process has been simplified, and a pull request has been submitted to host it within the Fedora Infrastructure OpenShift cluster.

There was also a discussion on the progress of creating bootc images for ELN. This effort is a prerequisite for producing bootc images for CentOS Stream 11. The current work is focused on creating the necessary compose image, with further technical discussions planned for a follow-up meeting.

Learn more about the ELN team.

Atomic

The Atomic group's main focus this week was the migration to the new Fedora Forge atomic organization, discussed during their weekly meeting. The team decided to begin by migrating repositories that do not depend on Konflux, such as documentation and issue trackers. Repositories requiring Konflux for CI/builds will be moved once the integration is unblocked. The discussion also confirmed that the new organization will be the home for bootc-related projects, including work on ELN and a potential move of the CentOS Stream bootc repository. Contributor opportunities include helping with documentation fixes and issue triage after the initial migration, with a cleanup session planned for a future video call.

In community discussions, new solutions were shared for technical challenges on immutable systems. A user provided an updated guide for running the Guix package manager on Fedora Silverblue, and another user shared their method for integrating the KeePassXC and Firefox Flatpaks.

Decisions

  • Repositories that do not depend on Konflux (e.g., docs, issues) will be migrated first from GitLab to the new atomic organization on Fedora Forge.
  • Repositories dependent on Konflux will be held back until the Konflux integration is complete.
  • The bootc ELN work and the CentOS Stream bootc container repository are considered in scope for the new atomic organization.

Learn more about the Atomic team.

CoreOS

In this week's CoreOS meeting, the team discussed the upcoming Fedora 45 release cycle and progress on build system modernization. A key topic was the effort to switch CoreOS Assembler (COSA) to run on Fedora 44, with a plan to test the removal of a potentially unneeded dependency to move forward. Following successful work to repair the bootc pipeline, the team decided to re-enable Konflux for building the Rawhide stream. The group also planned the next steps for adopting bootc-image-builder, which includes moving partition layout definitions into the OCI container and staging the rollout across different release streams, starting with Rawhide.

Learn more about the CoreOS team.

AI & ML

During the weekly AI & ML meeting, the group discussed significant packaging updates, including a new version of ollama in rawhide and progress on updating onnxruntime, which is unblocked by a recent protobuf update. There is a call for community help to review several new packages, including the pi-coding-agent and emacs-agent-shell. In a related forum discussion on NPU support, it was noted that an xrt runtime package is now awaiting review. The meeting also addressed the "Fedora AI Developer Desktop" proposal, with a consensus that the SIG should serve as a collaborative space to shape such ideas before wider public announcement. This led to a re-commitment to create better "Getting Involved" documentation to improve the SIG's visibility and accessibility.

Decisions

Learn more about the AI & ML team.

Security

This week, the Security SIG held its weekly meeting, where the main topic of discussion was user privacy in default applications. Sparked by concerns around Firefox, the group considered creating a Fedora-wide policy to disable telemetry and AI features by default, ensuring users must explicitly opt-in. Given the sensitive nature of the topic, the consensus was to continue this conversation in person at the upcoming Flock conference.

A significant opportunity for contributor engagement was announced on the forums with the publication of a new static analysis report on Fedora 45 Critical Path Packages. The report identified 1,242 new findings since the last release, with an AI analysis flagging 14 important and 12 moderate-impact issues that may have security implications. Package maintainers and other contributors are encouraged to review these findings to help secure Fedora's core components.

Learn more about the Security team.

DotNET

The DotNET SIG welcomed a new potential contributor, Anugerah Tallenta Agung, who introduced themselves on the mailing list. As a university student and long-time Fedora user, they expressed interest in contributing to the .NET and gaming experience on Fedora. They are seeking guidance on how to get involved, specifically mentioning sharing their experiences and potentially helping with packaging. This provides an excellent opportunity for the SIG to engage with and mentor a new member. No technical discussions or decisions took place this week.

Learn more about the DotNET team.

Go

This week in the Go SIG, the weekly meeting was lightly attended, leading to the postponement of discussions on open tracker issues. The primary point of information was the announcement of the public Fedora 45 Change proposal to introduce Golang 1.27. This proposal outlines the standard update of the Go toolchain for the next Fedora release.

A discussion on the mailing list resolved a packaging issue where spectool failed to download a source tarball. The problem was identified as a mismatch between the %{gosource} macro's generated URL and the upstream git tag, which included a "v" prefix. The solution was to remove a custom %global tag definition from the spec file, allowing the macro to use its default, correct behavior.

Learn more about the Go team.

Perl

The main point of discussion this week was a call for new maintainers for a large number of orphaned Perl packages. Due to the inactivity of a previous maintainer, there is a risk of these packages being retired. This presents a significant opportunity for contributors to step up and take ownership of packages they are interested in. Other activity consisted of routine package maintenance, including several version updates and a bug fix.

Decisions

Learn more about the Perl team.

Python

The Python team announced and executed the mass rebuild of packages for Python 3.15 in Fedora 45 (Rawhide). The process was conducted in a dedicated side tag to minimize disruption, starting on June 3rd. Maintainers were advised to pause their builds in the main Rawhide branch during this period. The side tag was successfully merged on June 6th, completing the transition.

With Python 3.15 now the default in Rawhide, the focus shifts to resolving any remaining build failures. Maintainers are encouraged to fix their packages, with guidance provided for handling common issues like test failures or broken dependencies. This is a key opportunity for contributors to help ensure their packages are compatible with the latest Python version.

Learn more about the Python team.

Other Discussions

  • In a discussion about a request to package the ouch compression utility, community members explained that Fedora packaging is volunteer-driven. The requester highlighted the tool's memory safety as a key advantage over existing tools like unar and 7z. While there was interest in the tool, no one committed to packaging it.
  • A user initiated a discussion about the use of AI in Linux kernel development, raising concerns about code quality, plagiarism, and the increased rate of change. The conversation touched on Fedora's own kernel validation challenges and whether an LTS kernel would be beneficial, with some contributors noting that kernel developers often consider LTS kernels to be of lower quality than the stable series Fedora already ships. It was also suggested that the main kernel mailing list (LKML) is no longer the appropriate venue for such discussions, which should instead be directed to subsystem-specific lists.
  • A proposal was made to standardize the inclusion of upstream repository URLs in Fedora package metadata to improve automation, security analysis, and contributor onboarding. The discussion evaluated using the existing URL or VCS RPM tags. The VCS tag was favored as a more suitable candidate, though concerns were raised about the significant effort required for a mass update and the need for a clear benefit to package maintainers.
  • Samyak Jain from Fedora Release Engineering announced that the fedora-comps repository has been migrated from Pagure to Fedora Forge. The repository, which maintains the XML files for installer groups and dnf metadata, is now located at https://forge.fedoraproject.org/releng/fedora-comps.
  • Frantisek Zatloukal provided an update on the rebuilds for the ICU 78.3 update, stating that they would restart early the following week after other conflicting rebuilds, such as the Python 3.15 bump, were completed.
  • Other topics discussed this week include a list of new packages added to Fedora, a query on how to easily add another user's fork as a remote in fedpkg, a clarification that the RPM 6.1 Change Proposal does not include a switch to the v6 package format, a report on static analysis findings in Critical Path packages which sparked a debate on responsible disclosure, and a reminder about the sunset of pagure.io clarifying its scope.

Orphaning packages

Package Updates

New Contributor Introductions

  • Pragyan Poudyal, who works at Red Hat, introduced himself and expressed his interest in contributing to Fedora as a package maintainer.
  • Raghavan Kanagaraj introduced himself to maintain the intel-cmt-cat package. It was clarified that as a previously inactive packager, he needed to follow the process for returning contributors to be re-added to the packager group.
  • Carl Byington, a former maintainer of libpst, requested sponsorship to package passwordsafe. Dominik 'Rathann' Mierzejewski sponsored him, welcoming him back into the packager group.

Jona Azizaj – Why Mentorship at Flock Changes Everything!

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

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Jona Azizaj’s first Flock was ten years ago in Kraków, Poland. What struck her most was how approachable everyone was. In a community full of experienced contributors, people made space for new voices, listened to her experiences building the local community in Albania, and made her feel like her perspective genuinely mattered. Those small moments, she says, are what made her feel like she truly belonged.

A decade on, Jona sees Flock as one of the most powerful tools for growing the next generation of Fedora contributors. Online mentorship happens asynchronously and at a distance. Flock, however, creates something different: the chance to sit down with someone, share experiences, and build real trust. Flock is where contributors grow more confident, find their place, and realise that open source is about far more than technical work.

For Flock 2026, Jona and the Fedora Mentor Summit team are bringing three initiatives, now in their 5th edition.

A successful Flock, for Jona, is one where people leave feeling more confident than when they arrived. It is an event where the connections built there carry on long after the event ends.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Accessing serial consoles on SBC’s

Posted by Dennis Gilmore on 2026-06-07 20:42:39 UTC

I have a bunch of different ARM SBCs, some Raspberry Pis, some Rockchip based, and some others. Some of them I have in 1U rack mount cases. Some in cases that I have 3d printed. They have all had a common issue. When something goes wrong, I need to unplug them, move them to my desk, and connect them to my desktop via a USB to tty adaptor. Aside from being inconvenient, it also meant I had to be home to debug what was happening.

I figured there had to be a better way. In the end, I used Claude to help me write a solution. What I came up with is a project to make an ESP32 Web Terminal. Using an ESP32 wired to the UART on the SBCs, I can securely access the serial console of my devices. I have used a couple of different ESP32 devices, from a USD$3 ESP32 C3 Mini to a USD$8 XIAO ESP32S3. all of which work well. For the Raspberry Pis, I purchased some premade JST SH1.0 mm 3 Pin Wire connector cables to plug into the uart port, and for other devices, I made some custom cables with 2.54 mm Dupont crimp pin connectors.

I have most of my SBC’s powered by PoE. In the pictured example, I soldered some headers onto the PCB for the PoE hat to use to provide a 5V power source to the ESP32, and it all runs self-contained in the rack-mount unit. I do want to work on making the connections a little neater and the housing better. But for now, this is functional. While the software on the ESP allows resetting the SBC and controlling the power, I do not currently have that wired up.

As for provisioning the ESPs, I run FreeIPA at home for authentication, and I have dogtag set up as a CA. When I have wired up and flashed a new board, it initially runs as an access point I connect to in order to set up my home network. Once it is connected to my network, I run an Ansible playbook to create and upload SSL certificates signed by my CA and change the admin password. That way, I can connect without any SSL warnings and use a known non-default password to log in. So far, I am quite happy with how they have performed. I still have some things I want to make better, and I also want to finish testing a setup where I connect to an SBC that exposes its serial port over USB. In theory, it should work with ESP32S3, I just need to test.

While it has added quite a few more devices to my network, it is useful to be able to access and debug what is happening without having to move devices and plug them into another computer. I have considered options for externally powering the ESPs and the best ways to connect the ESPs to the SBCs. I would like to at least be more robust with a 3d printed enclosure for the ESP. Each unit has cost me between USD$5 and USD$12, and each has acceptable performance. I have intentionally stuck to using small ESP’s, though it would work well with bigger devices also. Powering each through a shared power source would require additional circuitry to isolate them and prevent voltage leaks.

misc fedora bits first week of june 2026

Posted by Kevin Fenzi on 2026-06-06 17:56:41 UTC
Scrye into the crystal ball

Another busy week for me. Lots of little things all over the place.

mass update/reboots

We got everything updated and rebooted and cleaned up any messes from that (at least as far as I know). We did firmware updates on servers this time, and those always cause things to take much longer. Instead of a 'quick' 5m reboot of a server, it's more 20-25m to apply all the firmware updates and reboot a bunch of times. Ah well, it's good to be up to date.

We did have one arm server fail to come up after reboot. ;( It has a memory error, so we are having datacenter folks reseat all the memory (this happened once before and that cleared it up).

Some old long running tickets

I was able to try and move some old long running tickets over the finish line this week:

  • systemd-boot signing. This is all setup, but needs to be tweaked in the package and tested. Note that this is a self signed cert, but it will still hopefully help folks using systemd-boot.

  • Looked over a bunch of work from Stephen Gallagher to fix some dist-git repos that have commits that break git fsck. I hope I can finish this up early next week.

And a few new things

  • Got the drm-panic 'application' deployed. (I just deployed, the change owner did all the heavy lifting).

  • Setup a pagure-stg-ro01 machine to test a 'readonly' pagure instance.

  • Got koji upgraded to 1.36.0.

  • Got all koji builders, hubs and kojipkgs moved to fedora 44

  • Moved all our proxies to fedora 44

  • Moved all our compose hosts to fedora 44

  • Fixed some openshift apps that were still pulling from docker hub (and getting rate limited). I even moved greenwave to using a hummingbird memcached container. Works great!

flock

Flock is coming up fast now. I will be traveling to it starting next thursday. So expect me to be largely offline thursday and friday, and then only sporadically online while I am at flock.

Really looking forward to meeting up with folks and getting that good flock infusion of energy.

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

Akashdeep Dhar – Contributing to Fedora Infrastructure and the Power of Flock!

Posted by Fedora Magazine on 2026-06-05 15:07:06 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the Commit History campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Akashdeep’s history with Flock goes back around five years, and his perspective on it has evolved significantly. During his time on the Fedora Council, he participated in the grueling process of reviewing over 150 talk proposals in a single cycle. This task was made harder by the fact that acceptance is often tied to sponsored travel meaning funding rejection can mean a contributor simply can’t attend at all.

But beyond the sessions and schedules, Akashdeep is emphatic about what Flock is really for. Roughly 75% of the experience is about human connection; understanding the person behind the screen, building friendships, and embodying the “friends foundation” philosophy at the heart of Fedora. Technical work is the bonus, not the point.

Nowhere is this clearer than in the story of the Fedora Badges revamp. Interest in rebuilding the platform which, despite its 2003-era interface, plays a vital role in motivating new contributors, dates back to 2019. But it was Flock’s hallway conversations and dedicated workshops that finally built the consensus needed to move the project forward.

Akashdeep also wants people to know that contributing to Fedora infrastructure is more accessible than it looks. You don’t need to be on a specific team or work for a particular company. Just join a chat, introduce yourself, and find your corner. As one contributor discovered, starting with documentation led to a whole journey into diversity and inclusion work. Community bonding is what keeps people, and the technical work is the reward.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Community Update – Week 23 2026

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

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

Week: 01 – 05 June 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

RISC-V

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

  • F44: core rebuild is completed. Image generation and repo-creation needs some work. ‘omni’ kernels are being built and  ‘kiwi descriptions’ (required for image generation) needs some RISC-V specific patching.  We’re short on resources , so this delay is expected.
  • Conferences preparation:
    • Prep for RISC-V Summit, meetings with hardware vendors, upstream meetings, and RISE 
    • Prepare updated material for Flock RISC-V update
  • [Hardware] We have one of the newest RVA23 boards (SpacemiT K3) in Fedora RISC-V Koji.
    • Thanks to Jason Montleon.  It’s his personal hardware.   A CLE-sponsored Fedora K3 builder is on its way to him too, it’ll be wired into RISC-V Koji
  • [Hardware] Discussed with Jefro about potentially working with Scaleway to get some cloud builders via the RISE initiative.  To be discussed at the RISC EU Summit.

AI

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

  • t0xic0d3r helped draft the Fedora AI Developer Desktop Community Objective logic model [Draft]

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.

  • Discussed the coordination process for the private issues
  • Enabled the members team to create repositories [Access]

EPEL

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

  • Prepared EPEL 10.1 for move to archives
  • Package maintenance across multiple Fedora and EPEL packages
  • Quality work via bug reports and bodhi karma
  • Starting to onboard Pedro

UX

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

  • Finalizing Flock materials
    • Everything for print sent to organisers
    • Digital assets is now the focus

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 23 2026 appeared first on Fedora Community Blog.

🎲 PHP version 8.4.22RC1 and 8.5.7RC1

Posted by Remi Collet on 2026-05-22 05:09: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.7RC1 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.22RC1 are available

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

ℹ️ The packages are available for x86_64 and aarch64.

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

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

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

Update of system version 8.4:

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

ℹ️ Notice:

  • version 8.5.4RC1 is in Fedora rawhide for QA
  • EL-10 packages are built using RHEL-10.1 and EPEL-10.1
  • EL-9 packages are built using RHEL-9.7 and EPEL-9
  • EL-8 packages are built using RHEL-8.10 and EPEL-8
  • oci8 extension uses the RPM of the Oracle Instant Client version 23.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)

 

New badge: Flock 2026 Attendee !

Posted by Fedora Badges on 2026-06-05 00:22:08 UTC
Flock 2026 AttendeeYou attended Flock 2026, the Fedora contributor conference, in Prague, Czech Republic

Work-Life Balance 🏖️ with Sandogasa 👒 Hat-Track

Posted by Michel Lind on 2026-06-05 00:00:00 UTC

Caveat lector

This post discusses tools reluctantly written with AI assistance. If you don’t entertain using them under any circumstance, and think even reading about them legally compromise your ability to reimplement them yourselves, stop reading now

Happy Friday! Of course it’s not Friday anymore in Asia, and if I finish this post in time, it’s still the work day in the Western Hemisphere.

When you work in a large distributed project, it’s not dissimilar to working in a large multinational company - there are too many people to know everyone (or at least not at once!) and you might not know where someone is and if you’re pinging them in the middle of the night.

USTR🇺🇸 × 🇧🇷PIX

Posted by Avi Alkalay on 2026-06-04 23:59:00 UTC

Na novela USTR versus o nosso PIX do Brasil, vejo muito mais a mão do lobby da Apple e Meta do que Visa e Mastercard.

As bandeiras de cartão de crédito se beneficiaram muitíssimo da enorme democratização bancária que aconteceu no Brasil nos últimos anos. Não creio que são essas as empresas americanas que fizeram lobby para as sanções do USTR.

Já a Apple não permite a integração do Pix em seu Apple Pay se a transação (banco do usuário pagador) não lhe pagar um troco. Coisa que é impossível com o Pix. Apple Pay com Pix permitiria eliminar o QR com a app do banco, e o pagamento aconteceria por mera aproximação. Esse fator (ou a falta dele) faz com que usuários de iPhone continuem preferindo pagar com crédito e débito porque é mais rápido, natural e conveniente. Mas se o comerciante oferecer desconto se pagar com Pix, a história muda.

A Meta, sendo dona do aplicativo mais peer-to-peer do mundo — o WhatsApp —, é natural que integre pagamentos ali mesmo e ganhe um troco com essa intermediação. Só que o Pix é mais peer-to-peer ainda, e mais democrático por ser direto, sem intermediários (o Banco Central não é um intermediário, só um integrador de dados) e gratuito para o pagador e para o credor/comerciante. Isso faz com que o WhatsApp Payments seja um serviço insustentável e irrelevante no Brasil.

Lamento muito para eles, parabéns para nós brasileiros.

Também no meu LinkedIn, Facebook e Instagram.

Friday Links 26-18

Posted by Christof Damian on 2026-06-04 22:00:00 UTC
A large LEGO minifigure standing next to a green LEGO bicycle, in front of a LEGO mosaic of a city street scene

Again a few good podcasts, I especially liked the one about The Pre-Training Wall and the Mythical Man Month.

Quote of the Week
Rule of thumb: When the debate is no longer productive, it’s time to make a decision.
Managing Humans
Michael Lopp

Leadership

The Ask - what is this meeting actually about?

Updates and reboots on Fedora infrastructure

Posted by Fedora Infrastructure Status on 2026-06-04 21:00:00 UTC

Fedora Infrastructure team will be applying updates to servers and rebooting them.

Many services will be affected, most should only be down for a short time as their particular resources are rebooted HOWEVER some may be down for a non-trivial amount of time due to RHEL-9 to RHEL-10 upgrades.

In …

The status of OpenSSL 4.0 support in syslog-ng

Posted by Peter Czanik on 2026-06-04 12:01:40 UTC

OpenSSL 4.0 was released just over a month ago. So, how is its support progressing in syslog-ng? Well, Git master already supports it, and the patch is easy to backport to earlier releases. At the same time, version 4.12 will support OpenSSL 4.0 out of the box.

A month ago, someone from Gentoo Linux reached out to the syslog-ng team about OpenSSL 4.0 support. I asked the community about their expectations, knowing that version 4.0 is not an LTS version. However, I quickly learned that all major distros were preparing to use it in their rolling development versions. A few days later, we also received hints on how to add support for it in syslog-ng. And thus, a PR was born, which is now merged into syslog-ng git master.

What does this mean for you?

  • If you need OpenSSL 4.0 support RIGHT NOW using a RELEASED syslog-ng version, then use syslog-ng 4.11 and the related pull request from https://github.com/syslog-ng/syslog-ng/pull/5688
  • Use the latest syslog-ng git snapshot, as the above PR is already merged.
  • Wait a few more weeks, as syslog-ng 4.12 will be released soon with OpenSSL 4.0 support.

syslog-ng logo

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

Aleksandra Fedorova on Community, Flock, and the Human Side of Fedora

Posted by Fedora Magazine on 2026-06-04 08:00:00 UTC

Flock to Fedora is more than a conference — it’s where the Fedora community comes alive. As part of the #In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Aleksandra Fedorova’s journey into Fedora started with a sticker. At LinuxTag in Berlin, her first properly organised Linux community event she approached the Fedora booth simply wanting a sticker. What happened next changed everything. The people behind the booth invited her to join them on their side of the table. That single gesture dismantled the wall between user and contributor, and she never looked back.

For Aleksandra, Flock isn’t the place for deep technical work. Instead, it’s where the Fedora Council reads the room, sensing priorities, spotting coordination gaps, and picking up on tensions before they become real problems. She’s also refreshingly honest about Flock’s limitations: the costs of attending mean it’s not always a fully representative cross-section of the community, and understanding the broader Fedora ecosystem requires deliberate effort beyond the event itself.

But what Flock offers that nothing else can? The human element. No mailing list or Matrix channel lets you simply walk up to someone and start a conversation without a formal introduction. At Flock, the hallway is as valuable as the schedule. For Flock 2026, Aleksandra hopes the event helps ease current tensions; the reminder that everyone is working toward the same goal, even when they disagree on how to get there, is something only being in the same room together can provide.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

Fedora 43 Upgrade revealed 20 years old Outlook Security Bug

Posted by Fedora Magazine on 2026-06-03 19:19:57 UTC

Yes, the Fedora 43 upgrade brought an interesting revelation for all Outlook users—one that Microsoft is unlikely to be thrilled about. Outlook was not encrypting email connections, even though SSL/TLS was clearly enabled in the account settings. It looks like, that bug dates back to at least Outlook 2007, which is the oldest Outlook version I was informed about.

Let us start with the beginning

Every six months, Fedora Servers require and upgrade to the next release version, as you all know 😉 This May we had to upgrade from 42 to 43 and in this upgrade, Dovecot POP/IMAP server switched to version 2.4.3. Dovecot did us all an unexpected favor, because it required a full rewrite of the used service config, because it’s not backwards compatible. This change introduced a new paradigm: PLAIN TEXT passwords are no longer allowed over unencrypted connections.

This is a major break with the oldest RFCs (i.e. RFC 1081) regarding POP3 behavior, but a good one IMHO. No one should still use unencrypted connections to any form of service on the internet when we have easy to use encryption protocols like STARTTLS (STLS) at hand in any major client.

The Day After

After the upgrade, “we” (admins & customers) did not even know about the now broken auth-mechanism. This came a day later when customers started to call the support line about rquesters popping up for them to enter their passwords again. This is a normal behavior if auth fails… and it failed hard 😉

As all admins know, such upgrades will result in higher amounts of support calls. To my surprise it was all Outlook clients that called. The oldest version so far was Outlook 2007. We even had an old MACOS Outlook :-). They all had in common, that the mailbox prefs had “SSL/TLS” enabled, but used Port 110, which is the old cleartext port for POP3, where port 995 is the correct SSL port. A normal mailclient would change the port number to 995 as soon as you enable SSL/TLS encryption. This is because you can’t “speak” SSL on a non-ssl port, except if you choose STARTTLS. This starts as a cleartext connection, but upgrades itself to ssl-encrypted later.

“Look, there is something out there!”

Outlook did the worst move you can take as a security enhanced app. It silently ignored the choosen SSL option and used the unencrypted port 110 without any notice to the user. After our server upgrade, the following message popped up:

German version of the error message

“-ERR [AUTH] Cleartext authentication disallowed on non -secure ( SSL/TLS ) connections.“ popped up if you tried to open your inbox. The server logs revealed it clearly: the user used a non-secure connection and got this message correctly. This never got noticed since the EU GDRP only states, that corporations and organisations need to protect their data via a transport encryption like TLS. Normal persons don’t need to do so.

Even some of the notable folks of Fedora did not use encryption, which I personally advise to change immediately. Having this in mind, who are we to judge if you encrypt your connection or not? 😉

Really folks: use TLS encryption for your mailboxes!

You can easily check if TLS encryption is working. Send yourself an mail and open the mail headers, you will find lines like this:

Received: from bastion01.fedoraproject.org ([38.145.32.11] helo=bastion.fedoraproject.org)
by s113.resellerdesktop.de with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384
(Exim 4.99.2)
(envelope-from <updates@fedoraproject.org>)
…
Any good MTA ( Exim, Postfix, etc. ) will note if the connection was encrypted or not.

If you don’t see an encryption notice, you can use this command: 

tcpdump -A -n -n port 110 or port 143

in a root terminal and see if the unencrypted port is used for transport. If so, if it’s cleartext or if it’s using STLS.

So… THANKS Fedora 43 and Dovecot 2.4 … you revealed a 20 year old security bug in Outlook \o/

Disclaimer: It is possible that MS patched the Outlook UI in the past in a way that only old accounts are affected by this major fail. As Fedora users we had no Outlook available to test this 😉

Source: https://marius.bloggt-in-braunschweig.de/2026/06/03/outlook-hat-emailverbindung-nicht-verschluesselt/

Mindshare Election For FL44: Interview With Akashdeep Dhar

Posted by Akashdeep Dhar on 2026-06-03 18:30:44 UTC
Mindshare Election For FL44: Interview With Akashdeep Dhar

This is a part of the Fedora Linux 44 Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Akashdeep Dhar

What is your background in Fedora? What have you worked on and what are you doing now?

Since the past year, I have been actively contributing to the event planning [1] [2] and proposal curation in the Mindshare Committee. Representing our vested interests in the Fedora Council, I have paved the way for improvements in the regional event support (i.e., event owners and regional inventory), digital ambassadorship (i.e., swagpack designs and social media) and recognition service (i.e., Community Metrics and Fedora Badges).

Besides championing our community presence in underrepresented regions (e.g., in DevConf.IN 2026 and FOSSAsia 2026 in APAC), I have continued staying at the forefront of the Fedora Forge community initiative, working as an infrastructure architect for Fedora Infrastructure applications, organizing Fedora Mentor Summit during Flock events and mentoring budding contributors formally/informally in the community.

Please elaborate on the personal "Why" which motivates you to be a candidate for Mindshare

Technology might be why I joined the Fedora Project, but I stayed because of the people who made me feel at home. Progressing in various aspects of our planned functions over the past years has taught me one crucial thing – contributors are actually retained when they feel noticed, supported and trusted with meaningful work. The Mindshare Committee is where that happens, and I want to keep building what we started.

Furthermore, as the committee’s representative to the Fedora Council, I have seen firsthand how decisions at the governance level shape the contributor experience on the grassroots level. The update during the Fedora Council Strategy Summit 2026 gave us an opportunity to serve event organizers, community ambassadors and voluntary contributors better, all while using these outcomes to enhance the community health.

How would you improve MIndshare Committee visibility and awareness in the Fedora community?

Simple. We need to show up where the community is. A community booth in one event, some interactive workshops in another – to begin with in regional event support to ultimately show people that we indeed care. While making sure that our infographic swagpacks are updated on a regular basis in digital ambassadorship, we actually ensure that we are providing people with reasons to come back to us when the time is right.

With the upcoming collectible rarity feature in Fedora Badges and tangible contributor recognition awards (both as a part of Fedora Mentor Summit event and separately), we nudge people to more opportune contribution avenues while avoiding burnouts in longtime contributors. This could further be extended to our Fedora Linux Release Parties too, as ultimately, most of our community members started off as its users.

What part of Fedora do you think needs the most attention from the Mindshare Committee during your term?

Contributor Recognition. With over half a decade of experience in this space, the “What now?” problem (after the first contribution) has only become worse with the advent of AI Assisted Contribution Activities. Newcomers struggle to realize the value proposition of the community connection that Fedora Project could provide, and hence, it has become the need of the hour to incentivize contributions using rewarding activities.

But apart from that, we also need to do better at further improving our local presence in underrepresented regions. In this past term, my pilot experiment on APAC events worked wonders, and it showed us all the community power we can tap into by just being there. With reusable swagpacks, localized printing, active conversations and documented accounts, this limited experiment can scale well across various parts of the globe.

This article was originally posted on Fedora Commblog on 29 May 2026.

Council Election For FL44: Interview With Akashdeep Dhar

Posted by Akashdeep Dhar on 2026-06-03 18:30:40 UTC
Council Election For FL44: Interview With Akashdeep Dhar

This is a part of the Fedora Linux 44 Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts Monday, June 1st and closes promptly at 23:59:59 UTC on Friday, June 12th 2026.

Interview with Akashdeep Dhar

What kind of experience do you have which might be relevant to the role? E.g. governance, leadership, etc.

While I could not make it to the Fedora Council through elections in the previous term, I was chosen as a Mindshare Representative from the second half of the term. Besides bringing the interests of the Mindshare Committee to the Fedora Council Strategy Summit 2025, I also worked on further progressing the Fedora Forge Community Initiative with my work on the private issues and Pagure Migrator. Staying true to my volunteer first community agenda, I also worked on the documentation for the Fedora Project Contribution Model to encourage empathetic interactions and managing expectations in our mostly volunteer driven community.

Following the elector concerns from the previous term, I explicitly reinforced just how important it was for us to leverage objective community health metrics over arbitrary conditions that I voiced during the foundational drafting of the Fedora Verified proposal. With my inclination towards process sustainability, I have often voted for deferring decisions until we have accounted for most (if not all) feedback. I have had a hands-on approach towards major proposals like Fedora Forge, Image Mode, FedoraCVE trademark and Fedora Verified, by spending roughly around ten hours per week simply reading through the Fedora Discussion threads.

Besides my direct involvement in the Fedora Council, I am also working as an infrastructure architect, working on various projects in the Fedora Infrastructure and leading the Fedora Badges Revamp Project while mentoring an Outreachy intern. Being elected into the Mindshare Committee has also allowed for me to lead the logistics of various Fedora Project in-person representations at APAC events like DevConf.IN 2026 and FOSSAsia 2026, all while curating and guiding Fedora Project community events across the world. In my past life (or roughly five years back in human years), I also led the Fedora Websites and Apps community initiative.

What do you see as potential opportunities and risks for the Fedora Project?

One of the first things that comes to my mind about risks for our community is decision transparency. The discussions [1] [2] around the AI Developer Desktop Proposal were a valuable learning experience as they showed how much community members care about understanding why we vote the way we do, not just what we voted for. I see an opportunity here for elected members to share their reasoning with their votes on a given proposal, so others can follow the thought process. After all, I would want to vote for someone who engages with what the community has to say and is willing to show their work, even through various disagreements.

To dive even deeper, we also risk alienating the community members by deciding on a certain proposal before it is theoretically ready to be discussed. While a stopgap opportunity here might be ratifying a proposal readiness guidelines document that the members could refer to, in my honest opinion, being active around the Fedora Project community platforms just ends up helping a lot more. If this requires us to spend more hours around the desk, have more frequently organized synchronous meetings, include more electable Fedora Council seats or set regular Fedora Council social hours – then it is something that we need to account for.

Beyond transparency, I also want to champion process sustainability in our established processes. The end of an elected member’s term should not mean that their ongoing work disappears – it should be (or made) possible for incoming candidates or continuing members to carry forward and iterate upon that work. Similarly, we can reduce the risk of potential burnouts among elected members by effectively delegating to the enthusiastic contributors that our community is never short of. Good governance should outlast any single term, and I want to actively work towards building that continuity through documenting better handoff practices.

What brought you to the Fedora Project?

Video games. Back in early 2020 when we were isolated at our homes due to COVID-19 pandemic, all I had was a weak laptop and a Fedora Workstation setup to keep me from boredom. One of my first contributions had been to the Quick Docs. When I thought I was done with my contributing activities, friends like Ankur Sinha, Alberto Sanchez, Justin Wheeler, Marie Nordin, Nasir Hussain, Vipul Siddharth etc. just made me keep coming back for more. Then getting inspired from all the amazing stuff they got up to back in the day made me want to see if I could be of some help – and a huge reason why I am keeping myself busy even today is just that.

This article was originally posted on Fedora Commblog on 29 May 2026.

Valentin Rothberg on Building the Future of Fedora Containers

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

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the In the CommitHistory campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Valentin Rothberg’s journey into container-native Linux didn’t start with a grand plan – it started with the work. After over 8 years at Red Hat contributing to projects like Podman and bootable containers, Fedora felt like the natural home for his next chapter. In Summer 2025 he began working on Project Hummingbird, which builds directly on top of Fedora. Flock 2026 is where he wants to share what he’s learned.

His first Flock was in Budapest in 2019 – and he remembers it vividly. Stepping in at the last minute for Dan Walsh, he ended up presenting for over three hours straight on container technologies. Not a bad way to make an entrance.

For Valentin, Flock’s value isn’t primarily technical. Technical decisions tend to be made comparatively fast once a group of people rally around a cause. What matters is finding that cause together, and in-person time is what makes that possible. The implementation details, he says, are just details.

He’s also refreshingly honest about where Fedora stands in the container ecosystem. Despite being the birthplace of tools like Podman, Fedora containers don’t see wide use outside the community. Valentin has ideas about why, and how to change that. He’s coming to Flock not to present answers, but to hear other perspectives and build something together.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel. We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

From Antarctica to FPL : Jef Spaleta on Leading Fedora Into Its Next Chapter

Posted by Fedora Magazine on 2026-06-02 22:40:26 UTC

Flock to Fedora is more than a conference – it’s where the Fedora community comes alive. As part of the “CommitHistory” campaign, we sat down with confirmed Flock 2026 speakers to hear their stories: what brought them to Fedora, what Flock means to them personally, and what they’re hoping for in Prague this June. This is one of those conversations.

Jef Spaleta came back to Fedora at exactly the right moment. After years away, working across software startups and following his spouse’s move back to the east coast, the timing aligned perfectly with the previous project leader stepping down. With a sharpened skill set and fresh perspective, Jef felt ready to lead.

But leading Fedora in 2026 isn’t just about keeping the lights on. Jef sees the project at a critical crossroads. There is a generational transition where original founders are stepping away and institutional knowledge risks disappearing with them. His focus? Mentoring the next wave of contributors to keep Fedora sustainable for the next five to ten years.

On the state of the project, Jef is honest: Fedora continues to ship high-quality releases on schedule, a streak held for five or six years. But stability isn’t enough. He is developing a new Fedora innovation lifecycle, a dedicated space for experimental work where things can be tried, broken, and learned from without disrupting the mature processes the project depends on.

For Jef, Flock’s value is simple but profound. Digital tools work well when everyone agrees, but they fall apart when things get hard. Flock is where relationship repair happens, where tone and intent can finally be communicated in ways text never can. Looking ahead to Flock 2026, he is focusing on two priorities. First, migrating Forge infrastructure to meet the expectations of the next generation of developers, and second, shaping Fedora’s approach to AI-assisted development before the conversation shapes itself.

Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel. We hope to see you there!

Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.

#Commit History: Tell Us About Your First Commit

Posted by Fedora Magazine on 2026-06-02 14:11:26 UTC

Maybe it was a one-line typo fix in the docs. Perhaps it was a package you’d been maintaining in secret for months before you finally submitted it. Maybe it was completely terrifying, or maybe it just felt like the most natural thing in the world. Whatever it was we want to hear about it.

Ahead of Flock to Fedora 2026 (June 14–16, Prague), We the Fedora CommOps team are launching #Commit History: a community campaign to collect the origin stories of Fedora contributors – the moments that brought people into this project and kept them here.

The best stories will be featured in a Fedora Magazine article published before Flock 2026, celebrating the people who make this project what it is.

Here are the questions used to get started-

  • What was your first contribution to Fedora – and what made you take that first step?
  • What did it feel like? What went wrong (or right)?
  • Looking back, what did that moment mean for your open source journey?

There are no wrong answers. First commits come in all shapes code, documentation, translations, design, bug reports, community work. If you’ve ever contributed to Fedora, your story belongs here.

How to share: Drop your story in the comments below, or share it on Mastodon with the hashtag #Commit History.

Whether you’ve been contributing for a decade or made your first commit last week – we want to hear from you.

Planned Outage - Fedora Copr - copr-backend upgrade

Posted by Fedora Infrastructure Status on 2026-06-02 09:00:00 UTC

Fedora Copr build queue processing will be stopped during this outage while copr-backend is upgraded to new version.

DNF packages and repositories will remain available.

© 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