Fedora People

Michael Catanzaro: Please Do Not Ban AI-Assisted Issue Reports

2026-06-08T21:30:42+00:00

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

Rajeesh KV: RIT Unny open source font

2026-06-08T11:14:05+00:00

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.

Aurélien Bompard: From June 01 to June 07

2026-06-08T08:22:00+00:00

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.

Legal

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

A new repository, editorial-guide-ramalama, will be created under the ai-ml forge namespace for an Outreachy internship project.
A decision on the Skills Library refactor pull request will be made on or before the next meeting on June 18th.

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

The perl-WWW-RobotRules package was updated to version 6.03.
The perl-Net-CalDAVTalk package was updated to version 0.17.
The perl-Net-CardDAVTalk package was updated to version 0.11.
A fix for procps-ng usage was merged for perl-IO-Socket-SSL.

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

Neal Gompa has orphaned dnfdaemon, which is based on dnf4, as all its consumers have migrated to dnf5daemon-server.
Ben Beasley announced the orphaning of snakemake and a large number of its related Python packages. The decision was made to free up time, citing the high total maintenance effort and long-term concerns about bundled pre-compiled assets in the main package.
Neal Gompa has orphaned the libyui stack of packages, including libyui-gtk, libyui-mga, and others, as they are no longer used by any packages in Fedora.
Julian Sikorski has orphaned the qmc2 package because its upstream project is no longer maintained.
The weekly automated report listed a large number of orphaned packages seeking new maintainers. A discussion followed about whether SIGs should be automatically removed as co-maintainers from orphaned packages, with differing opinions on the matter.

Package Updates

Jerry James announced an upcoming update to the gap package to version 4.16.0, which will include a SONAME bump for libgap. This change is not expected to impact any other Fedora packages.
Michael J Gruber announced that new versions of girara, zathura, and mupdf would be updated, involving SONAME bumps. The updates, which include important bug fixes, will be built in side-tags for both Rawhide and stable releases under FESCo exceptions.
Artur Frenszek-Iwicki announced an update to kdsingleapplication in Rawhide, which included a SONAME bump. All affected dependent packages were subsequently rebuilt in a side tag.
The Protobuf update has landed in Rawhide. A discussion revealed that the Java bindings had been disabled; work was started to re-enable them by packaging the necessary dependencies. Several packages that failed to build with the new version were identified, and pull requests to use the compatibility package are still pending for others.

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.

Fedora Magazine: Jona Azizaj – Why Mentorship at Flock Changes Everything!

2026-06-08T08:00:00+00:00

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.

The Fedora Contributor Recognition Program celebrating the quiet, meaningful work that often goes unnoticed.
A Lunch and Learn session creating a relaxed space for people to connect beyond their usual circles.
A sticker matching icebreaker providing first-time attendees an easy, low-pressure way to start conversations.

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.

Dennis Gilmore: Accessing serial consoles on SBC’s

2026-06-07T20:42:39+00:00

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.

Kevin Fenzi: misc fedora bits first week of june 2026

2026-06-06T17:56:41+00:00

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

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

2026-06-05T15:07:06+00:00

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.

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

Fedora Community Blog: Community Update – Week 23 2026

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

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

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

Devise the flagging of inactive badges as a boolean column [Triaged]
feat: add legacy boolean column to badges [Approved]
Add unit tests for _serve_frontend path traversal safety [Suggested]
Add (or modify) methods to filter/modify the legacy status [Triaged] [Followup]
Moved fedora-badges to badges-assets [Repository] [Followup]
Mark the Pagure’s Fedora Badges repository as OBSOLETE [Commit] [Followup]
Revamp Fedora Badges Project (into develop) [Merged]
Port the project management aspect from Poetry to UV [Triaged A] [Triaged B]
Refreshed the Fedora Badges staging deployment [Resource]
Update badge rarity calculation [Reviewed] [Followup]
Modularize the dbapi module while retaining the references [Followup]
feat: normalize tags into separate tables [Review A] [Review B]
Readme.md file update [Closed] [Followup]
Update badge rarity calculation [Review A] [Review B]
rhel10 migration: tang servers
rhel10 migration: memcached instances
nftables cleanup, and table rename
discover why proxy11 struggles with restarting apache

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.

Reported bugs related to Thinkpad X1 Carbon Gen14, a laptop that could be in the next laptop models offering for RHatters. Both the microphone and camera are broken. Notified the CSB team and Mark Pearson from Lenovo.
We missed an installer crash in F44 KDE and other spins (but not Workstation), documented it and took follow-up steps to prevent it in the future. We have flagged before that having multiple installer UIs and storage paths raises the risk of this kind of situation
Ongoing tool tech debt and enhancement work: reviving and fixing issuebot, MCP server and devcontainer config for testdays-web, cloud automation now reporting to resultsdb
cloud automation found systemd bug at AWS
openQA: deployments upgraded to Fedora 44 and new os-autoinst packages, fedora-media-writer coverage extended, discovered multiple dependency bugs, dracut decryption bug, plymouth keyboard layout bug, KDE config panel layout bug

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.

Remi Collet: 🎲 PHP version 8.4.22RC1 and 8.5.7RC1

2026-05-22T05:09:00+00:00

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

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

Remi Collet: ⚙️ PHP version 8.4.22 and 8.5.7

2026-06-05T04:40:00+00:00

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:

Fedora Rawhide now has PHP version 8.5.7
Fedora 44 - PHP 8.5.7
Fedora 43 - PHP 8.4.22

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

Fedora Badges: New badge: Flock 2026 Attendee !

2026-06-05T00:22:08+00:00

Michel Lind: Work-Life Balance 🏖️ with Sandogasa 👒 Hat-Track

2026-06-05T00:00:00+00:00

Avi Alkalay: USTR🇺🇸 × 🇧🇷PIX

2026-06-04T23:59:00+00:00

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.

Christof Damian: Friday Links 26-18

2026-06-04T22:00:00+00:00

Fedora Infrastructure Status: Updates and reboots on Fedora infrastructure

2026-06-04T21:00:00+00:00

Peter Czanik: The status of OpenSSL 4.0 support in syslog-ng

2026-06-04T12:01:40+00:00

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

2026-06-04T08:00:00+00:00

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.

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

Fedora Magazine: Fedora 43 Upgrade revealed 20 years old Outlook Security Bug

2026-06-03T19:19:57+00:00

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/

Akashdeep Dhar: Mindshare Election For FL44: Interview With Akashdeep Dhar

2026-06-03T18:30:44+00:00

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

