fidzu : Fedora

I just published the first version of the Maintainer's Guide to Hackfests. It's intended to be a short, practical guide for getting the most out of participating in a hackfest. As my luck would have it, this year's Hacktoberfest - the event that inspired me to write the guide in the first place - will be completely different from years past. But there are other hackfest events out there that you might want to participate in.

From being clear about why you're participating, to getting policies and configuration in place, the Maintainer's Guide to Hackfests condenses all of my experience in 16 short pages. If you find it useful, or if you find something confusing, missing, or flat out wrong, you can contribute. Or just start reading from the links below.

• PDF
• epub

This post's featured image from Control by Tristan Ferne, used under CC BY 2.0. Edited by Ben Cotton.

The post Maintainer's Guide to Hackfests appeared first on Duck Alignment Academy.

02 Sep 2026 12:00pm GMT

02 Sep 2026 11:49am GMT

An Outreachy internship note on the Fedora AI/ML editorial and packaging assistants

As part of my Outreachy internship with the Fedora Project, I built two retrieval-augmented generation (RAG) assistants: one for the Fedora editorial guidelines (Community Blog and Magazine) and one for the Fedora packaging guidelines. Both share the same key step: building a vector store. The assistant reads the source documents, splits them into chunks, and turns each chunk into an embedding it can search later.

For most of the internship, I ran these builds without a GPU. Once I had access to a GPU instance, I re-ran the same builds on the GPU and measured the difference. On both projects, the result was about the same: roughly a 13x speedup.

What was measured

For each project, I built the vector store twice, holding the work identical and changing only whether the GPU was used:

• Same corpus per project, the same chunk size, and the same embedding model on both runs.
• Identical output: the chunk count matched between the CPU and GPU runs, confirming both did the same work (8888 chunks for the editorial guide, 6137 for the packaging guide).

A note on method: the two projects were measured slightly differently. For the editorial guide, both runs were on the GPU instance, with the GPU enabled for one and disabled for the other. For the packaging guide, the CPU run was on a local laptop, and the GPU run on the instance. So the packaging comparison is across two machines rather than one machine toggled. Either way, the question is the same: how much does proper GPU hardware speed up the build? The answer was consistent across both.

The result

Editorial guide assistant

Packaging guide assistant

Why the GPU helps here

The slow part of these builds is embedding: turning each text chunk into a vector. That is a large number of small, similar matrix operations, exactly the kind of work a GPU does in parallel. On the CPU, the chunks are processed with far less parallelism, so the same work takes much longer. During the packaging build, I could watch the card working: utilization rose to around 64%, and power draw climbed from about 10 W at idle to roughly 120 W.

One thing worth knowing

Installing the GPU drivers was not enough on its own. The pipeline runs inside a container, and at first the container could not see the GPU, so it quietly fell back to the CPU. The fix was to configure GPU passthrough for the container runtime (generating a CDI configuration). Once that was in place, the same command used the GPU with no other changes. It is an easy step to miss, because nothing fails; the build just runs slowly.

See it in action

Want to watch the packaging assistant actually run? Here's a full walkthrough of the pipeline, from staging the corpus to reviewing a spec file:

https://gtfrans2re.fedorapeople.org/videos/packaging-guide-ramalama.mp4

Takeaway

For builds that happen often during development, cutting the editorial build from over an hour to under six minutes, and the packaging build from nineteen minutes to ninety seconds, changes how you work. You can rebuild the vector store as part of a normal iteration loop instead of planning around a long wait, and it makes larger corpora and larger models practical to experiment with, which is where the projects go next.

What the GPU let us explore: larger models

Fast builds were not the end of the story. Because the GPU made a full rebuild cheap, we could do something that would have been impractical on CPU: try a range of model sizes and see how each one actually behaves against the guidelines. We tested five models on both projects, keeping to the same model families for a fair comparison, plus one from a third family: Granite 3B and 8B, Gemma E4B and 12B, and a 14B Qwen model.

A note on model versions: Model family alone does not tell the whole story; the generation matters too. The models here were granite-4.0-micro (3B) and granite-3.3 (8B), gemma-4 (E4B and 12B), and Qwen2.5 (14B). Worth keeping in mind: Qwen2.5 was released about two years before the others, and model quality has moved quickly in that time. So the 14B's weaker showing is not simply a case of "bigger is worse", it may also reflect its older generation. Newer small models often outperform older larger ones, which is part of why a mid-sized, current-generation model came out ahead here.

The question was grounding: does a bigger model do a better job of answering from the retrieved guidelines, rather than falling back on what it happened to learn during training? The answer turned out to be more interesting than a simple yes.

Retrieval carries the small models further than expected. For facts that live directly in the guidelines, like the exact SPDX license identifiers a package must use (MIT, GPL-2.0-only, Apache-2.0), every model got them right, including the smallest 3B. The retrieval step did the work, so size did not matter there.

Where size and quality showed up. The differences appeared on harder questions. Asked whether a spec file still needs a %clean section (it does not, under current guidelines), the two Granite models gave the outdated answer they had seen often in training, while the Gemma and Qwen models correctly said it is no longer required. On the editorial side, the small Gemma E4B actually refused to answer from the guidelines, replying that it did not have access to them, even though they were right there in its retrieval corpus.

Bigger is not automatically better. The clearest example: asked how to format the Release field in a spec file, the 14B Qwen model confidently invented a macro that does not exist, %{?asparagus:.ASPARAGUS}. It sounded authoritative and was entirely made up. The 12B Gemma model, by contrast, gave clean, decisive, grounded answers on both projects and comfortably fit the GPU with room to spare. It was the sweet spot: better grounded than the smaller models, and more reliable than the larger one.

The takeaway on models: RAG grounding works, but the model still matters. It decides whether the retrieved guidelines actually get used, or get overridden by training habits or confabulation. For these two projects, a mid-sized model was the best balance of grounding quality and hardware fit, and none of this comparison would have been practical to run without the GPU.

Written as part of my Outreachy internship with the Fedora Project. GPU hardware: an NVIDIA A10G (24 GB) instance running Fedora Linux 44. Packaging CPU baseline: local laptop [CPU: AMD EPYC 7R32, RAM: 32 GB].

01 Sep 2026 4:11pm GMT

Once again, GNOME is considering participating in the Outreachy internship program. Outreachy provides internships to people subject to systemic bias and impacted by under-representation in the tech industry where they live.

Outreachy internships are funded by the participating communities. While the GNOME Foundation has not yet finalized the budget for this cohort, having a strong list of proposed projects and available mentors helps the Board decide how many slots to fund.

Project ideas will be selected based on available funding and their relevance to the overall goals of the GNOME project. Project selection will be handled by Matthias Clasen, Allan Day, and Sri Ramkrishna.

