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

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

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

Fedora Forge Usage Policy

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

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

1. Scope, Criteria, and Exceptions

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

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

Criteria for "Fedora Project Related"

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

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

Exceptions and Special Cases (Ecosystem Upstreams)

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

Recognized Exceptions:

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

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

Decision Process for Edge Cases

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

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

2. Access and Authentication

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

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

3. Code of Conduct and Community Behavior

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

4. Prohibited Activities

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

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

5. Resource Limits and CI/CD

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

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

6. Repository Lifecycle and Organization

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

7. Support and Abuse Reporting

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

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

30 Jul 2026 12:11pm GMT

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

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

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

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

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

30 Jul 2026 8:00am GMT

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

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

The Transition

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

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

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

What stays the same

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

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

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

30 Jul 2026 8:00am GMT

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

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

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

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

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

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

Happy blogging!

29 Jul 2026 11:45am GMT

29 Jul 2026 11:37am GMT

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

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

Why this one stood out

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

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

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

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

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

What the community said

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

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

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

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

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

What happened after Prague

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

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

See you in 2027!

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

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

28 Jul 2026 8:00am GMT

28 Jul 2026 12:00am GMT

27 Jul 2026 10:00pm GMT

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

Announcements

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

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

Council

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

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

Decisions

• Agreed to advance the Fedora Forge usage policy by mandating a "tickets" repository for all organizations to facilitate communication, dropping the previous proposal for automatic repository archiving.
• Approved an exception to allow FreeIPA to create an organization on the Fedora Forge, recognizing it as a foundational ecosystem tool.
• Rejected a suspicious Forge organization request for a Software Engineering SIG because it was submitted by a brand-new account and failed to follow the documented SIG creation process.
• Agreed to revise the draft Conflict of Interest Policy to apply strictly to governance groups, protect GDPR privacy rights by not requiring detailed conflict explanations, and allow standard voting practices (like voting on one's own proposals) to continue with simple disclosure.

Learn more about the Council team.

FESCo

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

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

Decisions

• Change: RelocateRpmRepoConfigsToUsr was recategorized from a Self-Contained Change to a System Wide Change.
• For Change: libxml215, FESCo asked the Change Owner to update the wiki page to ensure critical path packages are fixed before the change is merged and to update for no releng-provided mass rebuild.
• Request to remove inactive software KVM projects: The barrier and input-leap packages will be retired without Provides being added.
• (Slightly) incompatible update request (one-off) for rust-routinator was approved.
• Adjust election policy regarding mid-term vacated seats was approved.
• Change: MariaDB 12.3 was approved.
• Change: MySQL 9.7 was approved.
• Change: Stratis Storage in Anaconda was approved.
• Change: Ruby on Rails 8.1 was approved.
• Change: Bash Color Prompt 1.0 was approved.
• Change: oo7 Secrets Service Provider was approved.
• Change: Fontconfig 2.18 was approved.
• Change: Disable Vendor Change by Default was approved.
• Change: LibreOffice Dictionaries was approved.
• Change: LibreOffice html help was approved.
• Change: Native Butane Config Support in Ignition was approved.

Learn more about the FESCo team.

Packaging Committee

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

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

Decisions

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

Learn more about the Packaging Committee team.

Mindshare

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

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

Decisions

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

Learn more about the Mindshare team.

Workstation / GNOME

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

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

Decisions

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

Learn more about the Workstation / GNOME team.

KDE

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

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

Learn more about the KDE team.

Server

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

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

Decisions

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

Learn more about the Server team.

Infrastructure

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

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

Decisions

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

Learn more about the Infrastructure team.

Release Engineering

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

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

Decisions

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

Learn more about the Release Engineering team.

Quality

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

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

Decisions

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

Learn more about the Quality team.

Design

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

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

Decisions

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

Learn more about the Design team.

Docs

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

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

Decisions

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

Learn more about the Docs team.

Internationalization

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

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

Learn more about the Internationalization team.

EPEL

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

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

Learn more about the EPEL team.

ELN

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

Decisions

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

Learn more about the ELN team.

Atomic

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

Learn more about the Atomic team.

CoreOS

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

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

Learn more about the CoreOS team.

AI & ML

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

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

Decisions

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

Learn more about the AI & ML team.

RISC-V

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

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

Decisions

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

Learn more about the RISC-V team.

Security

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

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

Decisions

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

Learn more about the Security team.

Go

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

Decisions

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

Learn more about the Go team.

Perl

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

Decisions

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

Learn more about the Perl team.

Python

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

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

Decisions

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

Learn more about the Python team.

Other Discussions

• Hummingbird Community Meeting - 23 July 2026 discussed the agenda for their upcoming meeting. Topics included AI's impact on open source, maintainer overload, and utilizing "factory" patterns for automated PRs to ensure contributions meet project standards.
• In How the Fedora 45 Sausage is Made, Simon de Vlieger shared a blog post detailing the process of producing Fedora, from packages to final artifacts like ISOs and disk images.
• A Change Proposal to use Sequoia for OpenPGP verification sparked a debate. The proposal suggests introducing an %openpgpverify macro to replace GnuPG with Sequoia, but developers strongly argued for keeping the existing %gpgverify macro name to avoid massive ecosystem churn and API/ABI breakage.
• The Shadow Stack by Default on x86_64 Change Proposal aims to enable hardware-enforced protection against ROP exploits. Discussions highlighted the need for i686 builds in testing repositories and clarified QEMU/libvirt support for the feature.
• A discussion on i686 removal - easy win set proposed adding ExcludeArch: %{ix86} to roughly 3,400 leaf packages to save build resources. While some suggested an opt-in approach for i686 instead, the consensus leaned towards moving forward with this opt-out approach via a formal Fedora 46 Change Proposal.
• The Disable in Kernel Crypto Userspace API (Phase 1) Change Proposal seeks to restrict the deprecated API to known users before upstream removes it entirely. Maintainers raised concerns about losing rootless access to LUKS containers for non-AES ciphers and VeraCrypt support, though the change is primarily about preparing users for the inevitable upstream removal.
• Adam Williamson announced a new feature for on-demand openQA testing of dist-git pull requests. Contributors can now comment /openqa test on a PR to trigger tests on the corresponding Packit scratch build, with results reported directly back to the PR.
• The RelocateRpmRepoConfigsToUsr Change Proposal intends to move RPM repository configurations from /etc to /usr. Adam Williamson raised concerns that this could disrupt existing workflows and scripts, suggesting it be escalated from a self-contained to a system-wide change.
• A Change Proposal for Web Based Remote Installation Support for Atomic Desktops aims to allow secure remote installations via the Anaconda WebUI. This opt-in tech preview will authenticate users with a PIN over HTTPS, bypassing the need for VNC/RDP clients.
• A targeted rebuild of Python packages with extension modules was announced for Rawhide due to an incompatible ABI change in Python 3.15.0b4. Maintainers were asked to hold off on building affected packages until the side-tag was successfully merged.
• Other discussions included a user trying to release a new version of a package, reminders for the F45 Self-Contained Change Proposal Submission deadline (and a duplicate reminder), complaints about slow s390x builds during the mass rebuild, a Change Proposal for LibreOffice Dictionaries, a review request for dupeguru, a fix for an outdated golang package on koji el8 build machines, questions about GCC plugins packaging for AFL++, inquiries if nextcloud-client is still maintained, a proposal to deprecate low-memory-monitor, an update for IBus 1.5.35, a proposal for Encapsule isolated devel containers, a proposal to switch to the Anaconda WebUI for Fedora Atomic, a proposal to hardcode nss-altfiles in Authselect profiles, a proposal to remove the Authselect NIS Profile, a proposal to enable systemd-oomd and zram swap for CoreOS, a patch submission for libndp, a clarification on why FTBFS bugs are no longer filed between mass rebuilds, a request of exemption for f45-backgrounds, and a request to add a CUDA backend to the Ollama package.

Orphaning packages

• Emanuele Petriglia inquired about the orphaned "fx" package, noting it was rewritten in Go, and successfully recreated the SRPM for review.
• Automated reports listed orphaned packages looking for new maintainers on June 21 and again on July 18.
• Efraim Kaov offered to step up for mcelog package maintenance and co-maintainership since it is outdated.
• The mysql8.0 package is retiring in Rawhide as it reached EOL upstream.
• Gabriel L. Somlo announced orphaning yosys/nextpnr & related packages due to a lack of time and unresponsive co-maintainers.
• A reminder was sent regarding the list of long term FTBFS packages to be retired in August.
• A request was made to unretire sugar packages (sugar and sugar-browse).

Package updates

• The f45-backgrounds package is available, but its initial 12800x12800 image broke KDE Plasma, prompting a resize to 8192x8192.
• An unannounced soname bump for nettle caused FTBFS for multiple packages, leading to a workaround using the nettle3.10-devel compat package.
• Similarly, an unannounced soname bump for openssl-pkcs11 broke rng-tools and the compose process, which was quickly fixed in a side tag.
• InsightTooklit 5.4.6 is coming to rawhide, requiring rebuilds for alizams and petpvc.
• A planned Flint soname bump was postponed because e-antic is not yet compatible.
• A shadow rebase and libsubid SONAME bump was announced, requesting rebuilds for apptainer, buildah, podman, and skopeo.
• The release of jimtcl 0.84 introduced a jimtcl soname bump affecting openocd.
• The Perl 5.44 upgrade has started in a dedicated build-root.

New contributor introductions

• Luca Albrecht

27 Jul 2026 4:51pm GMT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I am looking forward to seeing you all next year!

27 Jul 2026 9:39am GMT

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

26 Jul 2026 3:55pm GMT

26 Jul 2026 12:35pm GMT

24 Jul 2026 10:00pm GMT

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

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

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

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

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

24 Jul 2026 12:00pm GMT

24 Jul 2026 6:00am GMT

23 Jul 2026 10:00pm GMT