FAS ID: t0xic0der
Matrix Rooms:
- Fedora Council (#council:fedoraproject.org)
- Fedora Mindshare (#mindshare:fedoraproject.org)
- Fedora Forgejo (#fedora-forgejo:fedoraproject.org)
- Fedora Infrastructure (#admin:fedoraproject.org)
- Fedora Badges (#badges:fedoraproject.org)
- Fedora Apps (#apps:fedoraproject.org)
- Fedora Join (#join:fedoraproject.org)
- Fedora Mentoring (#mentoring:fedoraproject.org)
Fedora User Wiki Page

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.

Akashdeep Dhar: Council Election For FL44: Interview With Akashdeep Dhar

2026-06-03T18:30:40+00:00

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

FAS ID: t0xic0der
Matrix Rooms:
- Fedora Council (#council:fedoraproject.org)
- Fedora Mindshare (#mindshare:fedoraproject.org)
- Fedora Forgejo (#fedora-forgejo:fedoraproject.org)
- Fedora Infrastructure (#admin:fedoraproject.org)
- Fedora Badges (#badges:fedoraproject.org)
- Fedora Apps (#apps:fedoraproject.org)
- Fedora Join (#join:fedoraproject.org)
- Fedora Mentoring (#mentoring:fedoraproject.org)
Fedora User Wiki Page

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.

Fedora Magazine: Valentin Rothberg on Building the Future of Fedora Containers

2026-06-03T08:00:00+00:00

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.

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

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

2026-06-02T22:40:26+00:00

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.

Fedora Magazine: #Commit History: Tell Us About Your First Commit

2026-06-02T14:11:26+00:00

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.

Fedora Infrastructure Status: Planned Outage - Fedora Copr - copr-backend upgrade

2026-06-02T09:00:00+00:00

Fedora Community Blog: F44 Elections Vote Now!

2026-06-01T13:39:46+00:00

The F44 elections voting period is now open! The ballot boxes for this cycles elections are open from today, Monday June 1st until Friday, June 12th on the elections app. The ballot boxes will close on June 12th at 23:59:59 UTC.

For links to candidate interviews, please visit this post or the nominations wiki page of each election.

As the number of eligible candidates (4) equaled the number of open seats (4) for the EPEL Steering Committee, no ballot box is available for this election. Instead, these candidates are automatically elected by default.

Good luck to all of our candidates across Fedora Council, FESCo and Mindshare Committee during this election cycle!

The post F44 Elections Vote Now! appeared first on Fedora Community Blog.

Marcin Juszkiewicz: Arm desktop: so many cores, not enough speed

2026-06-01T13:06:00+00:00

Using a system with 80 AArch64 cores can be a pleasure. Or a pain…

Multicore heaven?

Having 80 cores sounds nice, doesn’t it? But not so much during actual use…

You see, building Fedora packages was flying by. With all cores in use, ccache buffers filling up (in case of rebuilds), and 128 GB of RAM in constant use, etc.

But at the same time, 100% load on all cores means you cannot listen to music on Spotify or watch online videos, etc. All that because the CPU cores are occupied by the build processes.

I tried to use cgroups to limit cpu.max for each fedpkg mockbuild call. It did not help much: the audio was still jerky.

To compare: I wrote this post on a system powered by a Ryzen 5 3600 CPU while a package build was running in the background. All twelve CPU threads were 100% busy, yet the music did not skip.

All of this shows that cores-heavy CPUs are perhaps not a good choice for a desktop machine. Latencies, the scheduler and context switching — all of this introduces enough noise to make a desktop user suffer.

The lack of single-thread speed

Arm processors are good in many cases, as long as you do not need pure, single-thread, CPU power.

It is very noticeable in a web browser. For example, Bitwarden unlocks with a noticeable delay, while on a Ryzen 5 3600, it is nearly instant. And it feels even worse when you watch some YouTube videos like “who will make faster PC on a €100 budget”, and then you run the same browser benchmark and get worse results…

Many software builds also highlight this problem. I have a feeling that developers have grown used to a small number of fast CPU cores, which is the norm on the x86-64 architecture, and their code is written to take it for granted.

And then you look at your machine, where 70 cores do nothing, waiting for some code to finally compile or link. I have seen one software package where the bootstrap was composed of TWO source files. Both were over two megabytes in size and full of machine-generated C code. Two cores were kept busy for quite a while, while the other 78 had to wait.

Not much has changed since my the “From the diary of AArch64 porter — parallel builds” blog post from eight years ago.

Of course, there are also packages which will take all cores, whole memory and as much swap as possible, and do magic in nearly no time. When I started build of the PrusaSlicer package, I had to add some swap because Firefox was gone due to OOM. Having less than 2 GB of RAM per CPU core really sucks ;D

Summary

To use a desktop system you do not need many cores. As long as they are fast.

Aurélien Bompard: From May 25 to May 31

2026-06-01T08:35:00+00:00

This week's main focus was on community governance and future planning, with the announcement that F44 election interviews are now live for the Council, FESCo, and other committees. In parallel, many groups are preparing for the next release cycle, with FESCo introducing several system-wide change proposals for Fedora 45, including updates to Golang 1.27, RPM 6.1, and the adoption of PURL metadata. Common infrastructure topics included the official End of Life for Fedora 42 and the planned decommissioning of pagure.io. A significant point of discussion across multiple teams was the impact of artificial intelligence; while the Council discussed a potential AI ecosystem and the AI & ML team worked on NPU support, the Quality and Security teams were occupied with investigating and reverting disruptive, unsupervised changes made by an agentic AI. Other key efforts include the KDE SIG's testing of the Plasma 6.7 beta and the Server team's planning for a new "Home Server" spin.

Announcements

This week's main focus is on community governance, with the announcement that F44 election interviews are now live. A central post provides easy navigation to all interviews with candidates for the Fedora Council (1, 2, 3, 4, 5, 6), FESCo (1, 2, 3, 4, 5), the Mindshare Committee (1, 2, 3, 4), and the EPEL Steering Committee (1, 2, 3). Voting begins on June 1st. In other community news, there is a call for on-site volunteers for the upcoming Flock to Fedora 2026 conference, and a report was published on Fedora's presence at the 20th Linux Session in Poland.

On the technical front, users and contributors should be aware that Fedora 42 has reached its End of Life and will no longer receive updates. A reminder was also sent about the upcoming decommissioning of pagure.io, with a call to migrate repositories to the new Fedora Forge. Looking ahead to Fedora 45, several system-wide change proposals were announced, including updates to Golang 1.27, RPM 6.1, and Erlang 27, as well as a proposal to adopt standardized PURL metadata to improve package mapping. Finally, the Community Update for Week 22 covers progress from various teams, and Fedora Magazine published a guide on installing Fedora Linux across two disks.

Council

This week's discussions covered a proposal for a new Fedora AI Ecosystem, the plan for decommissioning pagure.io, and the eligibility of younger candidates for the Council. The AI initiative sparked a debate on whether Fedora should develop its own software stack to compete on the world stage or focus on packaging existing tools. The proposal's author suggested creating a GPU engineering SIG and emphasized the goal of fostering direct communication between developers and users, though community members noted the significant challenges and the already fragmented AI landscape.

In an important update regarding the decommissioning of pagure.io, it was clarified that the service will be made read-only around Flock 2026. A new discussion also arose about whether teens can run for the Council, following the nomination of a 16-year-old candidate. The community response was overwhelmingly positive, with a consensus that candidates should be judged on their merit and contributions, not their age, and that the Council should adapt to accommodate any elected member's logistical needs.

Decisions

The pagure.io service will be made read-only around the Flock 2026 timeframe. Write access to git repositories and issue trackers will be disabled. A read-only mirror of existing content is being developed. Exceptions will be made for critical use cases (like the CoC process) which will retain read-write access on a reduced version of the service. (Link to comment)

Learn more about the Council team.

FESCo

The main topic of discussion in this week's FESCo meeting was the process for selecting a new representative to the Fedora Council. The committee discussed the time commitment, the ideal term length, and whether the selection should happen before or after the upcoming FESCo elections. Ultimately, they decided to postpone the selection until after the elections are finalized.

Several new Change Proposals for Fedora 45 were introduced this week, inviting community feedback. These include updates for RPM to version 6.1, Erlang to version 27 (now unblocked by RabbitMQ support), and Go to version 1.27. A significant new proposal aims to adopt PURL (Package-URL) metadata across various language ecosystems to standardize package identifiers, which will improve security vulnerability tracking and SBOM generation. Additionally, it was announced that the Perl 5.44 update was formally accepted by FESCo.

Learn more about the FESCo team.

Packaging Committee

The Packaging Committee held one meeting this week, focusing on several proposed guideline changes. A significant discussion occurred around PR #1539, which clarifies the allowance for pre-generated JavaScript and CSS. While the PR aligns with existing FESCo policy, recent issues with critical path packages have created a desire to revisit and potentially tighten these rules. The PR was put on hold, and a new ticket will be opened to re-evaluate the policy. The committee also reviewed a complex proposal for generating OpenStack client bash completions using filetriggers and systemd units (issue #1538). The proposed mechanism was deemed potentially problematic, and the discussion was tabled for a future meeting.

Decisions

In the Packaging Committee meeting, two pull requests were approved to remove outdated recommendations for RPM macro syntax:
- PR #1540
- PR #1541

Learn more about the Packaging Committee team.

Mindshare

During its meeting on May 28, the Mindshare Committee focused on event funding and planning for Flock 2026. Acknowledging mid-year budget constraints, the committee addressed a sponsorship request for FrOSCon by tentatively approving an initial 500 EUR commitment. The group also finalized the structure for the Mindshare Town Hall at Flock 2026, which will be an "Ask Me Anything" (AMA) style panel featuring both outgoing and incoming members to discuss their work and facilitate a smooth handover. On the operational side, a decision was made to archive the outdated Fedora Handbook repository. Separately, a forum discussion continued on the future of surveys in Fedora, emphasizing the need for a collaborative design process to ensure survey quality, regardless of the tool used.

Decisions

An initial sponsorship of 500 EUR was tentatively approved for FrOSCon 2026, pending a full asynchronous vote from all committee members.
The legacy Fedora Handbook repository will be moved to the Fedora Docs Archive organization on Forgejo.
The event request for Nerdearla (Argentina & Mexico) was closed as it lacked necessary details like a budget and value proposition. The reporter was asked to open a new ticket using the correct template.

Learn more about the Mindshare team.

Workstation / GNOME

In the Workstation Working Group Meeting on May 26, the group discussed the upcoming resignation of long-time member Tomáš Popela, which prompted a conversation about the group's effectiveness and the need to attract new contributors. This presents an opportunity for those interested in getting more involved. The migration of the group's documentation from Pagure to Forgejo is also nearing completion.

On the technical front, the call for testers for the new Google Drive integration in GNOME continues to receive positive feedback. A new discussion was started about improving the Fedora upgrade process, with a suggestion to make prerequisite system updates automatic or mandatory in the GUI before a major version upgrade. It was recommended that this be filed as an enhancement request with the upstream GNOME project.

Learn more about the Workstation / GNOME team.

KDE

This week, the KDE SIG's main focus was on the upcoming Plasma 6.7 release. A new KDE Plasma 6.7 Beta (6.6.90) was made available for public testing in a dedicated COPR repository. Testers are encouraged to use this beta software on non-production systems to help identify and report bugs. An update to Beta 2 (6.6.91) was also pushed to the repository later in the week. In other discussions, a user's feature request for a new screen edge option was redirected to the upstream KDE community, and they were also informed that the desired action (maximizing window height only) can already be achieved by middle-clicking the window's maximize button.

Learn more about the KDE team.

Server

The Server Working Group's main focus this week was the new "Home Server" spin-off, discussed during their weekly meeting. The group is planning the initial software selection and user experience, with a key strategy being the use of Ansible for post-installation configuration. The goal is to ship Ansible roles and sample playbooks, possibly integrated with a simple Cockpit UI, to automate setup for users new to server management. This initiative represents a significant opportunity for contributors interested in Ansible, Cockpit, and image creation.

In addition to the spin-off, the team discussed improving their project management processes. They reviewed plans for creating issue templates in their Forgejo ticket tracker and agreed to experiment with a more systematic set of labels to better track project status. A summary of the meeting and open action items was also posted to the mailing list.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team prepared for a mass update and reboot outage scheduled for the following week. A major project milestone was announced: the migration from Nagios to Zabbix for monitoring is nearly complete. The team also discussed the upcoming Flock conference and a potential travel directive that might affect attendees. On the mailing list, an official announcement was made that Fedora 42 has reached its End of Life, with its content now archived and scheduled for removal from main mirrors in two weeks.

During the weekly meeting, several long-standing tickets were reviewed. The team discussed the significant storage used by the container registry (#11512) and hopes the planned migration to quay.io will help address it. Other topics included ongoing investigations into proxy server alerts, work to update the Fedora Wiki theme for Fedora 44, and an exploration into setting up a public-inbox service on Communishift. For those looking to contribute, an issue with mote's team processing (#12873) was identified as a good task for a newcomer. Additionally, a discussion on the mailing list clarified how the mirror selection service handles country-specific requests, explaining the fallback logic for regions with few mirrors.

Learn more about the Infrastructure team.

Quality

The primary event this week was the discovery and subsequent investigation of an agentic AI system making unsupervised and incorrect changes to Fedora's Bugzilla and upstream projects. The system was operating under a contributor's account, which was claimed to be compromised. The incident caused significant disruption, requiring a manual review and reversal of the AI's actions. It also sparked a serious discussion about the potential for such systems to be used in supply chain attacks, drawing parallels to the xz backdoor incident. On a more routine note, the weekly Quality meeting was a brief, informal chat due to low attendance, where the idea of an LLM-based bot for creating test days was discussed, and a known bug with live installs on X.org in Rawhide was highlighted.

In community news, an important announcement was made that Fedora 42 has reached its End of Life and will no longer receive updates. For those looking to contribute, testing is requested for new nightly composes of Fedora 45 Rawhide and Fedora-IoT 45. Additionally, community feedback continues on the call for testers to restore Google Drive integration in GNOME.

Learn more about the Quality team.

Design

The discussion around the Prototype for a Modernized Fedora Media Writer saw renewed activity this week. A new functional prototype, built with Rust and the Iced toolkit, was shared by contributor Markus Götz, sparking conversation around its technical implementation and design. This led to broader discussions on the future of the tool, including a proposal for a web-based writer, though technical challenges with browser access to local hardware were noted.

A significant part of the conversation focused on the need to address existing functional problems, not just the user interface. A critical, long-standing bug causing media verification to fail was highlighted as a top priority for any new version. Contributors are encouraged to provide feedback on the new prototype, help investigate the root cause of the media check bug by looking at how other tools like Rufus and Etcher operate, and join the conversation on the overall direction of this important first-touch application for new Fedora users.

Learn more about the Design team.

Docs

This week, the Docs team published the new "Fedora Discussion Forum (Self-)Moderation Guidelines and Rules", officially retiring the old "Ask Fedora SOPs". The new guidelines are now live and linked from the Mindshare documentation section. Additionally, a significant discussion continued regarding the project's policy on documenting the installation of proprietary NVIDIA drivers. Contributors are exploring how to provide helpful instructions for users while navigating legal concerns about linking to third-party repositories like RPM Fusion. The conversation is weighing the possibility of instead documenting the official, opt-in fedora-workstation-repositories method for installing the drivers.

Learn more about the Docs team.

Internationalization

During the weekly Internationalization meeting, the team issued a final call for help with triaging Fedora 42 bugs before the next release cycle. The discussion then turned to planning for Fedora 45, with a reminder about the upcoming deadlines for Change proposals. One potential Change proposal involves consolidating multiple hunspell dictionary source RPMs into a single package.

A key topic was the future of packages maintained by user pwu, who is seeking help or new maintainers for approximately 40 packages, including many fonts and input method components. This presents an opportunity for contributors to get involved, and one member has already volunteered to help with the font packages. The team also discussed future technical improvements, such as adopting Wayland semantic pre-edit styling for the ibus-chewing input method to enhance user experience on modern desktops.

Learn more about the Internationalization team.

EPEL

In the weekly EPEL meeting, discussions covered committee matters and infrastructure updates. In election-related news, long-time member nirik announced he would not be seeking re-election for the next term, and nominees for the Steering Committee were reminded to submit their interview questions. There was also a positive update on the EPEL logo redesign, which is expected to move into an official design sprint soon.

Learn more about the EPEL team.

ELN

The ELN SIG held its weekly meeting to discuss several ongoing initiatives. A key topic was the plan to update the s390x architecture baseline to z15/z16 for ELN in preparation for RHEL 11. This change, which was missed for Fedora 44, is now being coordinated for both ELN and Fedora 45 to maintain alignment. The group also reviewed progress on enabling gating for kernel updates to improve stability, which is currently waiting on a review for a pull request to Bodhi.

Other discussions included the transition away from the deprecated libappstream-glib in favor of the newer appstream library. This move is blocked until the asgen tool can replace the existing asbuilder without breaking repository metadata. Progress on adding bootc support continues, with a call for volunteers to act as co-maintainers.

Learn more about the ELN team.

Atomic

This week, discussion continued on the tutorial for replacing the Fedora Flatpak remote with Flathub. A user attempting to follow the guide reported an error (Update is older than current version) when trying to reinstall their applications from Flathub. They shared a successful workaround, which involved manually uninstalling and reinstalling the specific application that caused the error. This discussion highlights a potential edge case in the migration process that may require an update to the tutorial's instructions.

Learn more about the Atomic team.

CoreOS

In the weekly CoreOS meeting, the team discussed two main proposals. The first was to switch container image layer compression from gzip to zstd to improve update speed and reduce bandwidth. This proposal was agreed upon, pending benchmarks to confirm its benefits. The second major topic was a proposal to denylist a set of rarely used kernel modules by default to reduce the security attack surface. While the goal was supported, concerns about maintenance and divergence from standard Fedora were raised. The discussion concluded with a plan to explore this idea collaboratively with other Fedora editions, such as the Atomic Desktops and Cloud variants, to potentially create shared "server" and "desktop" hardening profiles.

During the open floor, a call for review was made for an Afterburn pull request that implements password hashing. Contributors are welcome to assist with the zstd benchmarking effort or review the pending Afterburn change.

Learn more about the CoreOS team.

IoT

During the weekly IoT meeting, the group discussed creating new documentation for small projects to help users get started with Fedora IoT, such as using Raspberry Pi hats or setting up kiosk mode. There are opportunities for contributors to suggest project ideas or write guides, with one member already volunteering to create a more comprehensive guide for setting up the Jetson. The team also reviewed the status of Fedora 44, noting that a new release is planned to address a bug (#136) and improve support for the Raspberry Pi 5. Testing for Fedora 45 (Rawhide) is proceeding normally.

Decisions

A new "projects" section will be added to the Fedora IoT documentation to host guides for users. These guides will be linked from blog posts to increase visibility.

Learn more about the IoT team.

AI & ML

This week, discussion continued in the long-running forum topic "Figuring out NPU support in Fedora". With the full driver stack for NPUs now available in Fedora 44, the conversation has shifted to next steps and remaining gaps. Contributors highlighted the need for a higher-level coordination layer or daemon, similar to PipeWire for audio, to arbitrate NPU access for multiple applications and provide a stable interface. This presents an opportunity for those interested in system-level architecture. Other points raised included the general difficulty of finding NPU hardware documentation and a specific request to package the AMD XRT user space driver to enable tools like FastFlowLM on AMD hardware, which is currently missing from the official Fedora repositories.

Learn more about the AI & ML team.

RISC-V

During the weekly RISC-V meeting, the main topics were the status of the Fedora 44 build and the hardware landscape. Progress on F44 is currently held up by a large Qt 6.11 update, which is blocking the creation of desktop images. However, patches for the blocking qt-webengine package are now available, which should allow work to continue. The group also discussed moving the secondary dist-git overlay to forge.fedoraproject.org/riscv to streamline development efforts before RISC-V becomes a primary architecture.

On the hardware front, a new P550 board was added to the build farm. The new SpacemiT K3 boards have begun shipping, with community members already working on kernel support and running benchmarks. While the K3 offers a noticeable performance boost (e.g., reducing GCC build times from five days to two), there was a consensus that it is likely still not fast enough for use in the main Fedora Koji build system. The group aims to avoid the slow build times that impacted the community during the initial rollout of the ARM architecture. There is ongoing work to secure funding for more powerful hardware suitable for Fedora's data centers.

Learn more about the RISC-V team.

Security

The Security team held their weekly meeting on May 28. A key topic was the recent incident involving potentially unsupervised, AI-generated contributions from a community member's account. The group discussed the implications for account security and the broader challenge of how the project will handle AI-generated content in the future, noting that a problematic pull request to the Anaconda installer related to this incident has been reverted. Additionally, the team reviewed a ticket regarding a TPM issue and concluded that while it should be kept open to monitor upstream progress, no immediate action is required since TPM-backed disk encryption is not an officially supported feature in Fedora.

Learn more about the Security team.

Perl

This week's activity for the Perl group centered on package maintenance. Jitka Plesnikova submitted and merged a pull request for the perl-Cache-FastMmap package. The update bumps the package to version 1.62 and adds package tests, addressing a specific bugzilla ticket. This reflects routine maintenance to keep Perl modules current within the Fedora ecosystem.

Decisions

The pull request to update the perl-Cache-FastMmap package to version 1.62 and add tests was merged.

Learn more about the Perl team.

Other Discussions

A call for facilitators was made for the upcoming Fedora Mentor Summit's "Lunch & Learn" sessions. Volunteers are needed to help start and guide informal discussions on various topics such as Documentation, Packaging, AI, and Design, to create a welcoming space for contributors to share experiences.
A bug was reported in a discussion titled "F45 anaconda breaks all X based spins". The F45 installer fails on Xorg-based spins like Cinnamon due to a Wayland socket issue. The report was confirmed to be a duplicate of a previously reported bug.
In the ongoing discussion about a jobs board, a new suggestion was made to look at Debian's consultant page as a model for a services advertising section. It was noted that this might be easier to manage and moderate than a full jobs board.
Following the first Fedora Hummingbird community meeting, a discussion took place to share notes and clarify the project's goals. The conversation covered what "Agentic Linux" means, the opportunities for contributors, and the technical vision of using AI agents to automate development and testing workflows. A recording of the meeting was partially successful and will be shared later. This was also announced on the devel mailing list.
A major incident was reported and discussed regarding an agentic AI system making unsupervised and inaccurate changes on behalf of a Fedora contributor. The system was incorrectly reassigning bugs, closing them prematurely, and submitting incorrect, LLM-generated fixes to upstream projects like Anaconda. The contributor claimed their account was compromised. In a follow-up thread, the situation was further investigated, and as a precaution, the contributor's permissions were revoked, and the problematic changes were reverted.
A widespread issue with GCC Internal Compiler Errors (ICE) was reported, affecting builds on s390x, i686, and eventually all architectures. The problem was quickly traced back to a recent glibc update in Rawhide. The faulty glibc build was promptly untagged from the buildroot, resolving the build failures.
Other discussions this week included a clarification that the p7zip package was correctly replaced by the official 7zip and that dependent packages like scancode need to be updated, a user reporting that kinit is dropping their audio, a maintainer running into issues pushing to an un-retired package, a discussion on why .oct files are not getting stripped, a report on upgrade bugs from F42 to F43 affecting PostgreSQL and Dovecot, a bug in rpminspect that was incorrectly flagging non-shell files, an investigation into why torsocks missed its mass rebuild due to an infrastructure error, and a discussion about file conflicts caused by the ongoing protobuf update.

Package Updates

A major update to python-cloudflare 5.2.0 is coming to Rawhide. This version includes many breaking changes, and the only dependent package, certbot, is being updated concurrently in the same side tag.
The update to OpenColorIO 2.5 is now complete, and the update has been submitted to Bodhi.
The rebuilds for the icu 78.3 update were scheduled to begin. However, they were put on hold after encountering widespread GCC failures, which were later attributed to a separate glibc issue.
The OpenEXR update was completed in Rawhide. It was noted that a couple of dependencies, libjxl-devtools and libjxl-utils, were initially missed but have since been queued for a rebuild.
An update to quazip 1.7 is being prepared in a side tag, along with rebuilds of its dependencies. A side discussion resolved an issue with rpmdev-bumpspec by clarifying that the rpmautospec package must be installed for it to correctly handle %autorelease.
Significant progress was made on the Protobuf update. The new version and its successfully rebuilt reverse dependencies were built in a side tag and have now been pushed to Rawhide. A list of packages that failed to build and those still needing to merge compatibility patches was provided.

Orphaning Packages

The libyui stack has been orphaned because it is no longer used by any packages in Fedora.
The qmc2 package was orphaned because its upstream is no longer active. A follow-up message provided links to related work in FreeBSD for any potential new maintainers.

New Contributor Introductions

Hugo de Benito introduced himself to the community. As a recent software engineering graduate, he is interested in contributing to backend development, packaging, and infrastructure, and is eager to learn about collaborating in a FOSS environment.

Rénich Bon Ćirić: Migración de nubes a gran escala: de VMware a OpenStack con os-migrate y Ansible

2026-05-31T17:15:00+00:00

La neta, la virtualización tradicional con VMware se ha vuelto un dolor de cabeza económico para muchísimas organizaciones. Con los cambios recientes de licenciamiento y la incertidumbre del mercado, quedarse ahí amarrado ya no tiene sentido. Pero, a final de cuentas, dar el salto a una nube abierta no es una decisión de "copiar y pegar"; es una chamba estratégica y bien técnica.

Si estás buscando migrar a OpenStack, especialmente a las arquitecturas modernas basadas en contenedores como Red Hat OpenStack Services on OpenShift (RHOSO 18) desde una nube heredada o desde infraestructura tradicional de vSphere, la gran pregunta es: ¿cómo mueves cientos de máquinas virtuales, redes, subredes, routers y firewalls sin romper nada en el camino y sin que te dé un infarto?

En este artículo, te voy a compartir cómo diseñé un proceso de migración masiva automatizada utilizando la colección oficial de Ansible os-migrate, resolviendo los retos de integridad de datos, paridad de red y control quirúrgico sobre cada recurso.

El dolor de cabeza de VMware y el paraíso de OpenStack

Moverse de VMware a OpenStack ofrece soberanía tecnológica absoluta y te libra del lock-in del proveedor. Además, migrar a versiones modernas de OpenStack como RHOSO 18 trae una ventaja brutal: el plano de control corre directamente sobre Kubernetes/OpenShift. Esto combina la agilidad y resiliencia de los contenedores con el poder de orquestación de máquinas virtuales tradicionales.

Sin embargo, el desmadre empieza cuando te das cuenta de que una nube no es solo un montón de hipervisores corriendo discos. Una nube real está compuesta por:

Estructura lógica de Keystone: Proyectos (tenants), usuarios, grupos y asignaciones de roles.
Redes lógicas de Neutron: Proveedores de red, subredes, routers, políticas de DHCP y reglas de puertos.
Seguridad (Security Groups): Firewalls lógicos con cientos de reglas de tráfico.
Almacenamiento (Cinder): Volúmenes huérfanos, adjuntos o de arranque.
Cargas de trabajo (Nova): Instancias de procesamiento con sus respectivos metadatos, puertos específicos y llaves de acceso.

Hacer esta migración a mano no vale la pena; es una receta garantizada para que todo valga madre al primer intento. Para resolver esto de volón, la automatización declarativa es tu mejor amiga.

El motor de la migración: os-migrate al rescate

La colección de Ansible os_migrate.os_migrate es, sin duda, la herramienta reina para este jale. En lugar de intentar programar llamadas directas a las APIs de OpenStack y batallar con inconsistencias, os-migrate trabaja bajo el paradigma de Infraestructura como Código (IaC) en un flujo de tres pasos sumamente limpio:

Exportar (Get): Extrae la configuración del entorno origen (sea una nube OpenStack previa como RHOSP 16.2 o metadatos intermedios de VMware) y los escribe en archivos YAML declarativos.
Saneamiento (Fix): Modificas los archivos YAML en disco para ajustar nombres de red, corregir MTUs lógicas o sanitizar metadatos obsoletos.
Importar (Set): Inyectas los archivos YAML en la nube destino para recrear los recursos de forma idéntica.

Arquitectura de control y conversión: Copia bit-a-bit

Para mover los bloques físicos de los discos (los volúmenes de Cinder o archivos de VMDK convertidos a QCOW2) de una nube a otra, os-migrate no pasa los datos a través de la máquina del administrador. Eso sería lentísimo y saturaría tu enlace de red.

En su lugar, el proceso que diseñé implementa una arquitectura híbrida sumamente chingona (ahí usté dispensará la falta de sencillez):

+---------------------------------------+
|             Nodo de Control           |
|              (Ansible Engine)         |
+---------------------------------------+
     |                             |
     | (Orquesta vía APIs)         | (Orquesta vía APIs)
     v                             v
+-------------------+         +-------------------+
|    Nube Origen    |         |   Nube Destino    |
|   (RHOSP 16.2)    |         |    (RHOSO 18)     |
|                   |         |                   |
|  [VM de Origen]   |         |  [VM de Destino]  |
|         |         |         |         ^         |
|         v         |         |         |         |
| +---------------+ |         | +---------------+ |
| | Conv. Host    |== SSH Tunnel (NBD)=>| Conv  | |
| | (Source)      | |         | | (Destination) | |
| +---------------+ |         | +---------------+ |
+-------------------+         +-------------------+

Nodo de Control: Una máquina virtual (en mi caso, corriendo RHEL 9 con arranque UEFI) desde donde se lanzan los playbooks maestros de Ansible. Debe tener conectividad de red con las APIs públicas y de administración de ambos clusters de OpenStack.
Nodos de Conversión (Conversion Hosts): Son instancias ligeras temporales (corriendo CentOS Stream 9) que se levantan dinámicamente: una dentro de la nube de origen y otra en la nube de destino.
Túnel Seguro de Datos: Cuando se activa la migración de un disco, el nodo de conversión origen monta el volumen de solo lectura, expone sus bloques usando nbdkit y los transmite bit-a-bit a través de un túnel SSH cifrado directo hacia el nodo de conversión destino, que escribe los bloques directamente en el nuevo volumen. ¡Rápido, seguro y sin intermediarios!

El jale automatizado: Orquestación con Ansible y GNUmakefile

Para evitar que los operadores tengan que memorizar comandos kilométricos de Ansible y cometer errores humanos, centralicé todo el flujo operativo en un GNUmakefile que simplifica la vida.

Ahí te va el cotorreo de cómo estructuré los comandos del orquestador:

# GNUmakefile
# Automatización del ciclo de vida de migración masiva

BASEDIR=$(CURDIR)
PY=$(BASEDIR)/venv/bin/python3
ANSIBLE=$(BASEDIR)/venv/bin/ansible-playbook

# Importación del baseline global de la nube (Flavors, Imágenes, Proyectos, Usuarios)
globals:
    $(ANSIBLE) -i hosts.yaml import_globals.yaml -e @vars.yaml

# Desplegar los nodos de conversión específicos para un tenant
conv-deploy:
        $(ANSIBLE) -i hosts.yaml deploy_conv_hosts.yaml -e project_name=$(PROJECT) -e @vars.yaml

# Orquestar la migración completa del tenant (Export -> Saneamiento -> Import)
migrate:
        $(ANSIBLE) -i hosts.yaml migrate_project.yaml -e project_name=$(PROJECT) -e @vars.yaml

# Eliminar los nodos de conversión una vez terminado el proceso
conv-delete:
        $(ANSIBLE) -i hosts.yaml delete_conv_hosts.yaml -e project_name=$(PROJECT) -e @vars.yaml

Con esta estructura, migrar un tenant de pruebas se reduce a ejecutar de volón:

make conv-deploy PROJECT=pruebas
make migrate PROJECT=pruebas
make conv-delete PROJECT=pruebas

Control quirúrgico, sanitización y rollback sin sustos

Durante mi diseño de este flujo para proyectos de gran escala, me topé con varios retos reales del mundo de la producción que logramos resolver de forma elegante:

Control Quirúrgico con Etiquetas (Tags)

A veces no quieres migrar todo el proyecto de un jalón; tal vez solo quieres recrear las redes para que los ingenieros de infraestructura las validen, o solo migrar un grupo de instancias específico.

Para lograr esta granularidad, implementé etiquetas de Ansible estructuradas en el playbook maestro migrate_project.yaml. Así, puedes realizar importaciones quirúrgicas seguras:

# Migrar únicamente la topología de red (networks, subnets y routers)
ansible-playbook -i hosts.yaml migrate_project.yaml -e project_name=pruebas -e @vars.yaml --tags networks,subnets,routers

# Migrar únicamente las instancias (workloads) asumiendo que la red ya está lista
ansible-playbook -i hosts.yaml migrate_project.yaml -e project_name=pruebas -e @vars.yaml --tags workloads

Sanitización y Parchado Automáticos

Mover datos entre nubes de diferentes generaciones (como de OpenStack 16.2 a 18.0) expone discrepancias en las APIs. Por ejemplo, ciertas propiedades del catálogo de Glance o metadatos de almacenamiento de Nova (volume_image_metadata) ya no son válidos o bloquean la importación en el destino.

Para resolver esto sin intervención humana constante, integré scripts de saneamiento automático escritos en Python y Bash (como sanitize_workloads.py y sanitize_subnets.py) que se ejecutan automáticamente en la fase de parchado del playbook maestro, ajustando los metadatos YAML al vuelo antes de inyectarlos en la nueva API.

Estrategia de Rollback y Seguridad

La regla número uno del administrador de sistemas es: "no destruirás el entorno origen hasta que el destino esté cantando victoria".

Por lo tanto, mi arquitectura de migración sigue una política estricta de seguridad:

El playbook maestro apaga automáticamente la instancia en origen (mediante la variable os_migrate_workload_stop_before_migration: true) para congelar el estado del disco y garantizar consistencia de bloques durante la copia NBD.
El volumen de origen se trata de estricto solo lectura.
La máquina virtual en origen NUNCA se elimina del cluster original.
Si la validación en la nueva nube falla por cualquier desalineación de la red física o de la aplicación, el rollback es inmediato y sin sustos: solo apagas la VM en el destino (RHOSO 18) y vuelves a encender la original en el origen (RHOSP 16.2). ¡Cero pérdida de datos!

La hora de la hora: ¿Te animas a migrar?

Migrar la infraestructura de tu organización de VMware a OpenStack (o saltar de versiones clásicas a las nuevas arquitecturas hiper-modernas basadas en OpenShift) no tiene por qué ser un dolor de cabeza ni un salto al vacío. Con una planeación arquitectónica sólida, automatización inteligente basada en Ansible, y el uso correcto de herramientas como os-migrate, puedes convertir un desmadre caótico en un proceso predecible, seguro y repetible.

Si andas batallando con el costo de las licencias de VMware, quieres planificar una migración robusta o simplemente te interesa platicar sobre cómo automatizar este tipo de locuras en tu infraestructura, búscame y échame un grito... ¡con gusto te hago el paro! 😉

Mi sitio de servicios profesionales: https://evalinux.com/

Mi correo: renich en evalinux punto com.

Vít Smolík: I am running for Fedora Council!

2026-05-31T10:16:51+00:00

Fabio Alessandro Locati: Btrfs scare

2026-05-31T00:00:00+00:00

Kevin Fenzi: misc fedora bits the last week of may 2026

2026-05-30T16:54:54+00:00

Another week has gone by, time for another longer form recap.

More rhel10 migrations

Some more rhel10 migrations this last week. This time our memcached instances, our tang servers and a few others. Slowly making progress, but this will get us down to the 'fun' ones: Database servers, virthosts that host important things, etc.

Fedora 42 eol

Tuesday was supposed to be the end of life for Fedora 42. For some reason, the date was set to be wed, and then there was some delays due to failed updates composes that pushed it to thursday. It's done however. Fedora 42 was a nice release, it served well. We still have just 3 Fedora 42 instances we need to move and we will do those next week...

Updated staging koji

I have updated our staging koji ( https://koji.stg.fedoraproject.org ) hub and builders all to Fedora 44 and the latest koji version (1.36.0). We have some non upstreamed patches for our theme, and koji upstream changed from cheeta to jinja2 for it's templates which completely broke that. I was able to use a clanker to rework the patch for jinja2 and then manually fix it from there to work. I'd say it was much quicker, but the process wasn't particularly satisfying. Anyhow, it's done and working as far as I have been able to test in staging.

Mass update/reboot cycle next week

We are going to apply updates all around and reboot things next week. There is a lot we hope to do on this outage:

rhel 9.8 and 10.2 came out, so we will be updating all rhel servers to those.
we will be upgrading the wiki servers from f42 to f44 (and newer mediawiki)
I hope to do some rhel10 reinstalls while we are in outage
Upgrade prod koji to 1.36.0 and f44 (hubs and builders)
There is a chance DC operations want us to move some servers from one set of racks to another to balance power usage out. Still to be determined if this happens.

So, it should be a busy week

Flock

The week after next, flock is already upon us! I hope to be there and able to catch up with old friends and new.

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

Rénich Bon Ćirić: Integrando FreeIPA como Sub-CA en mi PKI

2026-05-30T16:00:00+00:00

Hoy tuve un problemón bien gacho en el lab intentando que los certificados de FreeIPA se llevaran chido con el resto de mi infraestructura. FreeIPA es un sistema de identidad bien chingón, la neta, pero de fábrica viene muy chiquión: se monta su propia Autoridad Certificadora (CA) autofirmada y se la pasa generando alertas de "certificado no confiable" a menos que andes copiando su maldito certificado raíz en cada pinche máquina cliente. ¡Qué hueva, compa!

Por suerte, encontré una forma muy suave de arreglar este desmadre: integrar FreeIPA como una Sub-CA subordinada de mi propia PKI de EVALinux. Así, cualquier certificado que emita FreeIPA ya viene con la bendición de mi CA Raíz y todos los clientes confían en él automáticamente. ¿A poco no está chido, no?!

Mi Arquitectura PKI

Mi PKI en EVALinux sigue una jerarquía clásica de dos niveles para mantener la seguridad bien cabrona sin perder flexibilidad operativa:

La CA Raíz (Nivel 1):: Ubicada en root/. Es una CA que mantengo estrictamente offline, bien resguardada, y que nomás sirve para firmar a las CAs subordinadas. Jamás emite certificados para servidores o usuarios finales directamente. ¡Seguridad primero, compa!
CAs Subordinadas (Nivel 2):: Ubicadas en clients/. Estas son las que se fletan el jale diario. Cada cliente o entorno (como evalinux o g02) tiene su propia CA subordinada aislada, con su propia base de datos y lista de revocación (CRL).

Cómo Administro esta Onda

Para no andar batallando, tengo todo automatizado con un GNUmakefile global que es la pura sabrosura.

Creando una nueva Sub-CA:

Si me llega un cliente nuevo (digamos, acme), nomás corro un comando para crearlo:

# Creación de la CA subordinada para el cliente acme
make new-client client=acme

Este comando automatiza todo el jale: crea el directorio clients/acme/, genera la configuración de OpenSSL con plantillas y firma el certificado de la Sub-CA usando mi CA Raíz de EVALinux.

Emitiendo Certificados Finales:

Ya que la CA del cliente está lista, me meto a su directorio para emitir certificados para servidores u otros dispositivos:

# Generación de un certificado de host en clients/acme
cd clients/acme
make cert host=web01.acme.com

La automatización se encarga de meter los nombres alternativos (SAN) correctos y, para evitar broncas con fierros viejos, convierte las llaves privadas al formato RSA tradicional. ¡Una chulada!

El Workflow de Integración con FreeIPA

Integrar FreeIPA como Sub-CA sigue la misma lógica, pero requiere un pequeño "apretón de manos" entre ambos sistemas:

Generar el CSR desde FreeIPA: Le digo a FreeIPA que pause su CA interna y me genere una solicitud de firma (CSR) para una CA externa:
```
# Comando para generar la solicitud CSR en FreeIPA
ipa-cacert-manage renew --external-ca
```
Firmar el CSR con mi PKI de EVALinux: Me llevo el archivo CSR al servidor de mi PKI y lo firmo usando el perfil especial sub_ca_ext dentro del directorio del cliente correspondiente:
```
# Firmado de la solicitud CSR de FreeIPA usando mi PKI
cd clients/g02
make certs/ipa-ca.crt ext=sub_ca_ext
```

Importar y actualizar todo el desmadre: Regreso el certificado firmado y toda la cadena de confianza a FreeIPA para terminar la renovación:

# Comando para importar la cadena firmada y aplicar cambios en FreeIPA
ipa-cacert-manage renew \
   --external-cert-file=ipa-ca.crt \
   --external-cert-file=g02.crt \
   --external-cert-file=root.crt

ipa-certupdate

La Neta sobre los Dolores de Cabeza

En el papel todo se ve muy chido, pero a la hora de la hora me topé con dos broncas perras. Aquí te paso los tips para que no sufras como yo.

Pitfall #1: El loop infinito del AKI:

La solicitud CSR que genera FreeIPA suele traer una extensión llamada Authority Key Identifier (AKI) que apunta a sí misma. Si tu CA firma el certificado copiando todas las extensiones tal cual, se genera una referencia circular bien gacha que rompe la validación criptográfica. ¡STAY AWAY! de copiar extensiones a lo loco.

Tip

La solución fue actualizar mi archivo client.cnf para meterle la directiva copy_extensions = none cuando firmo peticiones de Sub-CAs. Así obligo a que mi CA corporativa defina la autoridad y no el solicitante caprichoso.

Pitfall #2: El cochinero en el directorio LDAP:

A la herramienta ipa-cacert-manage le encanta ir amontonando los nuevos certificados en LDAP sin limpiar los viejos. Si tu nueva Sub-CA se llama igual que el viejo root autorfirmado, Apache se confunde y sirve la cadena vieja e inválida. ¡Qué pinche coraje!

Warning

No te metas a borrar cosas a lo tonto en LDAP si no estás seguro.

Para solucionar este desmadre, tuve que aplicar una cirugía LDAP bien precisa. Usé ldapmodify para borrar manualmente los valores en base64 de los certificados viejos del atributo cACertificate;binary dentro de la ruta cn=ipa,cn=etc. ¡Santo remedio!

Conclusión

A final de cuentas, meter a FreeIPA bajo el paraguas de mi PKI me quitó el dolor de cabeza de andar lidiando con alertas de seguridad en los navegadores. Con una jerarquía limpia de dos niveles y un poquito de automatización chida, todo el entorno Linux camina sobre rieles. ¿Te ha tocado pelearte con FreeIPA y OpenSSL? Cuéntame tu experiencia. ¡A la orden, compa!

Referencias

Fedora Community Blog: F44 Elections Interviews

2026-05-29T23:03:10+00:00

The F44 election interviews are now live. With seats open across all leadership groups, this is one of our most popular election cycles yet! Use this post to navigate to candidates interview posts easily.

Voting will be open on Monday, June 1st and will close at 23:59 UTC on Friday, June 12th. Best of luck to all our candidates!

Fedora Council – 2 seats open

Fedora Engineering Steering Committee/FESCo – 5 seats open

Fedora Mindshare Committee – 4 seats open

EPEL Steering Committee – 4 seats

The post F44 Elections Interviews appeared first on Fedora Community Blog.

Fedora Community Blog: F44 EPEL Elections: Interview with Jonathan Wright (jonathanspw)

2026-05-29T22:59:20+00:00

This is a part of the Fedora Linux 44 EPEL Steering Committee 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 Jonathan Wright (jonathanspw)

What is your name and what is your FAS ID?

Jonathan Wright, jonathanspw

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

I’ve been a consumer of EPEL for…a long time. 20 years? I’ve been a contributor to EPEL for about the past 5, and on the EPEL steering committee for the past year.

EPEL is very near and dear to my heart and is actually how I got involved with Fedora. I’m on the AlmaLinux team and like everyone else, the first thing I do when installing AlmaLinux (previously CentOS) is dnf install epel-release. I’ve successfully graduated packages from EPEL that ultimately got picked up by RHEL (see Valkey) and work to make EL distros more usable by having an array of package availability that’s not otherwise available without EPEL.

Why are you running for EPEL Steering Committee member?

I have a unique perspective to bring to the table with my history in web hosting and long time usage of RHEL and its clones (CentOS and now AlmaLinux). The past year serving on the EPEL steering committee has been a great honor and I hope to continue in that role for another year.

The post F44 EPEL Elections: Interview with Jonathan Wright (jonathanspw) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 EPEL Elections: Interview with Diego Herrera (dherrera)

2026-05-29T22:56:04+00:00

Interview with Diego Herrera (dherrera)

What is your name and what is your FAS ID?

Name: Diego Herrera
FAS ID: dherrera

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

My relationship with open source started back in 2006, and I’ve been an
advocate since, both by contributing to various projects and by publishing
my own. My deep dive into EPEL began in 2013 while working in a company doing
R&D work for local industries, where I gained my first practical
experience with RPM packaging. This early work gave me a solid understanding
of what it means to build and manage software within the Enterprise Linux context.

More recently, I joined Red Hat in 2021 to work as part of the
CLE Team, where I deepened my understanding of how to become a proper Fedora packager
and contributor. I have been working together with Carl George, focusing on the
needs of EPEL by participating in steering meetings and doing work
regarding the project’s infrastructure. Through this position, I was able to
participate in activities such as packaging, writing documentation and SOPs,
collaborating on maintenance work required for the infrastructure, and improving
infrastructure automation. Furthermore, during steering meetings, I have been able to
add my viewpoints and insights when they were needed, and I was also able to
take on some of the steering team’s workload,
such as the Forgejo migration.

Why are you running for EPEL Steering Committee member?

Over the last few years, while spending time on the infrastructure side of the project,
I’ve seen first-hand the ups and downs of the project, which has enabled me to
collaborate closely with members of the community.

The EPEL steering committee is already a place where I have been able to
use my experience and knowledge to support and contribute to the project.
However, this time I want a vote on these topics. This will allow me to
collaborate further, helping to turn those discussions into a better
path for the project. I want to continue helping the community so
that the project can continue to grow into a great
platform by ensuring our governance is as solid and reliable as our processes.

For the sake of transparency, even if I wrote the text myself, I also used a local LLM (Gemma4:e4b) to iteratively fix the text’s grammar and flow.

The post F44 EPEL Elections: Interview with Diego Herrera (dherrera) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 EPEL Elections: Interview with Carl George (carlwgeorge)

2026-05-29T22:52:36+00:00

Interview with Carl George (carlwgeorge)

What is your name and what is your FAS ID?

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

I got my start in Fedora and EPEL in 2014. I was working for Rackspace and joined a team whose primary purpose was to maintain IUS, a third-party package repository for RHEL. Part of my work there involved contributing to and maintaining EPEL packages. I left Rackspace in 2019 to join the CentOS team at Red Hat. In 2021, I started a new team at Red Hat to specifically focus on EPEL activities.

During my time on the EPEL team, I’ve lead the design and implementation of EPEL 9 and EPEL 10. These releases each brought significant improvements to packager workflows and user experience, especially the introduction of minor versions in EPEL 10. We’re currently in the early days of planning EPEL 11, with a focus on continued refinement and quality.

Aside from the hands-on technical work of EPEL release engineering and packaging, I routinely attend conferences to deliver presentations about EPEL and staff Fedora/CentOS booths to engage with the EPEL community. I enjoy mentoring new packagers and helping existing Fedora packagers get started with EPEL.

Why are you running for EPEL Steering Committee member?

I have been on the EPEL Steering Committee since 2020. I have enjoyed my six years serving on the committee, and hope to have the opportunity to continue this important work. I am passionate about EPEL and I am committed to continue finding ways to improve the EPEL experience for both packagers and users.

The post F44 EPEL Elections: Interview with Carl George (carlwgeorge) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 EPEL Elections: Interview with Troy Dawson (tdawson)

2026-05-29T22:45:50+00:00

Interview with Troy Dawson (tdawson)

What is your name and what is your FAS ID?

Troy Dawson (tdawson)

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

I started contributing to EPEL 11 years ago with some nodejs packages for OpenShift. I later added rubygems and golang packages as OpenShift changed languages. Later, RHEL 8 did not have KDE, so I added KDE to epel8, and have been maintaining KDE in epel ever since. I have picked up many other packages during the years, but I think my KDE contributions are what I am most known for.

I’ve been the EPEL Steering Committee chair since 2020, taking over from Stephen Smoogen. A lot of changes have happened since then, most of them for the better. I’m not responsible for all the changes, but it’s been wonderful being part of the committee as these changes have come through.

Why are you running for EPEL Steering Committee member?

EPEL has grown to be part of my professional and personal life. I not only want to contribute to it, but help steer it’s growth and progression. I think as a EPEL Steering Committee member, I can help keep EPEL healthy and thriving.

The post F44 EPEL Elections: Interview with Troy Dawson (tdawson) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Mindshare Elections: Interview with Akashdeep Dhar (t0xic0der)

2026-05-29T22:37:26+00:00

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 (t0xic0der)

FAS ID: t0xic0der
Matrix Rooms: Fedora Council (#council:fedoraproject.org), Fedora Mindshare (#mindshare:fedoraproject.org), Fedora Forgejo (#fedora-forgejo:fedoraproject.org), Fedora Infrastructure (#admin:fedoraproject.org), Fedora Badges (#badges:fedoraproject.org), Fedora Apps (#apps:fedoraproject.org), Fedora Join (#join:fedoraproject.org), Fedora Mentoring (#mentoring:fedoraproject.org)

Questions

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

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

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

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

The post F44 Mindshare Elections: Interview with Akashdeep Dhar (t0xic0der) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Mindshare Elections: Interview with Mackenzie Stewart (monkeybean12)

2026-05-29T22:33:17+00:00

Interview with Mackenzie Stewart (monkeybean12)

FAS ID: monkeybean12
Matrix Rooms: I tend to use these Matrix channels, Fedora, Fedora EPEL Matrix, Announcements, Introductions.

Questions

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

My background in Fedora is using the Java programming language from Oracle and I have worked on games and graphics with Java language. I am currently writing computer programs for other computer languages which are Python, JavaScript in nodeJS and Building/Maintaining WordPress websites using PHP, HTML5 and CSS3.

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

I want to help bring people together and support the culture around Fedora, not just the technical work. Fedora is more than just an operating system to me — it’s a community. I want everyone who contributes, whether they code, design, or help run events, to feel valued and know their work matters.

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

I would propose a recurring, informal ” Monthly Community News” session—open to all—where Mindshare members discuss why certain decisions were made, rather than just reporting the results. Also to be a place for any updates or events to be introduced or announced so that it may generate more interest to all.

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

Mindshare should act as the “connective tissue.” I want to focus on creating a standardized, project-wide mentorship framework that assists sub-projects in bringing in new contributors.

The post F44 Mindshare Elections: Interview with Mackenzie Stewart (monkeybean12) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Mindshare Elections: Interview with Mat Holmes (theprogram)

2026-05-29T22:27:42+00:00

Interview with Mat Holmes (theprogram)

FAS ID: theprogram
Matrix Rooms: Join, Fedora, Fedora Social, DEI, Mindshare, Design, Council, CommOps, Server, Docs. I also monitor technical channels, but try not to distract people there too much.

Questions

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

I started with Fedora through Discussion, our Fedora Help Desk. This helped me both learn and teach about Fedora.
Once I found Matrix, I quickly got involved as a member and sponsor with Join, where I to this day very much enjoy meeting and welcoming many new people.
As I continued over the past couple of years, I have progressed to many people facing roles such as helping with DEI and CommOps. I also stick my beak into Mindshare and Council topics while trying to not step on peoples toes.
These days I have started writing Docs such as the Beginners Guide to Fedora and I am now helping with Server where we are developing new Beginners Guides to Server and the upcoming Home Lab.

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

Mindshare suites me very well as I have extensive experience organising events and doing outreach for professional organisations such as Amnesty International Australia and a political party (which I won’t name as politics is too divisive – but feel free to ask me about it).

My personal motivation is that I enjoy working with people in the Fedora community.

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

The role of Mindshare has changed over the last couple of cycles to be more focussed on events. I would promote people to talk early and often to us, so we can put more smaller events on the table.

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

I think Mindshare needs a clearer idea of what budget we have to work with, and we need faster responses to ticketed issues.
We also need to improve the accessible roads to ambassadorship, both in person and digital. Taking my skills from Join, I would extend this to being available to help plan broader small group involvement with communities all over the globe.

The post F44 Mindshare Elections: Interview with Mat Holmes (theprogram) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Mindshare Elections: Interview with Samyak Jain (jnsamyak)

2026-05-29T22:25:36+00:00

Interview with Samyak Jain (jnsamyak)

FAS ID: My FAS username is jnsamyak, and most people in the community know me by jnsamyak as well
Matrix Rooms: #releng:fedoraproject.org #admin:fedoraproject.org #release-day:fedora.im #devel:fedoraproject.org #mindshare:fedoraproject.org #social:fedoraproject.org #design:fedoraproject.org
Along with many contributor onboarding, event coordination, and Fedora community discussions across Matrix.

Since this is mindshare, Samyak wanted to do something innovative and creative for keeping mindshare spirit alive.

Questions

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

I currently work as a Fedora Release Engineer and have helped lead multiple Fedora Linux releases, including Fedora Linux 42, Fedora Linux 43, and most recently Fedora Linux 44. My work primarily involves release coordination, compose workflows, branching, signing operations, automation improvements, and ensuring smooth release execution across Fedora infrastructure.

Over time, I’ve also contributed toward improving release documentation, mentoring contributors, coordinating release-day activities, and helping newer contributors understand Fedora Release Engineering workflows.

Before Fedora, I contributed to Debian, primarily around Kotlin and Ruby packaging. When I joined Fedora, one of the first things that stood out to me was how welcoming and community-driven Fedora felt. Fedora India meetings became my first real social entry point into the Fedora ecosystem, and from there, I gradually became more involved in both technical and community activities.

Beyond Release Engineering, my Fedora journey has always been deeply community-focused. Some of the initiatives and events I’ve been involved in include:

Co-organizing Fedora Hatch Pune 2022
Leading Fedora’s involvement and organization efforts for GNOME Asia 2024 in Bangalore
Representing Fedora at Flock 2025
Representing Fedora at FOSSASIA 2026 to strengthen Fedora’s APAC visibility and outreach
Speaking at conferences like DevConf.cz, DebConf, GNOME Asia, and Fedora events
Supporting contributor onboarding and mentorship across APAC communities

One experience that particularly shaped my perspective was attending FOSSASIA 2026 as part of Fedora’s APAC outreach efforts. It gave me a much broader understanding of how rapidly open source communities are growing in Asia and how different communities actively engage contributors in the region.

That experience reinforced something important for me: Fedora already has incredible technical foundations and strong community values — but we can do much more in terms of visibility, onboarding, storytelling, and contributor engagement across APAC.

I also currently serve as an Outreachy mentor for the Fedora Release Planner Scheduler project, helping contributors navigate Fedora workflows, collaboration practices, and open source contribution processes.

For me, Fedora has never been only about releases or infrastructure. It has always been about building a welcoming and empowering community around open source.

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

My motivation comes from the grassroots experiences I’ve had throughout my Fedora journey. I’ve experienced Fedora from multiple perspectives:

As a newcomer entering the community
As a packager and contributor
As a Release Engineer
As an event organizer
As a mentor helping newer contributors

And one thing became very clear to me: communities do not grow only through technology — they grow through people feeling connected, supported, recognized, and welcomed.

Mindshare sits at the center of that experience.

A major part of this motivation comes from my experiences in APAC communities. I’ve met incredibly talented contributors who often remain unseen simply because they lack visibility, opportunities, guidance, or regional representation. I want to help change that.

Mentoring contributors through Outreachy and interacting with contributors during conferences like FOSSASIA and Flock made me realize how important human connection is in open source communities. Many contributors do not stay because of technology alone — they stay because:

Someone guided them
Someone encouraged them
Someone followed up with them
Someone made them feel like they belonged

That is one of the biggest reasons why I want to contribute more actively through Mindshare. My goal is not just to organize events or discussions, but to help create:

Better contributor journeys
Stronger regional connections
More approachable onboarding
More visible contributor recognition
More interactive and welcoming community spaces

Fedora’s vision talks about creating a world where everyone benefits from free and open source software built by inclusive and welcoming communities. That vision strongly resonates with me, and I want to actively help bring that vision closer to reality.

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

I believe Mindshare visibility improves when contributors can clearly see its impact in their day-to-day Fedora experience. Right now, many contributors still don’t fully know what Mindshare does, how it supports contributors, how regional communities can engage with it, or how contributors can benefit from its initiatives.

I’d like to focus on making Mindshare feel more visible, approachable, interactive, and community-connected across three areas:

Regional Community Spotlights

Introduce lightweight contributor and regional showcases highlighting APAC contributors, Fedora event organizers, mentors and advocates, community success stories, and new contributors making an impact. Sometimes even a simple spotlight can motivate someone to contribute more.

Better Contributor Onboarding and Retention

Help encourage contributor roadmaps by interest area, beginner-friendly onboarding guides, mentorship checkpoints, lightweight follow-up systems, and easier discovery of Fedora teams and opportunities. The contributor journey should feel exciting — not confusing.

Stronger APAC Engagement

Encourage more regional collaboration, Fedora representation at local FOSS events, community-driven mini events and workshops, localized outreach content, timezone-friendly engagement opportunities, and better contributor recognition from APAC communities. There are many hidden Fedora heroes across APAC, and I want to help amplify their stories.

More Interactive DEI Engagement

Explore more interactive approaches such as regional contributor stories, Fedora social storytelling campaigns, contributor experience videos, cultural exchange sessions, community-led DEI discussions, and language-inclusive engagement initiatives. Sometimes even a small welcoming effort can have a lifelong impact on someone entering open source for the first time.

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

The biggest area that needs attention is contributor growth and retention — especially across underrepresented regions like APAC. I would specifically focus on three major areas:

1. APAC Visibility and Contributor Recognition

There is immense untapped contributor potential in APAC. I want to help improve regional visibility, encourage local leadership, increase contributor recognition, strengthen cross-community collaboration, and build a stronger regional Fedora identity. Even small recognition efforts can significantly motivate contributors and make them feel valued.

2. Contributor Retention and Mentorship

We need smoother and more approachable contributor journeys. I’d love to help encourage structured onboarding pathways, defined contributor milestones, team-specific starter guides, mentorship and feedback loops, easier first-contribution experiences, and better newcomer follow-up systems. The goal is simple: make contributors feel supported from their very first interaction with Fedora.

3. Human-Centered Community Building and DEI

Fedora is one of the most technically strong communities in open source, but what truly makes it special is its people. I want to help strengthen community interaction, social engagement, inclusive participation, DEI-focused storytelling, contributor appreciation, and community belonging.

Ultimately, I want Fedora to continue being a place where contributors from every background feel welcomed, valued, heard, and inspired to stay.

While contributors may forget specific technical tasks over time, they always remember how a community made them feel.

The post F44 Mindshare Elections: Interview with Samyak Jain (jnsamyak) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Mindshare Elections: Interview with Luis Bazan (lbazan)

2026-05-29T22:23:16+00:00

Interview with Luis Bazan (lbazan)

FAS ID: lbazan
Matrix Rooms: All channels! A lot.

Questions

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

My experience with Fedora has involved working and collaborating with the community at both national and international levels, encouraging people of all ages to use and contribute to Fedora. I have worked closely with several countries to help support their growth, maintain community engagement, and motivate contributors to continue participating in the Fedora Project.

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

My main motivation, and what has always kept me connected to the Fedora community, is contribution, networking, and the friendships I have built within it. Beyond that, I truly value being able to continue motivating more people to stay involved in the project.

In my opinion, this is one of the most challenging parts of being a contributor: helping more users and engineers become interested in contributing and encouraging them to continue participating in some way within the Fedora Project.

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

To improve the visibility and awareness of the committee, we should continue working on the plans that are already in progress, because these are not tasks that can be completed in a single day. These initiatives require time to mature in order to improve processes that benefit contributors and the community. The goal is not to make processes more complex, but to improve them so they remain effective and practical for collaborators. This takes time, in addition to the many other responsibilities we manage on a daily basis.

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

I believe that the area requiring the most attention is related to events and budgeting. We have had tickets and requests that did not move forward because either the requirements process was not fully understood or the process itself was not completed properly. We should be more open and supportive in this area, especially regarding swag and other resources for smaller events organized in different countries around the world.

The post F44 Mindshare Elections: Interview with Luis Bazan (lbazan) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Council Elections: Interview with Miro Hrončok (churchyard)

2026-05-29T21:42:06+00:00

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 Miro Hrončok (churchyard)

FAS ID: churchyard (you may also find me as mhroncok)
Matrix Rooms: python:fedoraproject.org, devel:fedoraproject.org, council:fedoraproject.org, and many more

Questions

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

I’ve been an active Fedora contributor for over 12 years, co‑maintaining the Python and 3D‑printing stacks and sponsoring new packagers.
I served on FESCo for 5 years and I’ve been on the Council for 1 year. Technically I am on the Fedora Packaging Committee as well, but I am not very active there nowadays.

Through those roles I’ve gained understanding of how Fedora is built and governed. I wish to keep that experience in the Fedora Council and ensure that the people who do the day‑to‑day work of creating Fedora Linux have a strong, informed voice at the table.

I spent my first year on the Council mostly orienting myself and I am not very satisfied with my accomplishments (or lack thereof).
I was contemplating whether to not run again or to try harder. As you are reading this interview, it means I decided for the latter

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

My overall feeling after spending a year in this role is that there is this abyss between the Council and all the folks doing all things Fedora, like packaging. On one hand, we speak about initiatives, visions, and goals. On the other hand, there is Fedora Linux and people who make it. And I don’t feel like one hand knows what the other hand is doing. This has been frustrating to me and I decided to try to bridge that gap. I don’t have a ready-made solution for this yet, but it’s something that I strongly believe needs to be addressed and reflected in what Council is doing, approving, proposing.

Related to this, I feel that there is a more general risk of fragmentation of the community. For example, we seem to have moved some communication to discussion.fedoraproject.org while we kept others on the mailing lists. This move was a great opportunity to get more people involved in project discussions. At the same time, we risk losing the existing contributors. In the end, it seems we have two almost distinct groups of people who don’t talk to each other much.

No matter how many new contributors we get, we should not lose the existing ones, who are driving the project.

What brought you to the Fedora Project?

It was actually 3D printing.
Back in the day, we had a lab at the university with 1 (one) Prusa Mendel in it and I wanted to package some 3D printing apps like Skeinforge, Slic3r or Printrun for Fedora. I attended an RPM packaging workshop in the Brno Red Hat office and started packaging.
Not long after that I became a Fedora Ambassador, bringing the 3D printer to the Fedora booth at conferences.

The post F44 Council Elections: Interview with Miro Hrončok (churchyard) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Council Elections: Interview with Tomáš Hrčka (humaton, jednorozec)

2026-05-29T21:41:15+00:00

Interview with Tomáš Hrčka (humaton, jednorozec)

FAS ID: humaton, jednorozec
Matrix Rooms: fedora-forgejo:fedoraproject.org, releng:fedoraproject.org, admin:fedoraproject.org, release-schedule-planner:fedora.im, forgejo-chat:matrix.org

Questions

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

In previous years, I was a member of FESCo, where I gained exposure to the governance of the technical side of the Fedora Project.

In my professional life, I currently serve in a leadership role as Product Owner of the Community Linux Engineering team at Red Hat. Our team is responsible for a wide range of areas across the Fedora Project, including Quality Engineering, EPEL, Design, Infrastructure, and Release Engineering.

This gives me a unique perspective that combines community experience, technical understanding, and insight into how Fedora is supported inside Red Hat.

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

Opportunities

Immutable Desktop
Fedora is well positioned for the shift toward immutable and image-based operating systems. Projects like Fedora Silverblue and Kinoite already provide atomic updates and rollback capabilities while maintaining a strong developer experience.

Cloud-Native and Edge Computing
With Fedora CoreOS and Fedora IoT, Fedora already has strong foundations for container-focused and edge deployments. As these technologies continue to grow, Fedora can remain one of the leading platforms for modern infrastructure.

The Open AI Workstation
Developers increasingly want reliable environments for running local AI workloads and experimenting with open models. Fedora has an opportunity to become the preferred Linux workstation for this use case through strong hardware enablement, modern tooling, and fast adoption of new technologies.

Early Technology Adoption
Fedora has built a reputation for bringing important new technologies to Linux users early, whether that was systemd, Wayland, PipeWire, or Btrfs. That culture of innovation continues to attract developers and contributors who want to help shape the future of Linux.

Risks

Balancing Community and Corporate Influence
Fedora benefits enormously from Red Hat sponsorship, engineering support, and infrastructure. At the same time, maintaining community trust and independence remains critically important. Long-term success depends on keeping a healthy balance between corporate priorities and the Fedora community ethos.

Project Fragmentation
Fedora continues to grow across Spins, Labs, Editions, Atomic variants, and now containers. Growth is healthy, but it also increases the complexity of maintaining consistent quality, direction, and contributor focus across the project.

User Experience vs. FOSS Purity
Fedora’s commitment to free and open-source software is one of its greatest strengths. However, hardware enablement and multimedia support can still be frustrating for many users. Fedora should continue improving the onboarding experience without compromising its principles.

Competition
The Linux ecosystem is moving quickly. Arch Linux attracts many advanced users, Ubuntu remains dominant in commercial environments, and NixOS is gaining momentum among developers interested in reproducible systems and declarative infrastructure. Fedora needs to continue innovating while preserving the strengths that make the project unique.

What brought you to the Fedora Project?

As a user, I was basically forced by my older brother to use Fedora Core 1-3 on our shared family computer.

After a few years of distro hopping, I eventually returned to Fedora because it consistently provided modern software without requiring the amount of maintenance that distributions like Arch Linux demanded at the time.

After years of using Fedora, I wanted to give something back to the community. I started contributing through packaging and co-maintaining several Node.js and Ruby packages.

Later, I had the opportunity to join the Fedora Project professionally as part of the Release Engineering team. Over time, I transitioned into my current role as Product Owner for the team supporting Fedora inside Red Hat.

Today, I have visibility into how work is prioritized across the teams that provide Fedora infrastructure and services, support release engineering and quality processes, and contribute to areas like EPEL, Docs, and Design.

This brings me to the current Council elections. I believe Fedora is at an important crossroads. The project continues to grow, but at the same time, the distribution and contributor experience are becoming increasingly fragmented across Spins, Labs, Atomic variants, containers, and specialized deliverables.

I believe Fedora’s biggest challenge over the next few years will not be innovation. Fedora has always been good at innovation. The real challenge will be maintaining a clear identity, a healthy contributor community, and a coherent user experience while continuing to grow.

The post F44 Council Elections: Interview with Tomáš Hrčka (humaton, jednorozec) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Council Elections: Interview with Fabio Valentini (decathorpe)

2026-05-29T21:40:43+00:00

Interview with Fabio Valentini (decathorpe)

FAS ID: decathorpe
Matrix Rooms: Too many to list them all: #devel, #rust, #epel, #multimedia, #pride, #python, #quality, #security, … (on the fedoraproject.org homeserver)

Questions

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

I have served as a member of FESCo for six terms since I joined the project, and have also been a member of the Packaging Committee for over eight years now. In these roles (among others) I have gathered experience in a variety of both technical and non-technical areas including problem resolution, technical discussions, project management, technical writing / documentation, organizing meetings, etc.

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

I think it will be increasingly important to keep the balance between what makes Fedora successful and things that end up being costly distractions – to continue integrating new technologies into a modern, but stable distribution, while avoiding adoption of dead-end or unsustainable technologies from the current hype cycle.

What brought you to the Fedora Project?

Fedora is where my distro-hopping days unexpectedly ended a little over a decade ago. It has felt like home since.

The post F44 Council Elections: Interview with Fabio Valentini (decathorpe) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Council Elections: Interview with Aleksandra Fedorova (bookwar)

2026-05-29T21:39:43+00:00

Interview with Aleksandra Fedorova (bookwar)

FAS ID: bookwar
Matrix Rooms: Usually #council, #fedora-ci, #mine-with-fedora

Questions

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

For some time I was an admin of the Russian Fedora Remix services – maintained the site and the wiki. I also participated in moderation of some of our IRC, Jabber channels and forums, which gave me quite a lot of experience in dealing with the folks which are not necessarily IT experts and professionals.

I am also a proud survivor of the GNOME 3 and systemd debates there

Professionally I have worked as a support engineer, build/devops/CI engineer, team lead and product owner, which gives me a range of experience covering quite a lot of “non-coding but still engineering” topics. And I generally believe that there is a lot more in engineering than just writing code.

I also have been on the Fedora Council for some time now. I can not say I really know how to do this council thing correctly, but I am doing my best.

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

I believe that the general interest in Linux and Fedora in particular is on the rise, and we as a distribution currently are well placed to provide a lot of things people are looking for – stable base, variety of options, fast moving layers on top of integrated foundation and so on. It comes with the risk though as we just might spread too thin trying to cover all possible use cases, all the emerging technologies and all kinds of sometimes contradicting goals.

Our current project model, while open and community-driven, is still rather centralized.

As a big fan of the idea of federation, I believe that going forward we need to learn how to work with the wider ecosystem without necessarily pulling every connected piece into the same project hierarchy.

As a former Fedora Remix user myself, I see remixing(*) as one of the core ideas, which can help us turn a single distribution into a some sort of constellation of distributions. And while each remix may be managed by different groups and different rules, they still need to have a good collaborative relationship, a way to discuss and communicate changes, or to coordinate shared efforts. Of course they also need a way to communicate and share the load and costs.

(*) Here I use a word “remix” in the widest possible sense as in anything which uses Fedora content as a base, no matter what kind of content is added on top and what format of the deliverable is built from it.

What brought you to the Fedora Project?

Even though currently I work as a software engineer, I started to use Fedora not as a coder but as a user. I needed LaTeX to write my Master’s and PhD thesis, and at that time the support for LaTeX(with Cyrillics) was really only working on Linux. Big thanks to Tom (spot) Callaway who still packages texlive for Fedora.

So essentially I chose Linux (and Fedora) because it was the easiest thing for me to use.

Of course the name also did play a role. The more common Linux distribution choices in my community at the time were Gentoo or Slackware. People were talking how “Linux is about choice” and that sort of thing. But once I learned a bit more about the ideas behind different Linux distributions, I really got hooked on the concept of an integration, rather than customization.

The Upstream First principle in particular was rather eye-opening for me. The idea that you should not just build a system for your own needs – that is what the local folks were doing – but that you need to share and contribute those changes back, or at least to discuss them with the original developers to understand their thought process and the choices they made.

I always looked at my Fedora system not as a thing to tweak for my personal needs, but as a path to become a part of a larger community.

The post F44 Council Elections: Interview with Aleksandra Fedorova (bookwar) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Council Elections: Interview with Hristo Mainov (hricky)

2026-05-29T21:38:35+00:00

Interview with Hristo Mainov (hricky)

FAS ID: hricky
Matrix Rooms: #bootc:fedoraproject.org, #coreos:fedoraproject.org, #atomic-desktops:fedoraproject.org, #silverblue:fedoraproject.org, #kinoite:fedoraproject.org, #fedora-forgejo:fedoraproject.org, #docs:fedoraproject.org

Questions

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

While I don’t have formal governance experience, I’m an active contributor to several teams and organizations focused on image-based systems. This is the very area where Fedora is leading innovation. This gives me both technical depth in Fedora’s modern directions and practical insight into how image-based approaches are being adopted across the ecosystem. Additionally, as an independent contributor, I bring a perspective focused on the broader community’s needs.

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

Fedora’s leadership in image-based systems is a significant opportunity. The Atomic Initiative is advancing this space meaningfully. However, when such initiatives conclude, we must ensure contributors remain engaged and their work integrates into sustainable community practices.

More broadly, as AI becomes increasingly present in development workflows, we need thoughtful governance around how Fedora engages with it. This is about authorship, accountability, and the moral questions around code provenance and community contribution. Fedora’s values should guide how we engage with these technologies responsibly.

What brought you to the Fedora Project?

I initially needed an OS for on-premise servers, which led me to CentOS. The transition forced a reassessment, and during that process, I discovered Fedora’s emerging work on image-based systems. That discovery led me to get involved in related teams, which deepened my commitment to this community. Now, as an active contributor in that space, what keeps me here is the community itself. I’m inspired by it, and that’s what drives my continued involvement.

The post F44 Council Elections: Interview with Hristo Mainov (hricky) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Council Elections: Interview with Akashdeep Dhar (t0xic0der)

2026-05-29T21:37:56+00:00

Interview with Akashdeep Dhar (t0xic0der)

FAS ID: t0xic0der
Matrix Rooms: Fedora Council (#council:fedoraproject.org), Fedora Mindshare (#mindshare:fedoraproject.org), Fedora Forgejo (#fedora-forgejo:fedoraproject.org), Fedora Infrastructure (#admin:fedoraproject.org), Fedora Badges (#badges:fedoraproject.org), Fedora Apps (#apps:fedoraproject.org), Fedora Join (#join:fedoraproject.org), Fedora Mentoring (#mentoring:fedoraproject.org)

Questions

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

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

What brought you to the Fedora Project?

The post F44 Council Elections: Interview with Akashdeep Dhar (t0xic0der) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 Council Elections: Interview with Vít Smolík (smoliicek)

2026-05-29T21:37:16+00:00

Interview with Vít Smolík (smoliicek)

FAS ID: smoliicek
Matrix Rooms: admin:fedoraproject.org, noc:fedoraproject.org, join:fedoraproject.org, data:fedoraproject.org, commops:fedoraproject.org, docs:fedoraproject.org, fedora:fedoraproject.org

Questions

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

To strengthen my governance knowledge, I recently completed two courses on governance fundamentals. (Governance Training, and Tools for Project Planning)

I am also familiar with meeting procedures, including how meetings are structured, planned, run and how decisions are recorded. I participate in regular productive meetings with Fedora Infrastructure.

I’ve always been an active person, through cycling and competitive dancing, and even as a student, I’m always thinking about how I can make things better for others. Thus, my current governance experience comes from outside of the open-source world, however, it translates well to the Fedora Project.

I’m an elected member of my school’s board and a member of the school’s parliament. I’m familiar with what it means to represent a diverse community, balance viewpoints, and make consensus-driven decisions. In this role, I dealt with issues such as financial disbursement and conflicting student choice.

As an independent contributor, my focus is entirely on serving our community and listening to the communities voice. While I respect the fantastic work of those who came before me, I will bring independent perspective to the Council, guided by my ethical commitment to fully open-source software.

To me, software freedom is a digital right.

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

When looking at the landscape now, the single biggest risk facing Fedora right now is the rush to implement AI everywhere. This threatens not only a drop in quality of our codebases but also creates massive legal grey areas. The community is rightfully pushing back against this. Fedora must refuse to let this hype dictate our governance.

The opportunity for Fedora is to set the global standard for what a measured, ethical, and secure approach to AI tooling looks like. Instead of rushing to adopt external, proprietary black boxes, Fedora should take its time to define how open-source principles apply, prioritizing local execution, strict licensing compliance, and open-weight models. Fedora can champion true open-source principles in a changing landscape, proving that innovation does not require the sacrifice of security or ethics.

Our priority must always be human craftsmanship and infrastructure integrity; any tool we introduce must serve our contributors, not replace them.

What brought you to the Fedora Project?

My first introduction to Fedora happened on July 20, 2025, when I sent an introduction to the infrastructure mailing list. On May 21, 2026, I was sponsored to my first sysadmin group. That is what Fedora has done for me and what I can do for Fedora.

Before joining the project, I was a sysadmin working completely alone. Fedora gave me the space to learn how to function in a bigger team, how to navigate complex infrastructure, and how to collaborate effectively.

My trajectory shows I’m capable of learning, adapting, and integrating into complex systems at an exceptional pace. I’ve gone from a newcomer to an active contributor, not only in the infrastructure team but also in Fedora Data Working Group, where I’m helping Hatlas come to life, and in the Join team, where I help new contributors find their footing.

Fedora has helped me scale up my skills rapidly, and I am running for council to ensure Fedora remains just as dynamic, rock-solid, and welcoming for everybody else.

The post F44 Council Elections: Interview with Vít Smolík (smoliicek) appeared first on Fedora Community Blog.

Fedora Community Blog: F44 FESCo Elections: Interview with Fabio Valentini (decathorpe)

2026-05-29T21:07:58+00:00

This is a part of the Fedora Linux 44 FESCo 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 Fabio Valentini (decathorpe)

FAS ID: decathorpe
Matrix Rooms: Too many to list them all: #devel, #rust, #epel, #multimedia, #pride, #python, #quality, #security, … (on the fedoraproject.org homeserver)

Questions

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I have contributed to many areas of the project since I joined it over a decade ago, so I think I can bring a broad perspective to FESCo. I want to help insure the project’s continued success happens in a sustainable way.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I am the most active package maintainer in Fedora (by count of updates / builds), primarily because I am the main point of contact for most Rust packages. My work includes package updates, package review, triaging build failures and broken dependencies, and pruning packages for obsolete, outdated, or unused Rust crates from Fedora. I regularly contribute to upstream projects through bug reports and pull requests to fix issues that are discovered downstream in Fedora. Additionally, I triage, report, and attempt to fix upgrade path issues caused by missing package updates every release cycle.

How do you handle disagreements when working as part of a team?

Many disagreements I’ve handled were only concerned with details, while the goals of everyone involved were still aligned. So I try to find common ground and / or explore alternative or creative solutions that can work for everyone involved.

Where do you think the Fedora Project should position itself concerning the use of ‘AI’ in software development?

I am – in general – wary of becoming dependent on products from companies that are nowhere near profitable and only kept afloat by a combination of inconceivably large amounts of venture capital and “creative” investment arrangements. Additionally, to me these “AI” systems aren’t “just tools” and can’t be treated solely as such, especially due to externalities like unethical data scraping practices, copyright / license laundering, excessive power and water consumption, noise and greenhouse gas pollution, hardware shortages and price increases, etc. I have yet to see a competitive “AI” product that does not have these problems, and I am unsure whether creating one is even possible.

What else should community members know about you or your positions?

No pineapple, and definitely not on Pizza.

The post F44 FESCo Elections: Interview with Fabio Valentini (decathorpe) appeared first on Fedora Community Blog.

Fedora People

Michael Catanzaro: Please Do Not Ban AI-Assisted Issue Reports

Rajeesh KV: RIT Unny open source font

Aurélien Bompard: From June 01 to June 07

Table of contents

Announcements

Council

Decisions

Mindshare

Workstation / GNOME

Decisions

Server

Infrastructure

Release Engineering

Decisions

Quality

Design

Docs

Decisions

Legal

COPR

EPEL

Decisions

CentOS Hyperscale

ELN

Atomic

Decisions

CoreOS

AI & ML

Decisions

Security

DotNET

Go

Perl

Decisions

Python

Other Discussions

Orphaning packages

Package Updates

New Contributor Introductions

Fedora Magazine: Jona Azizaj – Why Mentorship at Flock Changes Everything!

Dennis Gilmore: Accessing serial consoles on SBC’s

Kevin Fenzi: misc fedora bits first week of june 2026

mass update/reboots

Some old long running tickets

And a few new things

flock

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

Fedora Community Blog: Community Update – Week 23 2026

Fedora Infrastructure

CentOS Infra including CentOS CI

RISC-V

AI

QE

Forgejo

EPEL

UX

Remi Collet: 🎲 PHP version 8.4.22RC1 and 8.5.7RC1

Remi Collet: ⚙️ PHP version 8.4.22 and 8.5.7

Fedora Badges: New badge: Flock 2026 Attendee !

Michel Lind: Work-Life Balance 🏖️ with Sandogasa 👒 Hat-Track

Avi Alkalay: USTR🇺🇸 × 🇧🇷PIX

Christof Damian: Friday Links 26-18

Fedora Infrastructure Status: Updates and reboots on Fedora infrastructure

Peter Czanik: The status of OpenSSL 4.0 support in syslog-ng

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

Fedora Magazine: Fedora 43 Upgrade revealed 20 years old Outlook Security Bug

Let us start with the beginning

The Day After

“Look, there is something out there!”

Really folks: use TLS encryption for your mailboxes!

Akashdeep Dhar: Mindshare Election For FL44: Interview With Akashdeep Dhar

Interview with Akashdeep Dhar

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

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

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

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

Akashdeep Dhar: Council Election For FL44: Interview With Akashdeep Dhar

Interview with Akashdeep Dhar

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