If you are a GNOME developer/maintainer available for mentoring between December 2026 and March 2027, please submit a project proposal at gitlab.gnome.org/Teams/internship/project-ideas as soon as possible (by September 11).

If you have any questions, you can contact the Internship Committee on Matrix or ask on Discourse.

01 Sep 2026 12:59pm GMT

It's hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you're done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you're not planning to disclose the issue report within the next few months, it should probably already already be public.

For GNOME, I disclose issues whenever a merge request has been created or a fix lands in the git repo, or 30 days after the issue was reported, whichever comes first. Your project might prefer to wait until the fix is released before disclosing, especially if you fear that a vulnerability might actually be exploited during the window between the fix and release. Whatever you choose, please don't forget about it and leave the issue report confidential forever. That's not fair to your project's users. Even if not many people will take the time to look, users should at least have a chance to see reported issues.

31 Aug 2026 7:21pm GMT

31 Aug 2026 5:20pm GMT

For a while now, the fingerprint management UI in GNOME Settings (gnome-control-center) has felt outdated. While it worked, the layout and enrollment flow hadn't kept up with the rest of GNOME's modern interface updates.

I am happy that during the GNOME 51 development cycle we managed to address that. Allan Day, Marco Trevisan, and myself worked on modernizing the interface. There's still more work to do in the UI and in fprintd, but what we will ship in 51 is already a great step forward.

Historically, the fingerprint dialog in User Settings was stuck on a GTK3-style design. Even after being ported to GTK4, conceptually it remained unchanged. Beyond looking out of place alongside Libadwaita-based settings panels, it suffered from responsiveness and accessibility issues that made it difficult for some users to enroll their prints.

The new fingerprint management dialog uses a standard boxed list displaying your enrolled fingers. From here, each enrolled finger can be removed individually.

Clicking the "Add Fingerprint" button starts the finger enrollment process. First, you choose one of the unused finger options to enroll. From there, an assistant guides you through the scanning process. As you place your finger on the reader, the UI detects the touch and provides feedback on whether it was read correctly. You continue touching the reader until enough samples have been collected (the exact number depends on your reader's driver). Once the progress bar fills, your finger is ready for authentication.

This is only one of the improvements that GNOME 51 is bringing. As with everything in GNOME, we will continue gathering user feedback and making iterations over time. There are already more fingerprint features in the pipeline, such as renaming enrolled fingers and verifying individual prints. Stay tuned!

31 Aug 2026 9:57am GMT

Across the various Fedora groups, the primary focus is the progression of the Fedora 45 release, with teams actively navigating the Beta freeze, conducting Blocker Review meetings, and completing QA and feature testing. Concurrently, significant infrastructure and tooling transitions are a shared priority; multiple groups are gathering workflow requirements for an upcoming Red Hat Bugzilla replacement, finalizing the migration from the newly retired Pagure.io to the Forgejo-based Fedora Forge, and integrating modern build systems like Konflux. Package maintenance and policy refinement also dominate daily operations, characterized by widespread updates to packaging guidelines across ecosystems (including Python, NodeJS, and cryptography), coordinated responses to security advisories (notably RUSTSEC vulnerabilities), and the mass-orphaning of inactive packages. Finally, strategic structural alignments represent a common operational thread, highlighted by the EPEL 10 mass branching and repository restructuring, as well as ongoing proposals to unify CoreOS with Bootc technologies.

Announcements

Critical deadlines have arrived for Fedora 45 contributors: the "Complete" deadline for F45 Changes requires all tracker bugs to be updated to ON_QA, coinciding with the Fedora 45 Beta freeze, Bodhi updates-testing enablement, and Software String freeze. Additionally, contributors must meet a September 1 deadline to submit bug tracker workflows to help identify a replacement for Red Hat Bugzilla as its maintenance winds down. On the community engagement front, the Fedora Badges application has been completely revamped with a modern, fast single-page interface, and content creators can now utilize editorial-guide-ramalama, a new RAG-based local AI assistant designed to verify article drafts against Fedora's editorial guidelines before submission.

For the broader Linux community, several new technical guides have been published. Users can learn how to monitor drive health using Performance Co-Pilot (PCP) to catch subtle warnings of SSD or NVMe failure before data loss occurs. Those interested in local AI development can explore a guide on running Ollama locally with Podman to keep host systems clean and isolated, as well as a tutorial on how to safely sandbox AI coding agents using microVMs to prevent unauthorized automated access to production clusters or local work environments.

Council

The Fedora Council met to discuss the Fedora Forge Usage Policy and the proposed Innovation Lifecycle (Sandbox). The Council achieved consensus on the Forge Usage Policy, clarifying CI resource access for spins and remixes, and establishing a notification-only process for new remixes.

Additionally, extensive debate took place regarding the level of early technical oversight required for the Innovation Sandbox, prompting the scheduling of a dedicated follow-up workshop.

Decisions

• The Fedora Forge Usage Policy will be updated for version 5 to explicitly state that spins and remixes are permitted CI resources. Requests for infrastructure resources for new remixes must CC a Council member for visibility, but formal Council approval is not required.
• The Fedora Forge Usage Policy will remain open for one final week of feedback; if there are no further edits, it will proceed to an official Council vote.
• The Council will hold a dedicated, public video call on Thursday, September 3, 2026, at 14:00 UTC+1 to workshop the Innovation Lifecycle Proposal to resolve ongoing debates about FESCo's involvement.

See the detailed report for the Council team.

Learn more about the Council team.

FESCo

During this week, FESCo held a meeting to discuss ongoing system transitions and policy updates, including the rollout of 2FA for provenpackagers, the handling of binary executable content in node_modules, and the timeline for gathering requirements for Fedora's upcoming Bugzilla replacement. The committee also finalized a major policy change regarding where Fedora Changes discussions will take place moving forward.

In ticketing and forum activity, FESCo formally approved the use of AWS-LC for cryptography in Rust packages, bringing clarity to package maintainers struggling with the ring crate. Additionally, several non-responsive maintainer tickets were processed, resulting in package handovers and the mass-orphaning of inactive maintainers' packages, while a draft for Crystal packaging guidelines was submitted for community review.

Decisions

• Approved the F46 Change: Changes Discussion Only On Devel List, making it effective immediately. Discussions regarding Changes will now happen solely on the devel mailing list and will no longer be simultaneously discussed on Discourse.
• Approved the inclusion and use of the aws-lc-sys and aws-lc-rs crates for cryptography in Fedora to replace the ring crate wherever possible, via Ticket #3679. This exception will be documented in the Packaging Guidelines.
• Agreed to close the re-review of the F45 Change: RelocateRpmRepoConfigsToUsr, as major known issues affecting rpm-ostree, anaconda, and container composes have been resolved or mitigated.
• Approved extending the deadline for gathering Bugzilla replacement requirements to September 4th to accommodate additional feedback from teams, as discussed in Ticket #3664.
• Approved mass-orphaning of packages for non-responsive maintainers cleber (Ticket #3659) and gui1ty (slated for Sep 4 per Ticket #3678), while approving the handover of packages for benzea (Ticket #3672) and prarit (Ticket #3665).

See the detailed report for the FESCo team.

Learn more about the FESCo team.

Packaging Committee

This week, the Packaging Committee's activity focused on updating and clarifying packaging guidelines across various ecosystems to prevent contributor confusion and accommodate structural changes. A new ticket was opened to document an exception for limited aws-lc use within the system-wide CryptoPolicies.

In the NodeJS ecosystem, new guidelines for using different nodejs versions have been finalized to detail how packaged streams should be utilized after the upcoming metapackage change. Additionally, the Python packaging guidelines are being revised to explicitly state that using %pyproject_buildrequires automatically satisfies the mandatory python3-devel build requirement, making redundant declarations unnecessary.

Decisions

• Consensus was reached to update the Python build requirements guidelines to explicitly clarify that utilizing %pyproject_buildrequires automatically fulfills the mandatory python3-devel dependency.
• The proposed guidelines for using different nodejs versions were marked as ready to merge after incorporating guidance on handling runtime dependencies and shebangs.

See the detailed report for the Packaging Committee team.

Learn more about the Packaging Committee team.

Mindshare

This week, Mindshare focused heavily on in-person event representation, travel funding, and committee governance. The core theme connecting the active tickets is establishing a strong physical Fedora presence at regional open source conferences and ensuring proper internal representation on the Fedora Council.

The committee received two new travel support requests: one to record on-site Fedora Podcast episodes and present a talk at Texas Linux Fest 2026, and another to host a Fedora sub-booth alongside Red Hat India at IndiaFOSS 2026. Meanwhile, action was requested on the open Fedora Council Representative Nomination ticket to clarify earlier voting miscommunications and finally select the Mindshare liaison for the Fedora Linux 44 cycle.

See the detailed report for the Mindshare team.

Learn more about the Mindshare team.

Workstation / GNOME

The Workstation / GNOME group reviewed progress on several upstream and integration initiatives this week. Key topics included resolving recent bug-reporting friction with the Showtime project, acknowledging the failure of the current Flatpak strategy regarding Flathub integration, and discussions around Bazaar as a potential GNOME Software replacement.

Additionally, community members provided updates on restoring Google Drive integration for GNOME, noting that testing is temporarily delayed while developers adapt to recent upstream changes. Preparations are also underway for the Fedora 45 Blocker Review meetings, with a call for asynchronous QA voting.

Decisions

• The working group confirmed that the effort to filter the Fedora Flatpak repository remains formally blocked by the pending GNOME Software redesign, per the meeting summary.
• It was decided that the integration of the Bazaar app store requires a new contributor to take over the review process, as the original contributor is no longer responding.
• Neal Gompa will review the ticket regarding the replacement of xvfb-run with wl-headless-run for GNOME packages and close it if no further action is required.
• Allan Day will chair the next working group meeting, with Matthias Clasen serving as secretary.

See the detailed report for the Workstation / GNOME team.

Learn more about the Workstation / GNOME team.

KDE

KDE Gear 26.08.0 is now available for testing on Fedora 44 and newer. While a minor bug regarding missing icons in Dolphin's "Details" mode was identified, an upstream patch has already been secured for the forthcoming 26.08.1 release. Additionally, the Fedora QA team has scheduled an upcoming Fedora 45 Blocker Review meeting to address proposed blockers and freeze exceptions for the upcoming Beta and Final releases.

See the detailed report for the KDE team.

Learn more about the KDE team.

Server

The Server group met on August 26 to discuss Fedora 45 release testing and Project Ansible support. For F45 testing, the team is actively verifying features and installations, though hardware limitations for ARM and RAID setups have caused minor bottlenecks, prompting targeted volunteer efforts. A minor, non-blocking bug regarding Kickstart was identified during the testing phase.

On the Ansible support front, the working group verified that the Wildfly role functions properly when Java 25 is configured. The team agreed that the Wildfly and post-install modules are near completion and will serve as pilot projects, with beta user testing slated to begin in two to three weeks. In addition, the Fedora QA team announced Blocker Review meetings for Fedora 45.

Decisions

• The Server working group will use the post-install and Wildfly Ansible modules as pilot projects, with beta user testing slated to begin in two to three weeks. (Meeting Log)

See the detailed report for the Server team.

Learn more about the Server team.

Infrastructure

The Fedora Infrastructure team has officially entered the Fedora 45 Beta infrastructure freeze, which will remain in place until mid-September to ensure stability for the upcoming release. In major ecosystem news, Pagure.io has been officially retired as an active platform and transitioned into a read-only static archive for historical purposes. Concurrently, the team is heavily preparing the new Forgejo instance (Fedora Forge) to take over production Dist Git duties, including provisioning storage, refining access controls, and finalizing project board support.

Ongoing maintenance focused heavily on RHEL 10 migrations, with Zabbix servers successfully upgraded and Mailman servers queued next. The team also addressed a severe spam attack on the fedora-devel mailing list by banning the offending user, cleaning the archives, and implementing new moderation headers. Finally, various monitoring improvements were discussed, including stabilizing database OOM kills and tuning OpenShift app load balancer metrics.

Decisions

• The Fedora 45 Beta infrastructure freeze is in effect from August 25 until approximately September 15. Frozen production hosts cannot be modified without sign-off from sysadmin-main or rel-eng.
• Pagure.io has been officially turned off as an active service and converted into a read-only historical archive.
• A freeze break was approved for the new-updates-sync script to ensure RHEL users receive the correct EPEL 10 epel-release-latest symlink and avoid dependency errors.
• A generic internal guest account was enabled for Zabbix to allow the Copr team to easily forward status metrics to Grafana without complex SAML authentication.
• A new FAS group, sysadmin-public-inbox, was created to manage the public-inbox OpenShift deployment.

See the detailed report for the Infrastructure team.

Learn more about the Infrastructure team.

Release Engineering

The Release Engineering team enacted the Fedora 45 Beta Freeze on August 25 and began tracking Beta release tasks. A significant amount of the week was spent navigating infrastructure hiccups, including a Koji hub DDoS that stalled builds and dropped mounts, F44 Flatpak compose timeouts, and Rawhide ostree compose failures. In a F45 mass branching retrospective, the team noted successes in automation but highlighted the need to strictly prevent massive, disruptive updates right before branching.

Meanwhile, several infrastructure requests were addressed, including the setup of a temporary empty repository for F46 OpenH264 to bypass 404 errors until binaries are published. The new fedpkg request-unretirement tool saw active testing by maintainers, revealing some quirks regarding Rawhide branch unblocking.

Decisions

• The Fedora 45 Beta Freeze went into effect on August 25.
• Blocker bugs and freeze exceptions for the Beta release were accepted, including fixes for anaconda-webui crashes, kmscon initial-setup breakage, and the inclusion of LLVM 23.
• A large batch of Fails-To-Install (FTI) packages for F45 in the NEW state were retired as per the release schedule.
• Releng will update docs and templates to firmly warn maintainers against pushing last-minute disruptive changes right before mass branching.
• binutils-2.47.50-4.fc46 and ELN equivalents were untagged due to regressions breaking Rust builds.
• An empty repo was established for F46 OpenH264 to prevent 404 errors during builds while awaiting Cisco's binary uploads.
• The coreos-pool tagging keys were updated by removing the F43 key and adding the F46 signing key.

See the detailed report for the Release Engineering team.

Learn more about the Release Engineering team.

Quality

The Quality group was highly active this week as Fedora 45 reached its Beta freeze and Bodhi enablement point. The GNOME 51 test day concluded successfully with 30 participants submitting 135 test results. Early manual validation testing for Fedora 45 was also completed, uncovering multiple bugs across different architectures.

Additionally, the team evaluated proposed blockers in their Beta blocker review meeting, deciding on key anaconda-webui and kmscon bugs. The group is also urgently compiling requirements for the upcoming Red Hat Bugzilla replacement system, which are due by September 1st.

Decisions

• Accepted Fedora 45 Beta Blockers for an anaconda-webui review screen crash (Bug 2519654) and a kmscon bug that breaks console initial-setup on ARM minimal (Bug 2484542).
• Accepted Fedora 45 Beta Freeze Exceptions to pull LLVM 23 into Fedora 45 (Bug 2506941), to address missing obsolete packages for Python 3.14 (Bug 2492124), and to fix an anaconda-webui dependency issue preventing soas livespin creation (Bug 2517903).
• Declared User switching restart failure as an Accepted Final Blocker, but rejected it as a Beta Blocker (Bug 2501857).

See the detailed report for the Quality team.

Learn more about the Quality team.

Design

This week, the Design team saw continued progress on graphic design requests and repository maintenance, though some coordination activities were paused due to Madeline being on PTO. New artwork was submitted for the EPEL Steering Committee badge, and the migration of historical repositories to the new Forge organization was reviewed.

See the detailed report for the Design team.

Learn more about the Design team.

Docs

This week, the Fedora Docs team held a meeting to discuss ongoing projects, including the frontpage redesign and proposed updates to the Release Notes process. A major milestone was reached with the merging of a long-standing pull request that restructures the team documentation, successfully splitting the Docs Contributors Guide into its own module for better visibility.

Additionally, the team evaluated ticket activity, opening a new discussion on archiving or removing End-of-Life (EOL) distribution pages and processing a membership request. The team is actively seeking community input on the frontpage redesign and continues to request help with manual wiki migrations.

Decisions

• The Release Notes process will be updated to include clear documentation questions in the Fedora Change template, which will directly affect all Fedora Change owners. (Meeting Log)
• The Docs Contributors Guide has been moved into a separate module to allow placement on the Docs landing page, finalizing the team documentation restructuring. (Issue #55)
• Docs group membership requests will be denied unless the applicant has already made demonstrable contributions to repositories within the Docs organization on Forge. (Issue #60)

See the detailed report for the Docs team.

Learn more about the Docs team.

Internationalization

The Internationalization group focused on optimizing translation resources and streamlining issue tracking. Key discussions included centralizing the issue tracker for localization-docs repositories by redirecting them via API to the main localization tracker, and removing archived documentation (sysadmin and install guides) from Weblate to save resources.

Additionally, the team fielded requests regarding unsupported Fedora releases and an upstream KDE translation error. Both were closed and redirected to the appropriate channels (Fedora Docs and the upstream KDE translation team, respectively), clarifying the scope of the Fedora localization team's responsibilities.

Decisions

• Archived and unpublished documentation (Sysadmin Guide and Install Guide) will be removed from Weblate to free up resources, while keeping their underlying Git repositories.
• Unsupported (EOL) Fedora releases will remain in Weblate as long as they are still published on Fedora Docs; requests to hide them must be directed to the Fedora Docs team.
• Translation issues for upstream projects (such as KDE Plasma Vault) are out of scope for Fedora Localization and must be reported directly to upstream translation teams.

See the detailed report for the Internationalization team.

Learn more about the Internationalization team.

EPEL

This week, the EPEL group successfully completed the EPEL 10.3 mass branching, officially shifting standard development on the epel10 branch to target the upcoming EPEL 10.4 release. Packagers wanting to build specifically for EPEL 10.3 must now request and use a dedicated epel10.3 branch. The transition went smoothly, overcoming some infrastructure adjustments required for the new "10s" repository naming scheme.

Simultaneously, the team deployed the first phase of the EPEL 10 "de-z-ification" initiative. CentOS 10 systems with the latest release package will now use the new epel-10s metalink pointing to 10.4, while RHEL changes will follow in the fall with the release of RHEL 10.3. The team also addressed a minor but impactful bug regarding symlink churn for the EPEL 10 release RPM, temporarily fixing it to prevent repository dependency errors for users.

Decisions

• Builds submitted to the default epel10 branch now target EPEL 10.4 following the completion of the EPEL 10.3 mass branching. Packagers who need to build against EPEL 10.3 specifically must request and use the epel10.3 branch.
• The first phase of the EPEL 10 "de-z-ification" proposal was put into production. CentOS 10 systems now utilize the epel-10s metalinks and paths, which redirect to the epel-10.4 repository, to prevent package dependency issues on private mirrors. Details were announced on the discussion forum.
• The MirrorManager mapping logic for EPEL 10 was adjusted to use explicit minor versions (e.g., epel-10.4) with redirects for prior minor versions, rather than keeping the existing mapping and setting up redirects for future ones. (Discussion Post)

See the detailed report for the EPEL team.

Learn more about the EPEL team.

CentOS Hyperscale

During the August 26, 2026 meeting (log), the CentOS Hyperscale SIG announced that the wprof tool has graduated from incubation and is now available in Fedora and EPEL 10. The SIG has rebased to 7.1 kernels and plans to transition to 7.2 shortly after Fedora does. In broader ecosystem news, AlmaLinux is actively considering building the Hyperscale kernel for its users, which sparked discussions on kernel signing limitations and potential expansion of Hyperscale packages into AlmaLinux's extra repositories.

The group also discussed the progression of transactional Hyperscale updates, noting that core elements have been ported to dnf5. Work is actively proceeding on packaging these components, tracked via Bugzilla issues 2521657, 2521661, and 2521666. Additionally, a KDE proposal to improve enterprise technologies was highlighted for its strong alignment with Hyperscale's system snapshot capabilities.

Decisions

• The SIG decided to retain the EPEL 9 builds of wprof in the experimental hsx repository, despite its graduation to standard repositories for Fedora and EPEL 10.
• Davide Cavalca and Neal Gompa will finalize and submit the delayed Hyperscale quarterly report this week.

Learn more about the CentOS Hyperscale team.

ELN

During the August 25, 2026 meeting, the ELN SIG focused on infrastructure, sync processes, and tooling improvements. The group discussed options for building ELN and CentOS toolbox and container images, specifically weighing whether to migrate from Kiwi to image-builder for CentOS parity or to wait for future Konflux adoption; the decision was deferred for further investigation. The team also debated how to optimize the ELN Build Sync (EBS) timeout duration to prevent buildroot breakage during high-load events like mass rebuilds, with discussions moving to the tracker.

Most significantly for the broader Fedora and Linux packaging ecosystem, the SIG reached a consensus to stop using the Rawhide GPG key for ELN. Instead, they will provision a dedicated ELN key starting with the F46/EL11 branching. This key will be rotated approximately every three years to align with RHEL branching, which should resolve the recurring signing-related disruptions that typically happen during the Fedora branching process.

Decisions

• The SIG agreed to provision a new, dedicated GPG key for ELN starting with the F46/EL11 branching, rather than continuing to use the shared Rawhide key. This key will be rotated roughly every 3 years (aligned with RHEL branchings) to avoid widespread signing-related breakages during Fedora branching. (Meeting log)

Learn more about the ELN team.

Atomic

The Fedora Atomic group successfully added base and compose images for Fedora 45 in Konflux, while actively working to resolve build failures for IoT images alongside the IoT team. Ticket discussions highlighted a strong theme around improving the bootc image derivation process, focusing on trademark compliance and filesystem structure.

Administratively, steps were taken to grant write access to new maintainers for the base-images repository on both GitLab and the Fedora Forge. Users also reported a critical bug causing emergency mode on non-BTRFS filesystems (ext4/XFS) following recent system updates, which is currently under investigation.

Decisions

• Sean Thrailkill and Hristo Marinov were formally approved for maintainer access to the base-images repository and the Fedora Forge.
• A new Fedora Account System (FAS) group will be created for maintainers to safely isolate bot permissions on the Forge.
• The IoT team will fix their Konflux image builds now that they are aware of the failures, and coordinate future strategy for CoreOS, bootc, and IoT images.
• Ticket #125 will strictly track logos, release, and release notes packages for derived builds, with a separate ticket (#126) opened to track the /usr/local and /opt symlink issues.

See the detailed report for the Atomic team.

Learn more about the Atomic team.

CoreOS

During the week of August 24-30, 2026, the CoreOS group held one meeting to review pending action items, coordinate around the Fedora 45 (F45) release schedule, and discuss a major proposal to unify CoreOS and Image Mode/Bootc. Key discussions revolved around navigating the F45 beta freeze to implement zram/oomd enablement, and scheduling the F45 Test Day for September 21st.

The team had a highly positive initial reaction to the Bootc unification proposal, viewing it as a natural progression that could reduce duplication of effort across Fedora variants. This initiative will be proposed to the Bootc community next week to evaluate feasibility and alignment.

Decisions

• Tentatively scheduled the Fedora CoreOS 45 Test Day for 2026-09-21 (tracked in CoreOS #934).
• Agreed to prioritize completing the zram/oomd implementation for F45 and address any beta freeze exceptions afterward if necessary.

See the detailed report for the CoreOS team.

Learn more about the CoreOS team.

ARM

This week, the ARM group primarily discussed hardware compatibility and upcoming release blockers. A user reported a kernel error when attempting to boot an older Fedora 43 installation on a Raspberry Pi 5 Model B Rev 1.1. The issue was bypassed by upgrading to a Fedora 44 image, prompting maintainers to close the inquiry since Fedora 43 is no longer a focus.

Additionally, QA announced the upcoming Fedora 45 Blocker Review Meeting scheduled for August 31, 2026. Community members were invited to participate in the triage of proposed blockers and freeze exceptions for the Beta and Final releases.

Decisions

• Maintainers will not investigate or support boot issues specific to Fedora 43 on newer hardware revisions (like the Raspberry Pi 5 Rev 1.1), as development focus has shifted to Fedora 44 and newer.

See the detailed report for the ARM team.

Learn more about the ARM team.

Hummingbird

This week, an update was shared in the Hummingbird Community Meeting - 20 August 2026 thread regarding a new project. Jorge Castro announced that a version of Bluefin built on Hummingbird technology is essentially finished and will serve as a full peer to Dakotaraptor. He emphasized his complete commitment and support for this variant, noting that initial code pushes to its new repository are expected shortly.

Learn more about the Hummingbird team.

AI & ML

The AI & ML group met to discuss ongoing packaging efforts and long-term goals (meeting log). Work on PyTorch 2.13 has temporarily stalled in Rawhide and Fedora 45 due to a libstdc++ update that conflicts with ROCm, causing build breaks. Meanwhile, ROCm 10.0 (previously referred to as ROCm 8) was released on August 26. This major upgrade marks a shift in AMD's release pace and support model. The group is currently evaluating potential ABI breakage, though efforts are slightly hampered by libabigail crashing on debuginfo packages.

The group also explored the feasibility of shipping "open weights" AI models (like Nvidia's Nemotron 3 or AMD's open models) directly in Fedora. The consensus is that training or rebuilding these models from scratch within Fedora's build system (Koji) is currently unrealistic due to extreme hardware requirements (e.g., 64x MI300 GPUs) and timeouts. Doing so would require dedicated infrastructure proposals and deep-pocketed sponsors to provide heavy cloud compute resources.

Decisions

• ROCm 10.0 packages will be staged and maintained in the ROCm packagers preview COPR until basic testing is completed and the scope of ABI changes is fully quantified.

Learn more about the AI & ML team.

Security

This week, the Security SIG's primary focus was discussing a draft proposal for a new Fedora Privacy SIG, which originated from earlier conversations about maintaining the ff-disable-ai-ml package. The group debated the appropriate scope for such a SIG, noting that while security and privacy are closely related, a dedicated Privacy SIG might inadvertently attract ideological or political debates rather than technical contributions.

To address these concerns and ensure good optics-particularly to avoid appearing antagonistic toward the AI/ML SIG-the group agreed to postpone any formal launch. Instead, members will take extra time to review the RFC and intend to focus initially on concrete, ad-hoc technical work, such as packaging clear privacy config toggles for users.

Decisions

• Deferred the formal creation and announcement of the proposed Privacy SIG to allow members more time to review the draft and refine its scope.
• Agreed to focus on tangible, ad-hoc technical implementations (such as packaging user privacy toggles) to establish a technical foundation before officially spinning off a new SIG.

See the detailed report for the Security team.

Learn more about the Security team.

Go

During the Go SIG meeting, it was announced that Go 1.27.0 is now available in Rawhide. Maintainers will soon move this update into Fedora 45 and trigger a mass prebuild on COPR. The SIG is also preparing to retire Go 1.25 in Fedora 43 in favor of Go 1.26, aligning with upstream Kubernetes requirements which have dropped support for 1.25 across all supported releases.

Additionally, the team discussed a new method for handling security vulnerability reports. A community member modified an upstream CRI-O script to generate govulncheck output in openvex format. This script makes it much faster to verify if a package is actually affected by specific CVEs without having to run manual checks for each one. The script will be shared publicly on platforms like GitHub or Forgejo to help maintainers triage Bugzilla tickets more efficiently.

Decisions

• Move Go 1.27.0 into Fedora 45 and perform a mass prebuild on COPR.
• Open a ticket to retire Go 1.25 in Fedora 43 and transition to Go 1.26 to support recent Kubernetes releases.

Learn more about the Go team.

Perl

This week's activity on the Perl mailing list consisted entirely of package maintenance pull request notifications from Michal Josef Špaček. Key updates centered around the perl-DBD-ODBC package, which was re-submitted for Fedora review, updated with a new EPEL10 package, and received miscellaneous updates. Additionally, the perl-Archive-Extract package received version 0.90 version bumps across multiple branches.

Decisions

• The perl-DBD-ODBC package was re-submitted for Fedora review and merged.
• An EPEL10 package was created and merged for perl-DBD-ODBC.
• The perl-Archive-Extract package was bumped to version 0.90 across several pull requests.

Learn more about the Perl team.

Python

This week, the Python group discussed the behavior of %pyproject_patch_dependency when packaging multiple Python distribution packages in a single specfile. They agreed that its current behavior-filtering dependencies from all distributions-is sensible for most use cases but needs to be properly documented. An option to filter by a specific distribution name might be considered in the future.

In addition, flit-core has been updated to version 4. A deprecated compatibility package, python3-flit-core3, was introduced for packages that still require older versions. However, maintainers are expected to eventually migrate their packages to flit-core 4+.

Decisions

• Maintain the current behavior of %pyproject_patch_dependency (filtering from all dists) when multiple distributions are present, but document it properly.
• Update flit-core to version 4 and provide a deprecated python3-flit-core3 compatibility package for packages that have not yet migrated, with the expectation that all packages will eventually migrate to flit-core 4+.

Learn more about the Python team.

Rust

This week, the Rust group focused heavily on addressing various RUSTSEC security advisories and dealing with unmaintained crates across the ecosystem. Significant efforts were directed toward updating critical dependencies, notably the lru and git2 crates, to mitigate vulnerabilities, alongside planning migrations away from archived crates with unfixed soundness issues like smartstring, bitmaps, sized-chunks, and im-rc.

A major theme of the week was coordinating package updates and rebuilds gracefully. Because of the large number of dependent packages in the Fedora ecosystem, temporary compatibility packages are being introduced (such as for git2), and the group finalized a strategy for handling security rebuilds for affected packages they do not directly co-maintain, prioritizing cross-team communication over unilateral action.

Decisions

• Rather than invoking provenpackager privileges to force rebuilds of applications affected by the cxx RUSTSEC advisory, the group will file targeted bugs against the applications, linking the advisory and advising maintainers to simply rebuild their packages (Issue #36).
• A temporary rust-git2_0.20 compatibility package will be added to the repositories to prevent breaking a large number of dependent packages while they are being ported to git2 v0.21.0 (Issue #30).
• The group will wait until lru v0.18 is available in the repositories before attempting to patch the bounds for dependent packages like pydantic (Issue #39).

See the detailed report for the Rust team.

Learn more about the Rust team.

Other Discussions

• Michael Scherer initiated a discussion on Dynamic users with sysusers and bootc/image mode, noting that sysusers.d in image mode can cause UID mismatches on upgrades, and proposed amending packaging guidelines to pair it with a tmpfiles.d fragment to properly chown files in /var.
• Mattia Verga posted the latest report on Inactive packagers for the F45 release cycle, prompting a request from Miroslav Suchý to include plain text lists of usernames directly in the email rather than relying solely on the ticket tracker links.
• Norbert Manthey proposed to Extend default compiler settings to harden applications by adding flags like -fno-strict-overflow and -ftrivial-auto-var-init=zero. Daniel P. Berrangé noted that while the latter eliminates vulnerabilities, it can cause non-trivial performance degradation (e.g., 9% in virtio-blk) that maintainers must address.
• SY Wang raised an issue regarding No response from the main admin on a libxsmm pull request open for two months. Other users noted similar issues and advised following the formal nonresponsive maintainer policy via Bugzilla.
• Tobias Girstmair asked for advice on Questions on packaging vim-classic so it can coexist with standard vim. Maxwell G and Simon de Vlieger suggested starting with renamed or suffixed binaries rather than using the alternatives system.
• Aoife Moloney announced a DEADLINE: Please Submit your Bug Tracker Workflows by Sept 1, 2026 to collect workflow requirements for an eventual Red Hat Bugzilla replacement, though the tight deadline was questioned by Quality team members.
• Chihurumnaya Ibiam reported a FTBFS/FTI Page Not Found issue in an auto-generated comment link, which Miro Hrončok promptly fixed while reminding contributors to report tooling issues directly to the releng ticket tracker.
• Henryk Paluch noted that the Package Sponsorship page points to decommissioned pagure.io, and was directed to the new Fedora Forge tracker and an open pull request designed to fix the documentation.
• Kevin Fenzi confirmed the spam wave is over, stating that the spammers were banned, the archives cleaned, and new header rules were added to block similar messages.
• Orion Poplawski posted Help wanted with ansible mysql/mariadb collections, seeking a new maintainer for ansible.mysql as they are migrating to ansible.mariadb; Andreas Haupt volunteered to take it over.
• Other discussions included an announcement of the upcoming F45 Blocker Review Meeting, and two PRs from Bojan Smojver to address a Failed F44 Flatpak compose holding back updates.

Package updates

• Dominik 'Rathann' Mierzejewski announced an [SONAME BUMP] ffmpeg upgrade from 8.1 to 9.0 for Rawhide and F45, successfully rebuilding all dependents in a COPR with minimal issues.
• Milan Crha noted the target for libical 4.0 for rawhide is now Fedora Linux 46 due to its incompatibility with the 3.x series API.
• Gwyn Ciesla announced an Upcoming gumbo-parser soname bump to version 0.14.0 in Rawhide, noting dependent packages have built fine in a side tag.
• Christoph Erhardt warned about a SONAME bump in Rawhide: mimalloc 3.5.0, which will require pull requests for dependent packages like moarvm, mold, and rakudo.
• Milan Crha organized a GNOME 51.rc update for rawhide and f45, creating side tags (f46-build-side-149189 and f45-build-side-149193) for maintainers to group their package builds.
• Milan Crha shared a heads-up that gnome-autoar 0.5.0 drops gnome-autoar-gtk in rawhide, and plans to push it to F45 if there are no undetected users.

Orphaning packages

• Peter Hutterer is Orphaning evtest, evemu and some X11 utilities (sessreg, x11perf, etc.), noting that evtest functionality has been superseded by libinput record.
• The automated Orphaned packages looking for new maintainers report highlighted a massive list of unmaintained packages; in response, Henryk Paluch volunteered for python-aexpect and Ben Beasley adopted several Rust crates (rust-find-crate, rust-hidapi, rust-tinystr).
• Benson Muite is Orphaning python-proton-vpn-api-core because tracking its new native Rust extensions and submodule dependencies is too time-consuming.

New contributor introductions

• Charles Haithcock introduced himself as a former RHEL kernel troubleshooter who is now working on Fedora kernel bugs and hopes to become more entrenched in the community.
• Bri Mo introduced himself as an applied AI/ML engineer and OSINT enthusiast running Silverblue 44 and container-first workflows with Podman.

Contribution opportunities

Testing and Quality Assurance: Community members looking for highly accessible ways to contribute can help streamline the release process by voting on proposed blocker bugs and freeze exceptions using the blockerbugs app (requested by Workstation/GNOME, KDE, Server, Release Engineering, and ARM). Testers are also needed to evaluate Google Drive integration in GNOME, the KDE Gear 26.08.0 release, ROCm 10.0 packages, and transactional updates. More involved QA tasks include investigating Atomic Desktop boot failures on non-BTRFS systems, benchmarking tuned-ppd performance, and writing test cases for upcoming Anaconda test days or CoreOS testing events.

Design, Documentation, and Community Governance: Non-developers can make significant impacts by shaping project identity, documentation, and policies. Designers are invited to create an avatar for the Matrix Moderation Bot or submit artwork for the upcoming Fedora 46 Wallpaper call. Documentation volunteers can guide the Docs frontpage redesign (Issue #6, Issue #52), assist with Wiki cleanup (Issue #43), and modernize the Request for Resources process. Contributors are also encouraged to review and provide feedback on the Fedora Forge Usage Policy, the Innovation Lifecycle Proposal, Draft Crystal Packaging Guidelines, the Privacy SIG RFC, and the CoreOS Unification proposal. Additionally, bilingual users can report translation errors directly to upstream translation teams.

Programming and Scripting: Software developers have opportunities to write automation tools and patch ecosystems. Scripting tasks include using the Forgejo API to redirect localization issue trackers, building tools to adjust NodeJS shebangs, and creating a programmatic fix for EPEL 10 symlink churn. UI/UX developers can tackle low-hanging fruit by adding a power-off option to the GNOME initial setup screen, building system snapshot integrations aligned with KDE's enterprise goals, or developing user-facing privacy toggles. Rust developers are urgently needed for security auditing and migrating Fedora packages away from unmaintained crates like smartstring (Issue #38) and updating git2 dependents.

Packaging, Infrastructure, and Sysadmin: Contributors with packaging and system administration skills are highly sought after to adopt orphaned packages resulting from unresponsive maintainers, including PackageKit-Qt5, ansible.mysql, and Python utilities (sponsorship is available for adopters of packages like python-aexpect). Python packagers can also assist by migrating spec files to flit-core v4+. Infrastructure volunteers can help prepare for RHEL 10 by building missing EPEL packages needed to migrate Mailman servers, fix Ansible inventory macros, and update the Koji theme footer URI. Furthermore, packaging contributors can help create generic Fedora remix assets to ease trademark compliance for derived bootc builds.

31 Aug 2026 8:33am GMT

Time for another saturday weekly recap in longer form.

29 Aug 2026 5:53pm GMT

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

RPMs of PHP version 8.4.25 are available in the remi-modular repository for Fedora ≥ 43 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.33 and 8.3.33.

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

Version announcements:

• PHP 8.5.10 Release Annoucement
• PHP 8.4.25 Release Annoucement

ℹ️ 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.10
• Fedora 45 - PHP 8.5.10
• Fedora 44 - PHP 8.5.10
• Fedora 43 - PHP 8.4.25

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

• Migrating from PHP 8.2.x to PHP 8.3.x
• Migrating from PHP 8.3.x to PHP 8.4.x
• Migrating from PHP 8.4.x to PHP 8.5.x

Base packages (php)

Software Collections (php83 / php84 / php85)

28 Aug 2026 4:51am GMT

27 Aug 2026 10:00pm GMT

In Some Changes to GNOME Security Tracking, I reported:

I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

27 Aug 2026 2:56pm GMT

27 Aug 2026 11:02am GMT

In open source projects, we tend to grant privileges far more often than we remove them. This is understandable, but risky. First, keeping inactive people on the maintainer list means someone may go to them with a question and be frustrated when they don't get an answer. More importantly, it presents a security risk. Compromised accounts remain a common attack vector, and it's much easier to escape notice if the account owner isn't using the account. It behooves the project to keep the maintainer (or other privileged role) list tidy.

There are a few reasons that trimming the maintainer list doesn't happen. First, it's boring, tedious work. Who wants to do that? Second, it's complicated work. What does it mean to be "inactive"? Third, it can lead to hurt feelings. People who earn privileges absorb that role into their identity and they don't want to let it go. This is a case where the perfect quickly becomes the enemy of the good (or okay-ish). Let's look at each of the reasons in turn.

Overcoming the objections

Project and community management tasks often end up on the "avoid: no fun" pile. They only seem like no fun because they are. But "fun" and "important for the project" aren't the same. Changing the air filter in my furnace isn't fun, but it's important for the health and safety of my family. Ideally, the inactive maintainer process is automated and runs regularly, but building that automation takes work. So if you go through the list and identify inactive maintainers once or twice a year, that's better than nothing.

"Inactive" can mean a lot of things. Does one activity in a six month period count? Does the activity have to be "sustained"? You can define it in the way that's most convenient to you. The goal isn't to be rigorous and precise, it's just some spring cleaning. You can start by just asking yourself "have I seen So-and-so around lately?" If the answer is "yes", then they're active. Again, it would be nice if you could automate it. You don't need to wait for that.

The feelings objection is the hardest one. We're all friends here and we don't want to hurt our friends' feelings. Unlike the other two, you can't really half-ass this one, so you need a policy that treats people with kindness. Let's move on to that.

Creating an inactive maintainers policy

Here are some features of a good inactive maintainers policy:

• Define "inactive" unambiguously. "We will remove maintainers who have not been active in N months, where 'active' means having done X, Y, Z." Six or twelve months is probably a good place to start. Be sure to include as many activities as you can reasonably determine. Think about what's important to keep that status: commits, issues opened/closed/commented/reviewed, pull requests, mailing list posts, and so on.
• Define "inactive" generously. For the most part, the bigger concern is "is this person still in control of their account?" not "is this person earning enough points to keep their privileges?" So if someone's activity isn't what you'd want for them to initially earn maintainer status, that's probably okay.
• Check for inactive maintainers at a set time. If you have calendar-based releases, check at a given point in the release cycle. Right after the release is a good starting point.
• Automate what you can. The time spent really does pay off pretty quickly. Fedora is a large and complicated project, so evaluating activity requires checking half a dozen services. Mattia Verga wrote a script that handles the checks and creates issues in a repo to track the inactive packagers.
• Don't remove anyone without notice. This is a big part of the "don't hurt your friends' feelings" requirement. Give people a chance to respond. Some will respond by being more active. Some will respond by saying "yeah, I no longer have the time and/or interest, so go ahead and drop me." Some won't respond at all. If someone wants to remain, let them.
• Conspicuously acknowledge the people you're removing. Add people as a "maintainer emeritus". Mention them in a blog post, release notes, or other vehicle for public praise.
• Allow easy reinstatement. If someone lapses and later wants to return, let them. Don't make them go through the whole process again. It's much easier to let a role go if you know you can easily get it back later.
• Leave some privileges for people on emeritus status. Keeping their name on a list of historical maintainers, letting them keep a project email address, giving them voting privileges on certain issues, and other privileges will help people who are inactive still feel valued in the project.

It will take a few tries to get the policy just right. Don't be afraid to try it.

This post's featured photo by Jan Canty on Unsplash.

The post Removing inactive maintainers appeared first on Duck Alignment Academy.

26 Aug 2026 12:00pm GMT

26 Aug 2026 5:30am GMT

#
# https://github.com/rosset/myconfig/tree/master/brother-t420w-2026
#

                         ┌───────────────────────┐
                         │   Brother DCP-T420W                          │
                         │  (final architecture)                              │
                         │   IPP / PWG-Raster                                │
                         └──────────▲────────────┘
                                                         │
                         ┌──────────┴───────────┐
                         │      Network / IPP    │
                         └──────────▲───────────┘
                                                         │
              ┌─────────────────────┴─────────────────────┐
              │                                           │
    Linux / Raspberry Pi 5                         macOS 27 Golden Gate
        aarch64                                                            IPP Everywhere
              │                                                                                     │
        CUPS + PPD                                                                    CUPS
              │                                                                                     │
      br-box64-filter                                                           driver=everywhere
              │
            box64
              │
    Brother x86_64 filter
              │
       HBP / PWG-Raster
              │
              └───────────────────────► Printer

# Linux
# Printer Brother_T420W running with Linux (aarch64) + box64 + cups filter + modified ppd
# Status: working

=> uncompress opt-brother.tar.gz to /opt - final path = /opt/brother

=> copy /opt/brother/br-box64-filter to /usr/lib/cups/filter/br-box64-filter
    * make sure it is executable: chmod +x /usr/lib/cups/filter/br-box64-filter
    * this filter is a wrapper for the Brother LPD filter, which is a x86_64 binary
    * it uses box64 to run the x86_64 binary on aarch64 (rpi5 in my case)
    * if you try to use ./lpd/x86_64/brdcpt420wfilter directly, it will fail with "wrong architecture" error
    * DietPi v10.6.2 (Debian 13.6) + [BOX64] Box64 with Dynarec v0.3.4 nogit built on Apr 24 2025 09:54:47
    * the "key" thing is to keep the A4 Geometry: 2480x3508 (some wrappers are changing it to 2480x3507, which is wrong)
    
=> key files under /opt/brother:
    - /opt/brother/Printers/dcpt420w/inf/brdcpt420wrc
        -changed PageSize=Letter to PageSize=A4

    - /opt/brother/Printers/dcpt420w/cupswrapper/brother_dcpt420w_printer_en.ppd
        - changed from *cupsFilter: "application/vnd.cups-postscript 0 brother_lpdwrapper_dcpt420w"
            - to.      *cupsFilter: "application/pdf 0 br-box64-filter"

    - copy /opt/brother/Printers/dcpt420w/cupswrapper/brother_dcpt420w_printer_en.ppd
        to /etc/cups/ppd/Brother_T420W.ppd
    
    - finally add the printer:
        lpadmin -p Brother_T420W -E -v ipp://printer-IP:631/ipp/print -P /etc/cups/ppd/Brother_T420W.ppd


# V2 => Easiest path for Linux aarch64, avoid use of box64 and Brother
# x86_64 filter, use IPP (no everywhere) driverless printing instead
#
# Brother_T420W - V1
#    → Brother proprietary LPD + box64
#    → maximum Brother specific compatibility

# Brother_T420W_IPP - V2
#    → native CUPS driverless
#    → PWG Raster over IPP
#    → no x86_64 emulation

driverless \
    ipp://printer-IP:631/ipp/print \
    > /tmp/brother-ipp/dcp-t420w.ppd

sed -i 's/\*DefaultPageSize: Letter/*DefaultPageSize: A4/' \
    /tmp/brother-ipp/dcp-t420w.ppd

lpadmin \
    -p Brother_T420W_IPP \
    -E \
    -v ipp://printer-IP:631/ipp/print \
    -P /tmp/brother-ipp/dcp-t420w.ppd

cupsenable Brother_T420W_IPP
cupsaccept Brother_T420W_IPP

lpstat -v
lpstat -p Brother_T420W_IPP -l

# macOS 27 Golden Gate
# Printer Brother_T420W with CUPS + IPP Everywhere
# Kind: DCP-T420W - IPP Everywhere
# Driver version: 2.3
# Status: working

lpadmin -p Brother_T420W -E -v "ipp://printer-IP/ipp/print" -m everywhere

26 Aug 2026 3:43am GMT