A short one this week. The management reading list gave me some new ideas and the interview with Mr. T is great.
Good Culture is the Biggest Productivity Hack, Not AI - It relates to the quote above.
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.
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.
Recently, I heard complaints within the syslog-ng community that using Elasticsearch is not that easy anymore. I installed Elasticsearch 9.5 with Kibana to verify these claims.
Read more at https://www.syslog-ng.com/community/b/blog/posts/using-syslog-ng-with-elasticsearch-9-5
gtfrans2re )
on 2026-09-01 16:11:34 UTC
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.
For each project, I built the vector store twice, holding the work identical and changing only whether the GPU was used:
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.
Editorial guide assistant
Packaging guide assistant
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.
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.
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
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.
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].
feborges )
on 2026-09-01 12:59:08 UTC
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.
catanzaro )
on 2026-08-31 19:21:23 UTC
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.
u1f35c )
on 2026-08-31 17:20:15 UTC
I’ve been a Debian user since 1999, and a Debian developer since 2000. Given recent events it’s worth thinking about why that that is, and why I haven’t switched to something else in the past quarter century.
My first Linux distro was Slackware, off a CD in a book, some time in the mid 90s. After starting university I ran SUSE for a while, then moved to RedHat (both back before they had commercial variants significantly different to what was available freely). The main motivation for switching was package management; I was running a machine at home, and a machine at university. Keeping track of what was installed on each, and what versions, was getting annoying with Slackware. Most of the folk I knew were running RedHat, and I mostly played with SUSE because I’m contrary before realising it was different enough that I couldn’t easily make use of 3rd party RPMs.
I came to Debian via friends in Cambridge, who spoke highly of it. The first Debian machine I installed was fourier, the initial host for Black Cat Networks, and I never looked back.
(For additional context I should also point out I have contributed, in the distant past, to, and run, OpenWRT, OpenEmbedded, and FreeBSD.)
I’d like to try and work out what is it I get from Debian that I’d need in anything else. Originally I tried to order the requirements in some sort of priority, but it’s sometimes hard to work out what I’d drop if I had to compromise somewhere, so it’s a somewhat loose ordering.
Ultimately I don’t want to have to actively think about the Linux distribution I use. Debian has mostly given me that; I know it will generally be suitable for most environments I want to use it in (embedded situations where OpenWRT or OpenEmbedded are better choices being the exception, but that’s less frequent these days), and I can rely on getting timely security updates (thanks to all those who work on that within Debian!). I’m not sure there’s currently an alternative that would suit my needs? I’d love to hear if there’s something I should look at, even if I’m not necessary making a move just yet!
feborges )
on 2026-08-31 09:57:31 UTC
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!
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.
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.
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.
See the detailed report for the Council team.
Learn more about the Council team.
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.
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.rpm-ostree, anaconda, and container composes have been resolved or mitigated.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.
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.
%pyproject_buildrequires automatically fulfills the mandatory python3-devel dependency.See the detailed report for the Packaging Committee team.
Learn more about the Packaging Committee team.
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.
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.
xvfb-run with wl-headless-run for GNOME packages and close it if no further action is required.See the detailed report for the Workstation / GNOME team.
Learn more about the Workstation / GNOME team.
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.
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.
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.
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.
new-updates-sync script to ensure RHEL users receive the correct EPEL 10 epel-release-latest symlink and avoid dependency errors.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.
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.
binutils-2.47.50-4.fc46 and ELN equivalents were untagged due to regressions breaking Rust builds.See the detailed report for the Release Engineering team.
Learn more about the Release Engineering team.
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.
See the detailed report for the Quality team.
Learn more about the Quality team.
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.
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.
See the detailed report for the Docs team.
Learn more about the Docs team.
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.
See the detailed report for the Internationalization team.
Learn more about the Internationalization team.
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.
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.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.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.
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.
wprof in the experimental hsx repository, despite its graduation to standard repositories for Fedora and EPEL 10.Learn more about the CentOS Hyperscale team.
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.
Learn more about the ELN team.
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.
/usr/local and /opt symlink issues.See the detailed report for the Atomic team.
Learn more about the Atomic team.
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.
See the detailed report for the CoreOS team.
Learn more about the CoreOS team.
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.
See the detailed report for the ARM team.
Learn more about the ARM team.
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.
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.
Learn more about the AI & ML team.
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.
See the detailed report for the Security team.
Learn more about the Security team.
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.
Learn more about the Go team.
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.
perl-DBD-ODBC package was re-submitted for Fedora review and merged.perl-DBD-ODBC.perl-Archive-Extract package was bumped to version 0.90 across several pull requests.Learn more about the Perl team.
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+.
%pyproject_patch_dependency (filtering from all dists) when multiple distributions are present, but document it properly.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.
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.
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).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).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.
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.-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.libxsmm pull request open for two months. Other users noted similar issues and advised following the formal nonresponsive maintainer policy via Bugzilla.vim. Maxwell G and Simon de Vlieger suggested starting with renamed or suffixed binaries rather than using the alternatives system.ansible.mysql as they are migrating to ansible.mariadb; Andreas Haupt volunteered to take it over.moarvm, mold, and rakudo.f46-build-side-149189 and f45-build-side-149193) for maintainers to group their package builds.sessreg, x11perf, etc.), noting that evtest functionality has been superseded by libinput record.python-aexpect and Ben Beasley adopted several Rust crates (rust-find-crate, rust-hidapi, rust-tinystr).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.
Time for another saturday weekly recap in longer form.
Bunch more progress of various machines over the last week or two, and we are down to:
torrent01 (didn't manage to get this before beta freeze, will after)
mailman/lists ( https://forge.fedoraproject.org/infra/tickets/issues/13519 )
database servers ( https://forge.fedoraproject.org/infra/tickets/issues/13517 )
rabbitmq servers ( https://forge.fedoraproject.org/infra/tickets/issues/13383 )
Nice to finish this off soon.
I am hopefull that we have solved the last of our auth issues late this week. There's a lot of moving parts in our authentication stack: ipa servers on the backend, noggin on the frontend (accounts.fedoraproject.org), ipsilon for identity provider (id.fedoraproject.org). All of these have had various issues recently, but we have worked through them and I did some tuning of ipsilon on thursday that seems to have really helped.
If you are still seeing any issue, please add exactly what you were trying to login to/do and time/date to our tracking ticket. ( https://forge.fedoraproject.org/infra/tickets/issues/13482 )
We are in beta freeze now, so hopefully that will keep things a bit quieter and we can catch up on work in staging and docs and other like things.
As always, comment on the fediverse: https://fosstodon.org/@nirik/117180272072423365
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:
ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.
Replacement of default PHP by version 8.5 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.5/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.5 dnf update
Parallel installation of version 8.5 as Software Collection
yum install php85
Replacement of default PHP by version 8.4 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.4/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.4 dnf update
Parallel installation of version 8.4 as Software Collection
yum install php84
And soon in the official updates:
⚠️ To be noticed :
ℹ️ Information:
Base packages (php)
Software Collections (php83 / php84 / php85)
remi )
on 2026-07-31 05:05:00 UTC
RPMs of PHP version 8.5.9 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.4.24 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.3.33 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.2.33 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
ℹ️ These versions are also available as Software Collections in the remi-safe repository.
ℹ️ The packages are available for x86_64 and aarch64.
⚠️ PHP version 8.1 has reached its end of life and is no longer maintained by the PHP project.
🛡️ These Versions fix 3 security bugs (CVE-2026-7260, CVE-2026-17543, CVE-2026-17544), so the update is strongly recommended.
Version announcements:
ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.
Replacement of default PHP by version 8.5 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.5/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.5 dnf update
Parallel installation of version 8.5 as Software Collection
yum install php85
Replacement of default PHP by version 8.4 installation (simplest):
On Enterprise Linux (dnf 4)
dnf module switch-to php:remi-8.4/common
On Fedora (dnf 5)
dnf module reset php dnf module enable php:remi-8.4 dnf update
Parallel installation of version 8.4 as Software Collection
yum install php84
And soon in the official updates:
⚠️ To be noticed :
ℹ️ Information:
Base packages (php)
Software Collections (php83 / php84 / php85)
I skipped a week again. Some good podcasts this week, have a listen to the ones about The Pragmatic Programmer and the one about performance. For some fun, play Snek and watch the relaxing visualisation of train movements.
Headed for the Exit: the Great Engineering Leader Career Break - I can definitely relate. I would say that this doesn’t affect only leaders.
catanzaro )
on 2026-08-27 14:56:33 UTC
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.
czanik )
on 2026-08-27 11:02:53 UTC
Most of August, I was on vacation, but now I’m back and I try catching up on the events of the past weeks, just like my colleagues do. Currently, we are fixing issues and reviewing contributions, but we also discussed scaling back our efforts on Java support.
While most of the team was away on vacation, the number of syslog-ng contributions suddenly grew. We support both autotools and cmake, and while differences are narrowing, there are still some minor problems to fix. There are pull requests related to cmake, the syslog-ng disk buffer and more. Check https://github.com/syslog-ng/syslog-ng/pulls?q=is%3Apr+ for a full list of pull requests we are working on.
We also received some new issues. One of them was related to a memory leak when syslog-ng is reloaded. While we fixed several problems, Java was not among them. In fact, we rather disabled packaging Java destination support.
To explain this decision: Java support was introduced back when several destinations had no native C drivers and were only implemented in Java. However, Elasticsearch works fine using a wrapper around the http() destination. Kafka now also has a native C driver. And as for HDFS: well, it is dead, and its code will be removed from syslog-ng soon. A few months ago, I also wrote about disabling Java support in my packages. Now the same is happening with Debian / Ubuntu / RHEL packages available from https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-java-destination-disabled At the same time, we also decided not to work on a Java-related memory leak problem, unless we are notified that someone is actually using the Java destination with a self-developed driver. We were aware of such projects 3-4 years ago, but not anymore.
But are there any benefits of not packaging Java, you might ask? Well, in the Debian / Ubuntu world, many users install the syslog-ng package, which is an umbrella package installing all syslog-ng sub-modules and their dependencies. But even without an umbrella package, I have seen similar solutions from RPM users. Removing the unused Java package from the mix reduces both RAM and HDD usage, which benefits everyone.
Originally published at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-end-of-august-news-and-about-scaling-back-java-support
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.
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.
Here are some features of a good inactive maintainers policy:
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.
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.5.10RC1 are available
RPMs of PHP version 8.4.25RC1 are available
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.
ℹ️ Installation: follow the wizard instructions.
ℹ️ Announcements:
Parallel installation of version 8.5 as Software Collection:
yum --enablerepo=remi-test install php85
Parallel installation of version 8.4 as Software Collection:
yum --enablerepo=remi-test install php84
Update of system version 8.5:
dnf module switch-to php:remi-8.5 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.4:
dnf module switch-to php:remi-8.4 dnf --enablerepo=remi-modular-test update php\*
ℹ️ Notice:
Software Collections (php84, php85)
Base packages (php)
canderson9 )
on 2026-08-26 05:30:59 UTC
As an expat living in Germany, online radio has become a good daily companion. I enjoy listening to news from my home country (and connect to my mother tongue), practice German language or just discovering music and stories from a random place around the globe.
I found a GNOME app that is a genuine gem: Shortwave, which can be installed via Flathub.
Shortwave is an online radio app for GNOME that has a great and clean design, cool features and a built-in search that makes finding radio stations around the world effortless. Just search, tune and listen, super easy.
mjg59 )
on 2026-08-26 04:04:17 UTC
I’m on a VPN setup with several friends that, obviously, includes a VoIP network. I also have an old magicJack adapter and a deep and abiding need to use hardware in ways I should not. There was obvious synergy here.
Plugging in the magicJack gives a USB vendor id of 0x06e6, which belonged to a company called TigerJet who made a range of chips for hooking up phones to computers, either via USB or PCI. Some more digging suggested that it was a 580 part, and someone had conveniently uploaded some reference code and datasheets, so figuring out how to talk to the chip wasn’t terribly difficult. Once configured it simply sends HID events whenever a user hits a phone key or changes the hook state, and otherwise exposes a USB audio device that can be spoken to using the stock kernel driver. It also has the ability to generate dial tone and assert ring signal, giving a full traditional phone experience.
So you’d think this would be a super easy project, but I’d made things harder for myself by deciding I wanted to tie directly into Asterisk rather than just smashing an existing SIP stack onto the device. Asterisk uses channels to talk to devices, and channels end up as compiled C code that Asterisk can load dynamically. I didn’t want to have to deal with the pain of compiling stuff and matching ABIs and everything so writing a new channel from scratch was unappealing. Fortunately, the websocket channel is available in recent versions of Asterisk and provides a convenient way to get audio in and out, but that still leaves the job of handling incoming and outgoing calls. That’s handled with the Asterisk Rest Interface, which can initiate a call or respond to an incoming one and bridge various channels together to produce a bidirectional audio stream. There’s a convenient async Python library that handles the low level protocol.
Code for all this is here1, and works for my use case, but I should really abstract out the asterisk side and the magicJack side to make it easier to adapt to other devices. That’s a job for later, though. For now, you get this:
filiperosset )
on 2026-08-26 03:43:32 UTC
#
# 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
admin )
on 2026-08-25 12:47:18 UTC
By Ananya Nalavathu and Francois Gonothi Toure
Open source communities run on contribution, and contribution runs on documentation, storytelling, and knowledge sharing. At the Fedora Project, that means the Fedora Community Blog and Fedora Magazine, two publications that give contributors a voice and give the community a way to stay informed, inspired, and connected.
This year, as part of my internship with the Fedora CommOps team at Red Hat Ireland, I got to experience that firsthand. Publishing 11 articles, running editorial campaigns, and coordinating content across sprints gave me a deep appreciation for how much thought goes into keeping Fedora’s editorial standards consistent and how much easier that journey could be for new contributors with the right tool in hand.
That’s exactly what my fellow intern Gonothi built during his Outreachy internship with the Fedora Project. In our final sprint together, we decided to share it with the community because tools that make contributions more accessible deserve to be heard. With that context in mind, I’ll hand over to Gonothi to walk you through what he built and why.
My name is Gonothi, and I’m an Outreachy intern within the Fedora Project. The tool I built is called editorial-guide-ramalama, a Retrieval-Augmented Generation (RAG) assistant that reads Fedora’s actual editorial guidelines and published articles, then checks your draft against them. It tells you whether your article meets the standards and exactly what to fix if it doesn’t.
A regular chatbot would guess. RAG grounds every answer in the actual guidelines. When the tool flags a problem, it cites the specific guideline and gives you an actionable fix. Not “this looks off”- but “your article is missing the Read More tag, which is required per the Magazine guidelines.”
RamaLama is the engine behind the whole tool, and it’s a big part of why this project works the way it does. It runs open models locally as OCI containers, the same container tooling Fedora already uses, so there’s no API key, no external service, and no data leaving the machine, which keeps everything private and fully reproducible. It also has RAG built in: RamaLama handles the ingestion, chunking, and retrieval itself (running Docling internally to parse and chunk the guidelines), so I don’t have to wire together a separate vector pipeline. That combination of local inference, OCI-container packaging, and built-in RAG is what lets the tool ship as a single image that anyone can pull from Quay and run.
The tool supports both Fedora publications, Fedora Magazine and the Fedora Community Blog, each with its own editorial guidelines loaded as the primary source the model checks against. Switch publications in the sidebar, and the guidelines change accordingly.
The stack is built on RamaLama, Docling, Quay, and Streamlit, with small GPT-Generated Unified Format (GGUF) models benchmarked for quality versus size. The pipeline works like this:
Articles are pulled from both publications via the WordPress REST API; no static files are committed, and the corpus is always rebuilt from source and stays reproducible. RamaLama RAG runs Docling internally to parse and chunk the documents into a vector store, packaged as OCI images published to Quay at quay.io/fedora/editorial-guide-ramalama. To run a check, pull the relevant image and use either the Streamlit interface or the terminal; no build step required.
Paste a draft that meets the Magazine’s standards, and the model confirms compliance, citing the relevant guideline. Paste one with known issues, a missing featured image, a missing Read More tag, and it flags each problem with an actionable fix.
One honest note: small local models have limits. editorial-guide-ramalama is great for catching common issues before submission. It is not a replacement for a human editor, and it doesn’t try to be.
What strikes me most about this project is not just what it does technically, but what it represents for contributor onboarding in open source communities. One of the biggest barriers for new Fedora contributors isn’t motivation; it’s knowing the unwritten rules. Editorial guidelines, packaging standards, community norms these exist, but they’re scattered, and learning them through rejection is discouraging.
Tools like editorial-guide-ramalama lower that barrier. They don’t replace human editors or community knowledge; instead, they give new contributors a first pass, a way to self-check before they submit, and a way to learn the guidelines through doing rather than through trial and error. That’s exactly the kind of tooling that makes open source communities more accessible.
This mini-project was the proof of concept that validated the RAG approach for Fedora editorial documentation. The same architecture is now feeding into a larger project applying RAG to RPM packaging guidelines, a higher-stakes domain where grounded, local, open-model AI can help contributors get packaging right.
The code is on the Fedora Forge at ai-ml/editorial-guide-ramalama. Pull the image from Quay and try it on your next draft before you submit.
The tool is live and available now. Pull the image from Quay, paste your draft, and see what it says. If you’re a new contributor, nervous about your first article, this was built for you.
Thank you to the Fedora community, our mentors Justin Wheeler, Dominik Kawka, and Carol Chen, and Outreachy for making this internship possible.
The post Meet editorial-guide-ramalama: An AI Assistant That Checks Your Fedora CommBlog and Magazine Articles Against Editorial Guidelines appeared first on Fedora Community Blog.
Across the Fedora project, a major unified focus is the urgent preparation for the Fedora 45 Beta Freeze on August 25, 2026. Multiple groups—including Release Engineering, Quality, and various architecture and desktop SIGs—are finalizing mass branching, managing fails-to-install (FTI) packages, and conducting Blocker Review meetings to triage critical issues, such as widespread rpm-ostree breakages caused by the recent RPM repository configuration relocation to /usr. Concurrently, significant infrastructure shifts are a central theme, highlighted by the decommissioning of pagure.io into a read-only static archive and the formulation of usage policies for the new Forgejo-based Fedora Forge. Finally, routine package and system maintenance remains a shared priority, with teams actively auditing inactive maintainers, coordinating mass rebuilds for EPEL 10.3 and RISC-V, and modernizing packaging strategies across language-specific ecosystems like Python, Perl, and Rust.
Significant infrastructure shifts are underway as pagure.io transitions to a permanent, read-only static archive, cementing the new Forgejo-based Fedora Forge as the primary development platform. Accordingly, the Fedora Council is finalizing the Fedora Forge Usage Policy, which restricts the new forge strictly to Fedora-related projects, marking a departure from the previous general-use scope of Pagure. In brighter community news, the Fedora Badges service has been completely rebuilt from the ground up into a fast, modern single-page application and is currently heading to production.
As Fedora 45 approaches its Beta Freeze, developers are urgently reminded that all F45 system changes must be marked "Complete" by August 25. Concurrently, routine maintenance has identified over 200 inactive packagers for the F45 release cycle; affected contributors must comment on their tracking tickets to avoid being removed from the packager group. Finally, contributors and general Linux enthusiasts are invited to participate in the Fedora 45 Test Days starting August 17 to help evaluate major upcoming software changes—including GNOME 51, RPM 6.1, and OpenSSL 4.0—on both real hardware and virtual machines.
This week, the Fedora Council focused on policy development and event planning. A revised draft (Version 3) of the Fedora Forge Usage Policy was published for an extended community feedback period before an impending Council vote. Additionally, the Council began brainstorming Call for Papers (CfP) themes for Flock to Fedora 2027, and initiated a discussion on clarifying the AI-Assisted Contributions Policy regarding commit message attribution.
See the detailed report for the Council team.
Learn more about the Council team.
FESCo had a busy week managing package maintainer responsiveness, assessing feature changes for Fedora 45, and planning the requirements for Fedora's upcoming Bugzilla replacement. The committee addressed major regressions in rpm-ostree caused by the RelocateRpmRepoConfigsToUsr change, opting to grant maintainers a few more days to implement fixes before forcing a revert. In addition, FESCo handled multiple non-responsive maintainer tickets and approved several system-wide changes, including dropping the NIS profile from authselect and updating python-cloudflare for certbot.
rpm-ostree breakages caused by the RelocateRpmRepoConfigsToUsr change; otherwise, the change will be reverted for Fedora 45.certbot.See the detailed report for the FESCo team.
Learn more about the FESCo team.
The Mindshare group met on August 20, 2026 (meeting log) to share recent announcements and review open tickets. Key news included the production launch of Fedora Badges v3.x (Announcement, Try out) and Framework's announcement of their new Laptop 12 featuring an optional Fedora KDE pre-installation.
Due to low attendance, comprehensive ticket resolutions were largely deferred to asynchronous communication. Members reviewed event planning for Data Con LA 2026 (Issue 143) and All Things Open 2026 (Issue 128). They also discussed structural topics, including how to handle historically vacant Marketing and CommOps seats (such as CommOps Issue 145) on the committee.
Learn more about the Mindshare team.
The Diversity & Inclusion group has begun early planning for the 2026 Fedora Week of Diversity. The event is tentatively scheduled around October 9th as a short, 2-to-3-hour virtual event featuring 10-to-20-minute talks. The current proposed theme is "Respect the Culture," though the group is actively open to brainstorming other options.
Learn more about the Diversity & Inclusion team.
This week, the Workstation Working Group focused on cleaning up default installations and third-party repositories. They discussed the removal of GNOME Boxes from the default installation, a change likely slated for version 52, while keeping GNOME Connections. Additionally, they approved the removal of PyCharm from third-party repositories due to its outdated Community Edition.
Elsewhere on the forum, users expressed concerns over the maintenance status of Ptyxis and suggested Fedora prepare a contingency plan. More details can be found in the Workstation Working Group Meeting Summary and the Ptyxis discussion.
See the detailed report for the Workstation / GNOME team.
Learn more about the Workstation / GNOME team.
This week, the KDE group announced that KDE Gear 26.08.0 is built for Fedora 44+ and ready for community testing. Community discussions focused on user requests for changes to the Fedora repositories and spins, specifically regarding the inclusion of Kgamma2 for Wayland and a debate over offering a "Minimal Installation" option for the KDE desktop to reduce default application bloat.
In addition, the Fedora QA team notified the KDE mailing list about the upcoming Fedora 45 Blocker Review Meeting for the Beta release, encouraging early votes on proposed blocker bugs.
See the detailed report for the KDE team.
Learn more about the KDE team.
The Server working group held a meeting this week focusing on Fedora 45 release testing, Ansible support restructuring, and documentation improvements. A new member joined the group to help document homelab, Podman, and systematic backup strategies. Additionally, Adam Williamson announced the upcoming Fedora 45 Blocker Review Meeting, encouraging members to review and vote on proposed blockers in advance.
See the detailed report for the Server team.
Learn more about the Server team.
The Infrastructure team completed a major planned outage to apply updates, reboot servers, and advance the RHEL 10 migration, which now has only 33 hosts remaining. Notable infrastructure changes included moving download servers to BBR congestion control for improved syncing, preparing the pagure-ro01 VM as a read-only archive ahead of the pagure.io shutdown, and successfully migrating the Matrix moderation bot to official Fedora infrastructure. Additionally, the the-new-hotness bot was fixed to resume filing Bugzilla bugs after a token expiration.
In the community and services space, a discussion is ongoing regarding the deprecation of the retrace.fedoraproject.org server, as the maintaining ABRT team no longer exists. While QA finds the service valuable, it currently lacks active maintainers. Forgejo development continued with monitoring implementation and SSH enabled on staging, while several authentication bugs affecting FreeIPA and accounts.fedoraproject.org are under active investigation.
@moderation:fedoraproject.org), with a draft policy introduced for managing official Fedora Matrix rooms.See the detailed report for the Infrastructure team.
Learn more about the Infrastructure team.
The Release Engineering team focused heavily on the Fedora 45 release cycle, finalizing post-fixes for the mass branching process and preparing for the Beta Freeze scheduled for August 25. As part of this cycle, FTI (Fails To Install) packages in the NEW state were processed for retirement, and a Blocker Review meeting was announced for the upcoming Beta release. Furthermore, progress was made on infrastructure improvements, such as preparing the new Fedora 46 (Rawhide) openh264 builds for Cisco and enhancing documentation.
A significant operational shift highlighted this week is the full transition to self-service package unretirements. Maintainers opening unretirement tickets were directed to use the fedpkg request-unretirement command instead. To support this, the background tooling (toddlers) was updated with retry logic and fixes for Koji tag resolution on Rawhide. The team also handled routine requests to untag buggy updates (such as freeipa and bash-color-prompt) to prevent widespread test failures, and processed multiple EPEL stalled package handovers.
fedpkg request-unretirement instead of opening Releng tickets, as advised in multiple unretirement requests.See the detailed report for the Release Engineering team.
Learn more about the Release Engineering team.
Fedora 45 branching is mostly complete, though it was heavily complicated by the late-stage landing of the RPM repo config relocation to /usr. This required urgent patching across Anaconda, openQA, and Kiwi, and currently leaves ostree broken. Early manual validation testing for Fedora 45 is ongoing and has already surfaced notable bugs, including missing initial setup screens on non-graphical disk images (affecting Server and Minimal) and system freezes during shutdown.
In broader community news, a significant discussion highlighted performance and efficiency regressions caused by the default switch from power-profiles-daemon to tuned-ppd. Users and developers are actively debating whether to adjust the default TuneD profiles or revert the change entirely. Additionally, QA efforts are moving forward to formally propose replacing the unmaintained mcelog package with rasdaemon.
mcelog with rasdaemon by default, as mcelog is minimally maintained and fails on modern, unsupported CPUs. (Discussed in the Quality meeting and forum thread)See the detailed report for the Quality team.
Learn more about the Quality team.
This week, community members praised the newly revealed Fedora 45 wallpaper on the Fedora 45 Wallpaper Inspiration Poll. The team is already preparing for the next release, having recently held the Fedora 46 wallpaper mindmap call. In documentation news, the Design Docs have been revamped with newly published How We Work and Meetings pages.
On the tracking side, a contributor is asking for scoping clarification on the Community Personas project to determine whether deliverables should include a comic or just character illustrations. Additionally, older legacy repositories like designassets have been successfully migrated to the new design organization on Forge to preserve their history before Pagure is deprecated.
designassets repository (along with several others) was formally migrated to the new design organization on Forge to preserve historical content before Pagure is retired (Ticket #82).Learn more about the Design team.
This week, the Docs team and community members engaged in a discussion regarding the Fedora Installer's recommendation for a separate /boot partition, exploring the technical constraints and historical reasons behind it. Additionally, a broken link reported on a Fedora test results wiki page was addressed and resolved after being properly routed to the Quality team.
relval package documentation in the Release validation instructions wiki template were fixed by the Quality team. (Issue #61)See the detailed report for the Docs team.
Learn more about the Docs team.
The Internationalization group held a meeting on August 17 to review the progress of Fedora 45 changes, bug triaging for Fedora 43, and upcoming test events. Three changes for Fedora 45 (Fontconfig 2.18, LibreOffice Dictionaries, and IBus 1.5.35) have been accepted and will be transitioned to the MODIFIED state before next week's ON_QA deadline. Contributors were also reminded of key Fedora 45 milestones approaching on August 25, including the Beta Freeze, Bodhi updates-testing activation, and the 100% Code Complete deadline.
Learn more about the Internationalization team.
Vitaly inquired on the legal mailing list about the licensing of a JavaScript port of CPython's argparse (thread). The question centered on whether the port could be licensed under PSF-2.0 alone, rather than carrying the full CPython license stack, since the original code was added in 2010. Richard Fontana followed up by addressing the question directly on the upstream pull request.
Learn more about the Legal team.
Branched Fedora 45 chroots, which are builds copied from Rawhide, are now enabled and available for use in Fedora Copr. This update was announced on the copr-devel mailing list.
Learn more about the COPR team.
This week, the EPEL team's primary focus was preparing for the upcoming EPEL 10.3 mass branching scheduled for August 24, 2026. This process will create the EPEL 10.4 tags and involves temporarily disabling builds to the epel10-candidate target, as announced on the epel-announce and epel-devel mailing lists and discussed during the weekly meeting.
Additionally, the team discussed two package updates moving into testing: the new epel-release update for CentOS Stream 10 and a long-awaited ffmpeg compatibility package for EPEL 9. Both updates require community testing and feedback.
epel10-candidate target during the process.See the detailed report for the EPEL team.
Learn more about the EPEL team.
This week, the Atomic group saw brief activity across two forum discussions. A moderator action took place on an older discussion regarding Lenovo shipping ThinkPad laptops with Fedora, splitting off newer posts into a dedicated topic for new AI-ready ThinkPad models.
Additionally, a discussion regarding the behavior of /opt and /usr/local as symlinks in Silverblue and bootc images received a response. It was clarified that existing systems heavily rely on this legacy behavior, and any proposed changes to make them regular directories would require a comprehensive migration path.
Learn more about the Atomic team.
The CoreOS group met on August 19, 2026 (meeting log) to review the Fedora 45 Release Schedule ahead of the beta freeze. The team evaluated several proposed Fedora 45 system-wide changes to determine their impact on Fedora CoreOS, updating their F45 tracker. Most reviewed changes, such as LLVM 23, CMake variable drops, and disabling vendor changes by default, are expected to be transparent to FCOS.
The group also discussed ongoing work and blockers. Incomplete branching for fedora-bootc images is currently holding up Rawhide and Fedora 45 progress. Ongoing investigations continue for the relocation of RPM repo configs (Issue #2172) and the impacts of an OpenSSL upgrade (Issue #2165) and RPM cryptographic policy changes (Issue #2085).
Learn more about the CoreOS team.
The Fedora IoT Working Group met to discuss the status of stable and upcoming releases ahead of the Fedora 45 Beta Freeze on August 25, 2026. Fedora 44 remains stable, with testing progressing well on a new Greenboot update. However, both Fedora 45 and Fedora 46 have encountered critical installation failures that caused their OpenQA tests to be canceled. The group is actively triaging these bugs, particularly focusing on issues related to Anaconda and rpm-ostree.
rpm-ostree failure impacting Fedora 45, as the primary maintainer is currently on PTO.See the detailed report for the IoT team.
Learn more about the IoT team.
Adam Williamson announced the upcoming Fedora 45 Blocker Review meeting, scheduled for August 24, 2026, at 16:00 UTC on Matrix. The agenda includes evaluating 3 proposed blockers and 3 proposed freeze exceptions for the Beta release against the Fedora Release Criteria.
Learn more about the ARM team.
The Hummingbird group held its community meeting on August 20, 2026 (summarized here). Key updates included the introduction of the Gorget project for managing source tarballs and dependencies, progress on the bootable host (which is dropping the "bootc" name for trademark reasons), and broader Fedora Atomic Initiative efforts to expand Konflux access outside of Red Hat. The group celebrated reaching 3,100 packages in the repository and over 500 users of their images on public GitHub.
A major topic of discussion centered around establishing contributor pathways and building trust within a highly automated, SLSA-compliant environment. The team acknowledged that current restrictions (such as build logs hidden behind private logins) clash with Fedora's open philosophy and act as a barrier to external contribution. To address this, they agreed to break the contributor ladder down into three distinct areas: infrastructure code, build system operations, and image content creation.
Learn more about the Hummingbird team.
The kernel-ark os-build branch has been rebased. This continues a standard cadence established since version 5.15, aligning with upstream releases. By rebasing near the end of a release cycle when outstanding merge requests are minimal, the team ensures that patches carried by Fedora remain no more than one release out of date. This practice maintains the project's spirit of openness and makes patches easier to apply to other trees.
kernel-ark os-build branch was rebased, continuing the established cadence of rebasing for every upstream release (which will continue for 7.3, 7.4, etc.).Learn more about the Kernel team.
The Fedora RISC-V group successfully concluded the mass rebuild for Fedora 45, leaving a delta of fewer than 1,000 packages. The team is preparing to analyze the remaining "fails to build from source" (FTBFS) packages and unresolved dependencies once another full delta rebuild is complete. In the weekly meeting, members also highlighted solid progress on building installer images utilizing Anaconda and image-builder.
On the hardware front, the team is actively debugging glibc mutex failures on Titan (DP1000) boards and has temporarily disabled some builder boards due to proxy issues. Additionally, members suggested starting Fedora 46 preparations earlier than usual to maintain momentum while the package delta remains manageable.
Learn more about the RISC-V team.
The Security group focused on privacy-enhancing initiatives and SELinux integration for systemd-run0 this week. During their August 20th meeting, the SIG debated adopting a package (ff-disable-ai-ml) that disables Firefox AI/ML features, ultimately concluding that a dedicated Privacy SIG would be a more appropriate home. Consequently, a draft proposal for a new Fedora Privacy SIG was created and is currently open for feedback.
In SELinux developments, discussions on the systemd-run0 policy issue thread yielded a path forward for making run0/systemd natively SELinux-aware. This upstream fix will dynamically calculate target user contexts, bypassing the current architectural limitations of PAM transitions via PID 1.
ff-disable-ai-ml repository to the Security SIG was placed on hold in favor of creating a dedicated Privacy SIG. (Meeting Log)systemd-run0 natively SELinux-aware, rather than relying on static policy rules to handle transitions. (Mailing List)See the detailed report for the Security team.
Learn more about the Security team.
This week, Amine Kheddache introduced a free AI chat platform called Ptero on the DotNet SIG mailing list. The tool requires no signup and provides access to multiple large language models. It is designed to assist C# and .NET developers with debugging, generating boilerplate code, brainstorming architecture patterns, and explaining complex concepts like LINQ and async.
Learn more about the DotNET team.
This week, the Perl group focused on routine package updates and continuous integration testing. Michal Josef Špaček opened and merged four pull requests (PRs 13 through 16) to bump the perl-Mozilla-CA package to version 20260813. In addition, Steve Traylen continued work on PR #5 for perl-SQL-Abstract to disable the Perl bootstrap, successfully triggering a Packit CI scratch build to test the configuration.
perl-Mozilla-CA package to version 20260813 via PR #13, PR #14, PR #15, and PR #16.Learn more about the Perl team.
This week, the Python group clarified that redundant manual license file declarations can be safely removed from specfiles in favor of using %pyproject_save_files --assert-license unconditionally, provided the package requires flit-core 3.11 or newer (Drop second copy of LICENSE file?).
The group also agreed on a migration strategy for the backwards-incompatible flit-core v4 release. To avoid widespread build failures for packages pinning flit-core < 4, the primary package will be updated to v4 while simultaneously introducing a deprecated v3 compatibility package. This will allow time to gradually patch dependent users (Plan for flit-core v4).
flit-core >= 3.11 can safely drop manual %license directives and rely exclusively on %pyproject_save_files --assert-license (Source).flit-core v4 will be handled by updating the main package to v4 and providing a deprecated v3 compatibility package, allowing dependent packages to be patched incrementally over time (Source).Learn more about the Python team.
This week, the Rust group discussed a proposal for a new RPM packaging strategy aimed at eliminating the large volume of empty feature subpackages by using conditional metadata dependencies instead. Contributors weighed the impact of the currently generated Rust feature packages, noting that while they constitute a significant percentage of Fedora's package count, their actual payload and size remain negligible. Additionally, a new package review request for rust-ssh2 was submitted.
See the detailed report for the Rust team.
Learn more about the Rust team.
/boot and /lib/modules could be deduplicated using symlinks, successfully testing a boot where symlinks pointed to /lib/modules.community.mysql ansible collection has been renamed and is seeking a new maintainer for the ansible.mysql collection.file 5.47 caused systemd .service files to be misidentified, breaking brp-mangle-shebangs; maintainers are advised to explicitly install unit files with 0644 permissions.matrix-synapse package after it was retired due to failing to install.pagure.io decommissioning, and it was clarified that src.fedoraproject.org (dist-git) remains unaffected until a future migration to Forgejo.-fno-strict-overflow) to prevent overly aggressive optimizations that could introduce security vulnerabilities.low-memory-monitor, stats from the inactive packager check for F45, a non-responsive maintainer check for ddcutil, an announcement that pagure.io is now a read-only static archive, a request to retire python-PyPDF2 and pdf-stapler, a call for package review swaps, the unretiring of bodhi-server, a reminder of the F45 Changes Complete deadline, and a notice regarding a license change in mysql-connector-java.evtest, evemu, and several X11 utilities as they are unmaintained upstream.showtime because the upstream project now refuses bug reports from non-Flatpak builds; it was quickly adopted by Fabio Valentini.python-tiktoken, which is a leaf package.sg3_utils-1.49 containing a soname bump, requiring a sidetag rebuild for dependent packages.z3 that will require reverse dependencies to be rebuilt.For contributors interested in Testing, Quality Assurance, and General Feedback, there are numerous entry-level opportunities across the project that do not require specialized team membership. Community members are highly encouraged to help with Fedora 45 early manual validation testing, test branched F45 builds, and participate in the Internationalization Test Week starting September 7. Users can quickly assist by testing the KDE Gear 26.08.0 Bodhi update, the new epel-release update, and the freshly launched Fedora Badges v3.x platform. Furthermore, anyone can help shorten release meetings by asynchronously voting on blocker bugs and freeze exceptions using the Blockerbugs app. General feedback is widely requested on several community-wide topics, including the Fedora Forge Usage Policy, Conflict of Interest Guidelines, AI-assistance attribution in commits, the Privacy SIG proposal, and the Ptero AI tool for .NET (mailing list thread).
Those with Writing, Design, and Event Organization skills are highly sought after to support project infrastructure. Documentation writers can tackle server-side "white spots" (like Podman containers, HPC, and domain controllers), review installer and partition layout guides, or update Workstation marketing materials to reflect that GNOME Boxes is no longer a pre-installed application. Artists and UX contributors are invited to help shape and illustrate the Community Personas project, review legacy assets in designassets, or propose new QA data visualizations in Ticket #923. On the events and community side, volunteers are needed to organize the 2026 Fedora Week of Diversity (FWD)—which has openings for schedule management, marketing, and video editing—or staff the Fedora table at All Things Open 2026 (Issue #128). Contributors seeking leadership roles can also look into open committee seats on CommOps (Issue #145).
Contributors proficient in Package Maintenance can step in to keep the distribution healthy by adopting orphaned packages, claiming retired packages using fedpkg request-unretirement, or co-maintaining packages currently facing the non-responsive maintainer process (Ticket #3678 / sponsors issue tracker). Language-specific packagers can provide feedback on the proposal for "features/extras" packaging without subpackages, assist with the Python flit-core v4 migration by patching dependency constraints, or review pending packages like rust-ssh2. Community members are also encouraged to participate in cross-team package review swaps to help unblock dependencies.
Finally, there are critical Systems Engineering and Debugging tasks for developers and sysadmins. The Infrastructure team welcomes newcomers to help port packages for the RHEL 10 migration and is urgently seeking 1-2 engineers to take over maintenance of the retrace (FAF) crash analytics server. System architects and engineers can jump in to investigate severe installation failures, such as IoT's Anaconda boot failure and rpm-ostree bugs, or analyze CoreOS's OpenSSL upgrade impacts and FESCO Ticket #3661 enablement. There are also specialized opportunities to investigate RISC-V mass rebuild build failures, help systemd-run0 become natively SELinux-aware upstream, or submit YAML manifests and container files to the new Hummingbird build factory using standard pull requests.
Another week gone by, it's hard to understand that it's almost fall now.
Much of my week was handling updates/reboots/reinstalls. Got all our instances, including our openshift clusters updated to the latest and rebooted. Also I managed to move almost the last of our vmhosts over to rhel10.
We are down to just 27 rhel9 instances left.
12 are db servers
6 are rabbitmq-servers
1 logserver
2 mailman servers
1 fedorapeople
1 storinator
1 torrent server
1 straggler vmhost that needs a disk replaced before reinstall
2 zabbix servers
I'm hoping to finish up the logserver, storinator and torrent servers next week, then I will start on the db servers. Hopefully doing staging first to catch any problems and then doing the prod ones in the time after beta but before final freeze.
We have a plan for the rabbitmq servers and zabbix servers. For mailman we will need to look and see what is missing in epel10 for them.
Looking forward to finishing this up and moving on to other things.
The last bits got sorted out and now pagure.io is read-only. You can pull git repos and look at other content, but no login/push/api access is possible.
I don't know that we have a specific timeline for keeping this, but I think it should be a very long time. It's static with no auth so the attack surface is much smaller than the pagure instance.
It's already getting to be time to start the Fedora 45 Beta freeze. So, if you have anything you want to land in the Beta, you best do it asap.
My trusty Lenovo slim 7x that I have been using day to day all the time for the last 2 years (!) is finally showing some signs of wear. The battery at full is only 70% of it's orig full capacity. Some of the keys have really anoyingly been sticking for me (especially the 1 and down arrow keys). Sometimes they send 2 or 3 keypresses. Pretty anoying.
So, I have been pondering what to do.
I could try and replace the keyboard/battery in this slim7x, but not sure how easy that will be. This is not a very 'repairable' laptop. Even swapping the nvme drive was a super pain. The case uses clips instead of screws and sounds like it's going to shatter when you are trying to pry it open.
I could go back to my framework ryzen laptop. Should be perfectly usable. Not good enough for local ai playground, and would mean going back to x86, but otherwise it's just a reinstall and a bit of moving things around.
The newer snapdragon X2 version of the slim7x all models seem to only have 1024x768 screens, and thats a hard no from me.
There's a really nice looking x2ee hp laptop, the HP EliteBook X G2q. It has upstream support, but... man, you can configure one thats $7500. That is crazy. I could buy like 3 of the following laptops for that.
The asus zenbook a16 looks nice and has upstream support already, but I am not sure a 16" laptop will be very easy to carry around. I suppose it could be nice day to day. I'm not even sure my laptop bags would fit it. It would mean staying on aarch64, which I kinda like.
I could go all out and get a new framework 13 pro ( Ryzen™ AI 9 HX 370 ). That would get a nicer screen than my old framework, much faster, and possibily to play with local llm model stuff. Fair pile of money and going back to x86.
No great hurry to decide, and this is indeed a horrible time to buy new computer hardware sadly.
As always, comment on the fediverse: https://fosstodon.org/@nirik/117140830512414290
catanzaro )
on 2026-08-20 22:37:22 UTC
Injection vulnerabilities, like cross-site scripting (XSS) or command injection, occur when we fail to properly encode untrusted output when inserting it into a trusted context. Before injecting uncontrolled or untrusted data, it’s essential to encode, escape, or quote the data to prevent it from breaking out of its intended context.
Some security folks previously used to like to talk about “input sanitization.” In practice, input sanitization is hopeless. Instead, nowadays we do the opposite and think about “output encoding.” When you inject untrusted data into a new context, assume the data is always malicious, and encode, escape, or quote it to make it safe for use in that context. Let’s look at some examples.
Here’s a low-stakes example of Pango markup injection:
markup = g_strdup_printf ("<b>%s</b>,
my_user_provided_data);
gtk_label_set_markup (GTK_LABEL (label), markup);The untrusted data is not escaped and may decide to inject its own Pango markup, or break out of any markup that you used yourself. For example, if the data is </b><span foreground="blue" size="x-large">Hello world!</span><b> then it can decide to be blue and extra large instead of the intended bold. That’s not especially serious and probably not likely to be a security issue, but surely it’s an unintended bug. If you’re injecting an uncontrolled string into a Pango markup context, like a GtkLabel, then use g_markup_escape_text() first. (Pango markup can do other interesting things like hide characters or capitalize them. I’m not sufficiently creative to claim that’s definitely a security problem, but perhaps attackers will be more clever than me.)
A real-world example: in this GNOME Shell issue report, the title of a desktop notification is able to use Pango markup to manipulate its own formatting. (At least, probably, because the issue report is unconfirmed. Looks plausible, though!)
Another good example is the Evince command injection vulnerability from a few months ago, where a malicious filesystem path is able to trick Evince/Atril/Xreader into executing arbitrary code. Evince expects the path of a file to open to be something like /home/foo/hello.pdf, but a malicious PDF instead provides the evil input --gtk-module=/home/foo/evil.so /home/foo/hello.pdf. If not quoted properly, we have a command injection vulnerability where --gtk-module is interpreted as a command line flag rather than as a path:
Incorrect: /usr/bin/evince --named-dest= --gtk-module=/home/foo/evil.so /home/foo/hello.pdf
Correct: /usr/bin/evince --named-dest=' --gtk-module=/home/foo/evil.so /home/foo/hello.pdf'
If you’re constructing a Unix command line, as in the Evince example above, then use g_shell_quote(). Failure to do so is ruinous. (But beware: this isn’t necessarily safe if you’re using an actual Unix shell.)
With that primer out of the way, let’s consider what happens when you inject untrusted content into HTML (or CSS, or JavaScript).
I used to think XSS matters only for websites, and is surely not something that desktop app developers need to know about, right? Wrong, as I discovered five years ago when, to my surprise, Prakash (@1lastBr3ath) reported that websites could inject scripts into Epiphany’s new tab page (about:overview) via malicious page titles. This on its own is not especially serious, but it’s surely not supposed to be possible.
If your desktop app uses WebKitGTK or another web engine, you probably do need to think carefully about XSS. For example, before injecting untrusted data into HTML, we need to HTML-encode it, which Epiphany didn’t do anywhere. In the simplest case, that looks like this:
char *
ephy_encode_for_html (const char *input)
{
GString *str = g_string_new (input);
g_string_replace (str, "&", "&", 0);
g_string_replace (str, "<", "<", 0);
g_string_replace (str, ">", ">", 0);
g_string_replace (str, "\"", """, 0);
g_string_replace (str, "'", "'", 0);
g_string_replace (str, "/", "/", 0);
return g_string_free_and_steal (str);
}Simply replace the few dangerous characters with HTML entities, and you’re good to go. That doesn’t work for HTML attributes, though, where the rules are slightly different. And it definitely doesn’t work for CSS or JavaScript. Carefully review the OWASP Cross Site Scripting Preventing Cheat Sheet to understand what you can and cannot do.
Anyway, back to the old about:overview bug report. Turns out, Epiphany had many similar vulnerabilities. I attempted to fix them all, but in fact, I had missed a spot. In this old commit, I recognized that a URL is untrusted data that must be encoded before I inject the URL into the error message. But I treated the error message of the GError returned by WebKit as if it’s trusted and does not need to be encoded. In fact, the error message itself may contain a URL! Oops. Fernando Munoz recently noticed and reported several example URLs that could inject content into Epiphany error pages. I’m unable to share my favorite example URL here on WordPress, because WordPress is sanitizing it (yes, that is indeed ironic, considering my above recommendation to not do that). But the result of the injection looks like this:
So an evil URL can mess up the Epiphany network error page. That’s not particularly serious, but Fernando found a second injection that is much worse, an XSS vulnerability in Epiphany’s autofill implementation. Here, selector is formed using an untrusted DOM element ID provided by the web page itself. Notice that no output encoding is performed before the untrusted value is injected into the JavaScript command:
page_id = webkit_web_view_get_page_id (WEBKIT_WEB_VIEW (view));
world_name = ephy_embed_shell_get_guid (ephy_embed_shell_get_default ());
script = g_strdup_printf ("EphyAutofill.fill(%lu, '%s', %i);",
page_id,
selector,
fill_choice);
webkit_web_view_evaluate_javascript (WEBKIT_WEB_VIEW (view),
script,
-1,
world_name,
NULL,
view->cancellable,
autofill_cb,
NULL);Because the untrusted data here is already used as a quoted data value, one of very few cases where it is safe to inject untrusted data into JavaScript, this would actually have been safe if only Epiphany had JavaScript-encoded the value first, following the OWASP rules for JavaScript encoding: “Encode all characters using the Unicode \uXXXX encoding format, where XXXX represents the hexadecimal Unicode code point. For example, A becomes \u0041. All alphanumeric characters (letters A to Z, a to z, and digits 0 to 9) remain unencoded.” But Epiphany did not do so. (I got confused by the OWASP rules and didn’t realize how easy it was to make this safe, so I fixed it in a more complicated way instead, by removing the need for injecting the form ID.)
So how bad is this mistake? In Fernando’s example, the ID of the evil form element is "a'); alert('XSS in private world'); var _=('", allowing the malicious website to run any script it wants. That might not seem so serious, because websites don’t need to exploit any vulnerabilities to execute JavaScript… right?
Websites are only supposed to be able to execute JavaScript in the default script world. Think of a script world as basically just a big namespace for all of your JavaScript: the default world is what the website itself uses, but desktop applications can create their own private script worlds in order to run their own scripts. In a private script world, you can manipulate the page’s DOM as usual, but you have a separate environment for executing JavaScript code, so you don’t have to worry about name clashes or scripts conflicting with each other. Also, website scripts cannot access your scripts.
In practice, web browsers inject their own scripts into every web page in order to implement various browser features. Epiphany uses a script to find the best web app icon for a web page, for example. These scripts use a private script world that websites should never themselves have access to. But in this XSS attack on Epiphany’s form autofill implementation, the malicious website has managed to execute its script in the private script world. Now it can access whatever internal web browser features are available in that script world.
Unfortunately, there’s one more relevant Epiphany feature implemented using scripts: the password manager. Epiphany’s password manager is necessarily exposed to its private script world because Epiphany needs to execute JavaScript code in the web page in order to autofill passwords. Although there were no relevant bugs in Epiphany’s password autofill code (which is totally unrelated to its vulnerable generic form autofill feature), this did not matter: if an XSS bug in any Epiphany feature can be abused to execute code in Epiphany’s private script world, that code can access the password manager and exfiltrate all the user’s saved Epiphany passwords for every website. (At least, probably, because I have not set up an attack website to test this. But I don’t see why it wouldn’t work!) So that’s pretty serious.
I requested a CVE for the autofill vulnerability earlier today, but nowadays CVE requests usually take a couple of weeks, so I don’t have one yet. It is fixed in Epiphany 50.6 and 49.9. If you don’t have those versions yet, don’t panic. To be exploited, you have to manually trigger form autofill by right clicking on a form and then selecting either “Autofill Personal Fields” or “Fill This Field,” so that makes it much less scary. Even more fortunately, users probably won’t ever do that, because selecting either option always causes Epiphany to reject all further mouse input, becoming unusable. Nobody has reported this bug before, so it seems safe to conclude zero people are using Epiphany’s form autofill feature!
Update: I said it would take a couple of weeks, but a few hours later I received CVE-2026-77682. Red Hat has improved its response time!
admin )
on 2026-08-20 20:00:00 UTC
Fedora Infrastructure team will be applying updates to servers and rebooting them.
Many non-user facing services will be affected, most should only be down for a short time as their particular resources are rebooted HOWEVER some may be down for a non-trivial amount of time due to RHEL-9 to RHEL-10 …
bcotton )
on 2026-08-19 12:00:00 UTC
If you’ve ever tried to make something work better by adding or changing a process, you may have noticed that the something got worse. Whether that worseness surprised your or not depends on if you’ve heard of the “J curve” concept. A J curve is any graph that looks like the letter “J”: a sharp dip followed by a sharp rise.
The phenomenon appears in many fields — economics, medicine, and technology. Where might you see it in your project? Maybe you add automated tests to reduce the manual QA work you do pre-release. This should allow you to ship your releases faster. Except once you introduce it, you spend twice as much time fixing bugs because you find so many more. The next release ships slower. But once you’ve caught up, the benefits you expected appear. Bugs — particularly regressions — get caught (and therefore fixed) faster.
Similarly, you might start blocking changes that include vulnerable dependencies. This should improve security for your users. But the first time, every dependency is full of vulnerabilities. This, at least, makes the apparent security worse. And maybe the actual security as you take time to prioritize and fix vulnerabilities in dependencies that would have been “accidentally” fixed in routine updates anyway. Again, after you have a handle on the situation, the process works as intended.
Recognizing where you are in the curve is important to navigating it. Are you still on the downslope? Have you leveled off? Are you on the way up? If what you’re trying to change is measurable, then tracking those measurements will help. Of course, not everything is easily or meaningfully measurable. In those case, you can trust your intuition. Do things feel like they’re still getting worse? Better?
The main thing is to make everyone aware of the J-ness before it starts. Acknowledge that things will get worse for a little bit and then you’ll see the improvements. Avoiding surprise is the key to keeping people engaged, and keeping people engaged is the key to seeing the change through and not ending permanently in the “worse” state. Unfortunately, it’s hard to answer the “how much longer will it take?” question; there’s no magical way to know how long the curve is. Which leads us to…
The J curve is a useful concept, but it’s not an inviolable law of physics. While there are plenty of reasonable explanations for why the J curve phenomenon occurs, there’s no guarantee that it will. Just because you think it will, does not mean it will. Sometimes, our ideas for making things better don’t work.
As I said above, you can’t predict where you’ll go next — even if you’ve been meticulously tracking the thing you care about. This, combined with the “it might not get better” aspect, means you could be on an endless march into darkness. At some point, you have to decide it’s time to bail out.
So what do you look for if you can’t predict the future? Let’s go to calculus class for a moment and think about the second derivative. In other words: the rate of change of the rate of change. If you’re really on a J curve and not a ramp into hell, the second derivative should become positive pretty quickly. (“Pretty quickly” is relative to the scope and impact of the change.) Even if things are still getting worse, you should see them getting worse more slowly. As long as the second derivative stays positive, you’re on a good track.
Finally, and what I’ve often seen ignored, is the fact that the upward part of the J doesn’t continue forever. At some point, you’ve maximized the gains you can see from that change. That’s fine. Contrary to investor beliefs, things do need to level off at some point. The Satir Change Model, developed by family therapist Virginia Satir, is a good representation of a realistic J curve, complete with a new equilibrium state at the end.
This post’s featured photo by Zyanya BMO on Unsplash.
The post The J curve, or: it gets worse before it gets better appeared first on Duck Alignment Academy.
feborges )
on 2026-08-19 10:12:54 UTC
Earlier this month, I published a post about the future of Boxes where I detailed the huge technical rewrite I have been doing, porting to GTK4, Libadwaita, and replacing our SPICE display widget with Libmks. Today, I want to share a structural decision that aligns with that vision and sets up the project for long-term health/sustainability.
I have formally submitted a proposal to remove Boxes from the core-developer-tools set in gnome-build-meta and transition it towards becoming an independent application (with the ultimate goal of applying for GNOME Circle once all criteria are met).
I want to dive into why I am making this move, what it means for users and maintainers, and why I believe this is the right path forward.
First off, let’s get this out of the way: there is zero drama between Boxes and the GNOME project.
Boxes continues to be built by the same core set of contributors, fully committed to the GNOME Human Interface Guidelines (HIG) and deeply integrated into our ecosystem. We aren’t stepping away from GNOME. We are simply right-sizing how Boxes is categorized, distributed, and maintained.
The desktop Linux landscape is shifting toward image-based operating systems with atomic updates and immutability. In this model, the underlying operating system provides a slim, reliable base, while applications live on top and update independently at their own pace.
Tying a complex application like Boxes to the biannual GNOME release schedule is not useful anymore. It forces us to hold back features and bug fixes for months just to align with the OS cadence, when users should simply get updates when they are ready and stable.
Furthermore, virtualization isn’t an essential utility that needs to be pre-installed on every single user’s machine by default. Boxes fits much better as a targeted application users explicitly choose to install when they need it.
As a maintainer, maintaining separate code paths and stable branches for dozens of traditional distribution packages is simply not sustainable long-term. I can no longer afford to maintain multiple stable branches. Moving forward, I am simplifying maintenance down to one stable branch and one development/nightly branch. To make this sustainable, Flathub is our primary and only officially supported distribution method.
By bundling the virtualization stack in our Flatpak, we ensure that users get a much more tested, consistent, and working virtualization backend regardless of what operating system they are running.
Moving out of Core allows us to heavily discourage downstreams from individually packaging Boxes. Instead, distros should defer their users to the official Flatpak on Flathub. If you are filing bug reports or seeking support, the Flathub build will be the baseline.
To reflect this independent status, a few logistical changes are happening alongside this move. We are dropping “GNOME” from the user-facing app branding. Going forward, it will simply be named “Boxes”, and we will soon be moving to a new website domain (which is currently being finalized). Importantly, our Flatpak application ID will remain org.gnome.Boxes for full continuity and compatibility. This means existing installations, user settings, and Flatpak configurations won’t break, and users won’t need to reinstall anything.
This change gives us the flexibility to release updates whenever features are ready, iterate faster, and dramatically reduce maintainer burnout, all while delivering a more reliable and consistent user experience via Flathub. Once we settle into this new cadence and finalize our transition, we plan to apply for GNOME Circle.
To set clear expectations on timing: since Boxes currently uses GTK3 in its stable releases, we will soon submit an application for GNOME Circle review following our GTK4/Libadwaita rewrite.
If the Circle application is approved before the GNOME 52 Alpha deadline, the plan is to proceed with the removal from core-developer-tools and transition to Circle in time for the GNOME 52 release in March 2027.
For distribution maintainers wondering about upcoming distro releases: distros targeting GNOME 51 can continue to package the GNOME 50 release of Boxes, which will remain supported for the standard lifecycle of that release. If everything goes according to plan, GNOME 52 won’t include Boxes in the core set anymore. At this point, please don’t package Boxes anymore.
admin )
on 2026-08-19 08:00:00 UTC
After years of technical research and foundational work, the Fedora Badges application service has been rebuilt from the ground up, and it is heading to production. Whether you have been collecting badges for years or you are brand new to the Fedora Project community, here is what is waiting for you there.
The archaic server rendered pages are now gone. The Fedora Badges application service now runs on a modern single page application. This provides you with a much faster and more responsive experience, while functioning across various screen sizes and devices types, all without full refreshes or front-end reloads.
Navigations have been revamped as well. But do not worry at all – if you have bookmarked any old service links, they should redirect you to the right place.
You can now customize the look of the Fedora Badges application service choosing from eight colour schemes. Your choice flows through the various elements of the front-end – from navbar to borders, from charts to accents, etc. The dark mode and light mode switch respects your system preference and can also be toggled.
Your choices are persistent across visits residing in your session storage. As long as the same session is used, the colour schemes and dark mode settings stay.
Not only does the profile page show your precious badges, it also shows a radar chart that maps your collection across categories. This is a rudimentary method to gauge your progress and discover the areas you have not explored yet. Giving a means to diversify the activities, this encourages more people to join in.
The refreshed history page also adds a collection time-line chart showing yours (and your friends’) contribution activities over months and years at a glance.
The renewed difference page lets you compare your badges collection with those of your friends’ possessions. See which badges you both share, which ones only you have, and most importantly, which ones they have earned that you have not yet. It’s a fun way to discover new badges and unearth new ways to contribute.
You can also reach out to your fellow community members for potential mentoring opportunities, based on their contribution activities and collected badges.
Every active badge now has a rarity tier based on how many users currently hold it:
You can now browse active badges by their rarity tiers, making it easy to hunt down the ones that fewer people have earned. Not only does it allow you to find new pathways for contribution, you also get a sense of the impactful work and relevant tracks that are waiting for you in your community activities.
Departing from different searches for badges and users, the search bar now helps unified lookup across both badges and users. Start typing and results start appearing immediately after – with better lookup results. These will appear when the query is general enough to return more than eight results.
To save server resources, the asynchronous search request begins only when at least four characters are entered into the search bar for the query.
Departing from the restricted rankings page, it is now possible to request custom period filtering on the leaderboards page. Filters can be based on days, weeks, months, and years. One can see who has been earning most badges in those times, and generally look back at the community’s evolving progress over a time period.
The rankings are deterministic and can be shared with others, using the sharing link that inherently applies the same filters. This creates a reproducible resource.
Badges can now be manually marked as legacy (retired, unobtainable) after they should no longer be awarded to the users. For instance, the badges for joining the Fedora Linux Release Party 42 should no longer be available to new users in 2026. Hence, they should not be accounted for while computing rarity tiers.
And nope — we are not taking awarded badges away from users who have already earned them. These retired badges are still going to be visible in the history.
You see, the revamp was not just about the front-end. The data layer that powers the application service got a major overhaul as well. The Database Library project, which handles all database operations, saw 105 commits across 7 contributors during the same period, pushing from version 1.4.1 to 1.5.5.
Here’s what changed under the hood, and why it matters to you:
Authentication has been reworked. The old session-based login has been replaced completely with a modern token-based flow using OpenID Connect. The application service now has its own dedicated authentication client so logging in through Fedora Accounts is more consistent across other things.
If you are visiting for the first time, like it has been for years, your user account is automatically created without requiring any further steps.
Email addresses are no longer visible across various API responses. They are hashed before being sent as an asynchronous response, for use by Libravatar. Users have the choice to opt out of the Fedora Badges application service entirely. In that case they will stop receiving badge awards for their community tasks.
RSS feeds are now limited to recent entries for performance and efficiency, so you can still stay informed about the latest incoming activities on the app.
If you are a part of the team, the new interface gives you a full set of tools.
Access control is tiered — community members see the service experience, while authorized team members get the administrative controls they need.
This revamp (codenamed स्वातंत्र्य or Svātantrya) represents a year of active work across the two repositories. These comprised 165 commits in Tahrir and 105 commits in Tahrir API. This occurred after many years of technical research and foundational work resulting in a leaner codebase with a net reduction of 13,320 lines of code.
I mean it when I say, this revamp would have been dead in the water without the help of the following folks (in the alphabetical order):
And those, of course, from Flock 2026’s workshop on the Fedora Badges Revamp Project.
This revamp project was in a development hell for quite some time. It was able to come out of it thanks to those listed above and countless others who have helped maintain the project for the past fourteen years or so. It is now time for me to pass this torch on to others who can help maintain this.
The project codebase currently lives on the Fedora Infrastructure’s GitHub namespace. Please consider providing feedback and contributing changes to help maintain the projects. You can also hang out with us in the Fedora Badges chat room on Fedora Project’s Matrix server to learn more.
The production deployment should be live by the time this article is publicly available. Head over to Fedora Badges to explore the refreshed experience. As it might be a little rough around the edges in the starting days, please bear with us while we hammer down the oddities with your useful reports.
Your input influences what comes next to the Fedora Badges application service. Please consider giving it a try right now and let us know what you think!
renich )
on 2026-08-18 23:25:00 UTC
Hoy me topé con un artículo bien fregón publicado por Sreenath en It's FOSS: Looking Beyond Tmux and Screen: 8 Terminal Multiplexers Worth Trying. De entrada, quiero darle todo el crédito a ese gran artículo y a su autor. La neta, te invito a que vayas y le eches un ojo a su trabajo original, porque plantea un panorama excelente sobre cómo ha evolucionado la gestión de terminales en el ecosistema FOSS.
Ahora bien, como usuario y apasionado de Fedora Linux, me di a la tarea de aterrizar esa lista completa al terreno de Fedora. Porque una cosa es que una herramienta exista en GitHub, y otra muy diferente es saber cómo se instala, si está en los repositorios oficiales, si vive en Copr o si requiere bibliotecas adicionales para correr al cien en tu máquina fedoriana.
Aquí te traigo la guía completa y probada empíricamente en Fedora de cada una de estas opciones, desde los veteranos de batalla hasta la nueva generación impulsada por Rust, Go, aceleración por GPU y agentes de Inteligencia Artificial.
Note
Todas las instrucciones y comandos que verás aquí fueron verificados y probados directamente en Fedora Linux. Para los comandos de gestión de paquetes (DNF) o directorios del sistema, asume una sesión como superusuario (su -).
Si lo que buscas es estabilidad y cero configuraciones externas, Fedora incluye en sus repositorios principales varias herramientas de primer nivel listas para instalar con dnf.
Instalación:
# como root
dnf -y install tmux
Tips de uso:
GNU Screen es el abuelo de los multiplexores de terminal. Aunque su desarrollo es más conservador que el de tmux, sigue siendo una herramienta sumamente confiable que viene incluida en prácticamente cualquier distribución Linux.
Instalación:
# como root
dnf -y install screen
Tips de uso:
tmate es un fork directo de tmux enfocado en una sola cosa: compartir tu terminal al instante con colegas o compas de trabajo sin tener que configurar túneles SSH complejos ni abrir puertos en tu router. Al arrancar, tmate genera un enlace SSH seguro y un enlace web de sólo lectura o lectura/escritura que puedes pasar a cualquier persona.
Instalación:
# como root
dnf -y install tmate
Tips de uso:
# Iniciar tmate y obtener credenciales de conexión
tmate
Una vez adentro, tmate te mostrará en la barra inferior los comandos de conexión SSH y URLs web para compartir con tu equipo.
Si ya usas el emulador de terminal Kitty, sabes que cuenta con soporte nativo acelerado por GPU para pestañas, paneles y ventanas divididas. Sin embargo, una terminal gráfica no gestiona sesiones persistentes en segundo plano por sí sola.
Aquí es donde entra abduco. Siguiendo la filosofía UNIX de herramientas pequeñas y enfocadas, abduco se encarga exclusivamente del detach y attach de procesos, dejando que Kitty gestione toda la interfaz visual.
Instalación:
# como root
dnf -y install kitty abduco
Tips de uso:
# Crear una sesión persistente llamada "servidor"
abduco -c servidor bash
Cuando las herramientas evolucionan muy rápido o no han entrado a los repositorios base de Fedora, el sistema de empaquetado comunitario Copr es tu mejor aliado.
Zellij se autodefine como un workspace completo de terminal más que un simple multiplexor. Escrito en Rust, viene con una interfaz sumamente amigable, atajos intuitivos en pantalla, soporte de pestañas flotantes, layouts declarativos en KDL y un ecosistema de plugins compilados a WebAssembly (WASM).
Instalación:
# como root
dnf -y copr enable sramanujam/zellij
dnf -y install zellij
Tip
Si prefieres contar siempre con la versión más reciente directamente desde el equipo de desarrollo de Zellij, puedes instalar el binario oficial compilado con su instalador:
# Instalación directa del binario oficial de Zellij
bash <(curl -L zellij.dev/launch)
Tips de uso:
# Iniciar Zellij
zellij
WezTerm es un emulador de terminal moderno y ultra configurable (mediante scripts en Lua) que integra su propio multiplexor cliente/servidor (wezterm-mux-server). Te permite gestionar dominios locales y conectarte a dominios remotos a través de SSH con sincronización de estado.
El autor de WezTerm (wezfurlong) mantiene su propio repositorio Copr oficial para Fedora:
# como root
dnf -y copr enable wezfurlong/wezterm-nightly
dnf -y install wezterm
Tips de uso:
Una vez instalado, puedes lanzar WezTerm con soporte de multiplexación o iniciar sesiones contra su servidor de multiplexación integrado.
En los últimos meses ha surgido una oleada de herramientas innovadoras que replantean por completo el concepto del multiplexor: interfaces modales, persistencia de estado a nivel de emulador y multiplexores pensados para orquestar agentes de codificación autónomos.
TUIOS lleva los conceptos de un gestor de ventanas tipo tiling (como i3 o bspwm) directamente dentro de la terminal. Desarrollado en Go, cuenta con una interfaz modal inspirada en Vim, soporte de múltiples espacios de trabajo (workspaces), barra con telemetría de CPU y RAM, servidor SSH integrado y automatización mediante archivos de guion (tape files).
Instalación:
# como root (si faltan utilerías de compresión)
dnf -y install curl tar gzip
# Descargar e instalar TUIOS
curl -fsSL https://raw.githubusercontent.com/Gaurav-Gosain/tuios/main/install.sh | bash
Tips de uso:
# Iniciar TUIOS
tuios
# O ejecutarlo con un tema específico
tuios --theme dracula
Boo, desarrollado por el equipo de Coder, es un enfoque distinto al clásico multiplexor. En lugar de reinterpretar secuencias de escape ANSI por encima, está construido directamente sobre la biblioteca de emulación libghostty (del proyecto Ghostty).
Esto le permite a Boo guardar el estado exacto de la pantalla y la memoria del terminal, de modo que al desacoplar y reenganchar la sesión, todo queda exactamente como lo dejaste. Además, ofrece una API y comandos CLI diseñados para que scripts externos y agentes de IA interactúen con sesiones en segundo plano sin requerir una conexión interactiva.
Instalación:
# Descargar e instalar Boo mediante su script oficial
curl -fsSL https://raw.githubusercontent.com/coder/boo/main/install.sh | sh
Tips de uso:
# Crear una sesión en segundo plano
boo new mi-tarea
# Reengancharse a la sesión
boo attach mi-tarea
Okena es un multiplexor gráfico nativo escrito en Rust utilizando el framework GPUI (el motor de interfaz desarrollado originalmente para el editor Zed). Su punto fuerte no es el trabajo en servidores remotos sin entorno gráfico, sino ofrecer un entorno de desarrollo local donde cierras la aplicación, la vuelves a abrir y todo tu espacio de trabajo (paneles, proyectos, terminales y pestañas) se restaura al instante.
Instalación:
# como root: instalar dependencias de renderizado
dnf -y install libxcb libX11 libxkbcommon-x11 vulkan-loader libglvnd-egl
# Descargar y extraer Okena
curl -fsSL https://github.com/contember/okena/releases/download/v0.28.0/okena-linux-x64.tar.gz -o /tmp/okena.tar.gz
tar -xzf /tmp/okena.tar.gz -C /usr/local/bin
chmod 700 /usr/local/bin/okena
Tips de uso:
# Lanzar interfaz de Okena
okena
# Inspeccionar comandos del cliente CLI
okena --help
Séance es uno de los proyectos más interesantes del momento. Diseñado específicamente para entornos de escritorio Linux modernos con GTK4, libadwaita y libghostty, adopta una disposición de paneles horizontales con scroll infinito (similar al concepto del gestor de ventanas niri).
Está pensado desde la base para orquestar y monitorear agentes de codificación de Inteligencia Artificial (como Claude Code, Codex o Pi). Detecta automáticamente el estado de los agentes en una barra lateral (si están trabajando, esperando confirmación o inactivos) y expone una herramienta de control por socket Unix (seance ctl) para controlar ventanas y paneles por código.
Instalación:
# como root: instalar dependencias de entorno gráfico
dnf -y install fuse-libs libadwaita gtk4 libX11 fontconfig
# Descargar el AppImage oficial
mkdir -p ~/.local/bin
curl -fsSL https://github.com/no1msd/seance/releases/download/v0.1.4/seance-0.1.4-x86_64.AppImage -o ~/.local/bin/seance
chmod 700 ~/.local/bin/seance
Tips de uso:
# Iniciar ventana principal de Séance
~/.local/bin/seance
# Controlar sesión desde CLI
~/.local/bin/seance ctl --help
Para que tengas el panorama completo de un solo vistazo, aquí te dejo la tabla comparativa con el método recomendado en Fedora:
| Herramienta | Tipo de interfaz | Método de instalación en Fedora | Repositorio |
|---|---|---|---|
| tmux | TUI clásica | ``dnf -y install tmux`` | Oficial Fedora |
| GNU Screen | TUI clásica | ``dnf -y install screen`` | Oficial Fedora |
| tmate | TUI colaborativa | ``dnf -y install tmate`` | Oficial Fedora |
| Kitty + Abduco | GPU TUI modular | ``dnf -y install kitty abduco`` | Oficial Fedora |
| Zellij | TUI moderna (Rust) | ``dnf -y copr enable sramanujam/zellij && dnf -y install zellij`` | Copr/Binario |
| WezTerm | GPU GUI/Mux (Lua) | ``dnf -y copr enable wezfurlong/wezterm-nightly && dnf -y install wezterm`` | Copr oficial |
| TUIOS | Modal TUI (Go) | Script oficial/GitHub Releases | Binario directo |
| Boo | TUI Ghostty (Coder) | Script oficial/GitHub Releases | Binario directo |
| Okena | GPU GUI (Rust GPUI) | GitHub Releases + dependencias Vulkan | Binario directo |
| Séance | GTK4/AI Mux | AppImage oficial + bibliotecas GTK4/Adwaita | AppImage/Fuente |
A final de cuentas, el mundo de los multiplexores de terminal ya no se limita únicamente a elegir entre tmux y screen. Hoy tienes un abanico chingón de alternativas:
Pruébalos en tu instalación de Fedora y quédate con el que mejor se adapte a tu flujo de trabajo. ¿Cuál de todos estos es tu gallo para el día a día?
After reading What software do you use daily in 2026? on Lobster, I learned about Chafa.
Described as: The premier UX of the 21st century just got a little better: With chafa, you can now view very, very reasonable approximations of pictures and animations in the comfort of your favorite terminal emulator. The power of ANSI X3.64 compels you!
As a heavy shell user, I decided to install and had a lot of fun opening my images in the terminal :-)
feborges )
on 2026-08-17 08:21:29 UTC
Most of GNOME 51 is now packaged for Fedora 45. Starting today and running through the end of the week, we will be running our traditional Fedora Test Day for GNOME. If you are a Fedora user, you can help us find last-minute integration issues and iron out what’s going to become the stable Fedora 45 release.
You can either boot the latest Fedora 45 image (nightly) in a virtual machine or update an existing test setup. Follow our guided test matrix, try out different features, and record your results. Even testing for 15 minutes and reporting a single issue makes a huge difference.
Visit https://fedoraproject.org/wiki/Test_Day:2026-08-17_GNOME_51_Desktop for more info. You can join the Fedora Workstation Matrix chat channel if you have more questions.
Across the various Fedora groups, the overarching focus this week was on the successful Fedora 45 mass branching and its subsequent release preparations, which drove extensive testing, mass rebuilds (particularly for the RISC-V architecture), and CI/CD validation efforts. Concurrently, infrastructure and engineering teams were heavily engaged in major system upgrades, notably migrating services to RHEL 10, executing planned server outages, transitioning repositories to Forgejo, and implementing network blocklists to mitigate aggressive automated scraping that temporarily disrupted operations. Policy and governance updates were also a central theme, as the Council and FESCo worked to finalize the Fedora Forge Usage Policy, establish new Conflict of Interest guidelines, and address community concerns regarding AI-integrated software and regulatory liability under the EU Cyber Resilience Act. Finally, routine ecosystem maintenance and security remained high priorities, evidenced by the active processing of non-responsive maintainers, Out-of-Band security patching for vulnerabilities like the "Zapscape" kernel flaw, and ongoing dependency and macro improvements across language stacks like Python and Go.
On the development and infrastructure front, Fedora 45 successfully completed its mass branching on August 11 (following an initial notification), placing the release into a post-branch freeze until a successful compose. Change owners were also reminded that all F45 changes needed to be testable by August 11. Contributors should prepare for a six-hour planned infrastructure outage on August 20 for server upgrades and RHEL 10 migrations. Policy updates are also underway, with the Council seeking feedback on the proposed Fedora Forge Usage Policy for the project's internal Forgejo instance. In broader ecosystem news, Mark J. Wielaard was honored with the Distinguished Service Award in Software Freedom by the Software Freedom Conservancy for his decades of foundational work on tools like Valgrind, elfutils, and Sourceware.
For those looking to get involved, the Fedora QA team is calling for volunteers for the upcoming Fedora 45 Test Days (detailed further in a Fedora Magazine article), starting with GNOME 51 on August 17 and followed by testing for RPM 6.1 and installation media. If you are a newcomer unsure of where to start interacting with the community, Episode 058 of the Fedora Podcast provides a comprehensive guide to Fedora's communication channels. Finally, users can check out a new tutorial on how to monitor NVMe and SSD drive health using Performance Co-Pilot (PCP).
This week, the Council focused heavily on community policies and governance processes. Significant progress was made on the Fedora Forge Usage Policy, with the Council agreeing to adjust guidelines around Personally Identifiable Information (PII) and dropping the automated repository archival rule in favor of a mandatory "tickets" contact repository for organizations. Additionally, the Council agreed to propose a new Conflict of Interest guideline requiring neutral oversight during private decisions involving access rights.
Other major topics included a proposal by Red Hat to act as the Open Source Software Steward for Fedora under the EU Cyber Resilience Act (CRA) to shield volunteer contributors from regulatory liability. The community also discussed user concerns over AI features embedded in packaged software, clarifications to the AI-Assisted Contributions Policy, and an updated draft of the Fedora Innovation Lifecycle to create a sandbox for large experimental changes.
See the detailed report for the Council team.
Learn more about the Council team.
This week, FESCo held one meeting, participated in three forum discussions, and handled 19 tickets. During the meeting, FESCo noted that the completion deadline and mass branching for Fedora 45 had arrived, and briefly discussed the need for mitigations against aggressive automated scraping on the src.fedoraproject.org infrastructure. On the forums, community members initiated a discussion on whether Fedora needs a formal policy or labeling system for packages that introduce AI-powered features, highlighting concerns about data privacy and unexpected behavior.
A significant portion of FESCo's activity in tickets involved voting on Change proposals for F45 and F46, resulting in the approval of several new features including a WebUI installer for Fedora Atomic, the deprecation of the NIS profile in authselect, and the introduction of a new encapsule developer container tool. Additionally, FESCo processed multiple non-responsive maintainer tickets, resulting in the orphaning of some packages and the assignment of new maintainers to several critical components like thermald and mcelog.
See the detailed report for the FESCo team.
Learn more about the FESCo team.
This week, the Ambassadors group received a single announcement regarding the Call for Sessions for the Everything Open 2027 conference. Fedora contributors are encouraged to submit proposals for talks or tutorials relating to Linux, open source, security, or operations by September 6, 2026. For more details, see the mailing list post.
See the detailed report for the Ambassadors team.
Learn more about the Ambassadors team.
This week, the scheduled Workstation Working Group meeting was cancelled due to a scheduling conflict. The primary discussion in the community centered around the future of the Ptyxis terminal emulator in Fedora, as its original author confirmed he is no longer maintaining the project.
Community members discussed potential alternatives to replace Ptyxis, including Ghostty and GNOME Console. To determine an official path forward and prevent wasted effort by community translators on an abandoned upstream project, a formal ticket was filed with the Workstation Working Group.
See the detailed report for the Workstation / GNOME team.
Learn more about the Workstation / GNOME team.
During the week of August 10-16, 2026, the Fedora Server group focused on Fedora 45 branched release testing and documentation restructuring. The group celebrated the availability of group-wide CI/CD runners for the first time. Significant discussions were held regarding the Home Server spin-off, specifically evaluating a new virtualized Kiwi development and testing environment.
In documentation, the group decided to streamline by merging tutorial and use-case files into a single "Use cases" section. Testing for F45 is actively underway, though a partition type issue in the VM build requires a fix.
See the detailed report for the Server team.
Learn more about the Server team.
This week, the Infrastructure team focused heavily on migrating services to RHEL 10, scheduling a major 6-hour outage for August 20 to handle mass updates, reboots, and VM reinstallations. To combat severe scraping traffic on Fedora infrastructure (which temporarily spiked server loads and disrupted Anubis on Pagure), the team successfully implemented a new user-agent blocklist. The team is also officially migrating the Matrix moderation bot to Fedora's OpenShift infrastructure, alongside drafting new policies for "official" Matrix rooms. Finally, the legacy retrace.fedoraproject.org server is being decommissioned due to a lack of maintenance.
retrace.fedoraproject.org server will be shut down and decommissioned.@moderation:fedoraproject.org).See the detailed report for the Infrastructure team.
Learn more about the Infrastructure team.
This week, the Release Engineering team successfully completed the mass branching of Fedora 45 off of Rawhide, with Rawhide officially transitioning to Fedora 46. Concurrently, the mass re-signing process for Fedora 45 packages and the generation of the Fedora 47 IMA key took place. Additionally, the team finalized the migration of all Release Engineering repositories to Forgejo (fedora-scm-requests).
Other notable activities involved fixing an early signing issue for ELN packages, updating staging environments for koji-image-builder testing, and refining internal tools, such as creating a dedicated team to validate SCM requests and reduce notification spam. Maintainers are also reminded to use the new fedpkg request-unretirement feature instead of filing Releng tickets for routine package unretirements.
fedpkg request-unretirement command (requires fedpkg v1.48+).forge-releng-scm-validators) was established to handle SCM requests directly, resolving the issue of excessive pings to all members of the releng organization.coreos-pool and replaced with the Fedora 46 key.cleber, resulting in the orphaning of their packages.See the detailed report for the Release Engineering team.
Learn more about the Release Engineering team.
The Quality group focused on system performance, package default configurations, and preparations for the Fedora 45 release. Significant attention was brought to performance and power efficiency regressions caused by the switch to tuned-ppd, prompting discussions on how to better adjust the default TuneD profiles. Additionally, community testers successfully verified a critical GRUB Out-of-Memory fix in Rawhide.
In Quality Engineering (QE), early manual validation testing for Fedora 45 has started and already uncovered several significant bugs. The team also prepared tooling for the upcoming release, testing Issuebot in production and marking it ready for F45.
See the detailed report for the Quality team.
Learn more about the Quality team.
Between August 10 and August 16, 2026, the Design team continued to refine key graphical assets for Fedora projects and internal tools, alongside ongoing UX work for the Fedora Design Docs revamp. Major discussions revolved around finalizing the character details for the LoLa AI Package Manager mascot and aiming to complete avatars for the Fedora Matrix bots by the end of the current sprint. Additionally, historical design assets were preserved through a repository migration from Pagure to the active Forge.
designassets repository from Pagure to the Design organization on Forge to preserve historical content and history.@admin:fedoraproject.org as the official handle for the newly rolling-out moderation bot, which will require an avatar.See the detailed report for the Design team.
Learn more about the Design team.
The Docs team met to discuss ongoing efforts to clean up outdated Fedora Wiki pages, exploring automated approaches using the MediaWiki API to replace tedious manual deletions. They also evaluated a new experimental CI site builder relying on Podman and discussed adopting the Vale linter, deciding to introduce it as a recommendation for local authoring before enforcing it in CI. Concurrently, a community forum discussion took place regarding the documentation and rationale behind recommending a separate /boot partition in Fedora installations. Team tickets tracked a new membership request, a broken link in the Server test results wiki page, and the extensive historical wiki cleanup effort.
See the detailed report for the Docs team.
Learn more about the Docs team.
This week, the Internationalization group received a cross-posted invitation to speak at the Everything Open 2027 conference. Community members are encouraged to submit session proposals covering topics like Linux, open source, AI, security, and operations before the September 6, 2026 deadline.
See the detailed report for the Internationalization team.
Learn more about the Internationalization team.
This week, the Legal group discussed whether Copr projects are permitted to download and use proprietary software, specifically the NVIDIA CUDA toolkit, during the build process for otherwise free and open-source packages like cuda-python. The primary concern raised was that utilizing proprietary dependencies during a build could inadvertently include proprietary code in the resulting binaries, such as through inlined headers. The prevailing consensus was that this practice is not allowed if it results in the distribution of content that violates Fedora's allowed licensing rules.
See the detailed report for the Legal team.
Learn more about the Legal team.
A scheduled outage for the COPR servers was announced for 2026-08-12 at 07:30 UTC, lasting approximately three hours. The downtime allowed the team to update COPR packages to newer versions, providing bug fixes and new features to the general Linux community using the build service.
Community members with questions or issues were encouraged to use the Fedora Build System Matrix channel (#buildsys:fedoraproject.org) or comment on the associated infrastructure ticket.
Learn more about the COPR team.
This week, the EPEL group focused heavily on repository architecture and package updates. The Steering Committee unanimously approved the "de-z-ification" of EPEL 10, aligning its repository structure with the upcoming EPEL 11 release by utilizing the $stream variable for CentOS while leaving RHEL without a suffix.
In package news, maintainers announced the migration of libgit2 dependents in EPEL 9 and EPEL 10 to the supported v1.9 branch to address security vulnerabilities, as well as minor updates to uv and ruff in the EPEL 10.3 testing repositories.
epel-10s) while RHEL uses unsuffixed paths (e.g., epel-10), aligning with the approved EPEL 11 design.libgit2 in EPEL 9 and EPEL 10 will be migrated from the obsolete v1.7 branch to the supported v1.9 branch via pull requests.See the detailed report for the EPEL team.
Learn more about the EPEL team.
The ELN group met this week to discuss recent updates, including the publication of bootc images, the minimization of go-vendor-tools for RHEL 11, and variant reorganizations such as moving Live images to a new AltImages variant and adding a new Extensions variant. The group also noted the F45 branching process, which temporarily paused builds, and highlighted that the next branching in six months will coincide with the RHEL 11 branching.
Additionally, the group discussed mitigating database bloat in Koji caused by failing draft build retries. A proposal was also made to adopt a separate GPG key for ELN content starting with Fedora 46 to reduce the frequency of key rotations from twice a year to once every three years.
See the detailed report for the ELN team.
Learn more about the ELN team.
The Atomic group had a quiet week. During a brief meeting, members noted that ongoing Konflux integration work for Atomic Desktops is continuing. On the forums, a community member inquired about /opt and /usr/local functioning as symlinks in Silverblue and asked whether future Fedora bootc images will transition to using regular directories instead.
Learn more about the Atomic team.
CoreOS met once this week to discuss the Fedora 45 release schedule and a severe kernel vulnerability. Fedora 45 recently branched from Rawhide, and the team is preparing the necessary updates for coreos-installer and bootc images, alongside monitoring for F46 key signing issues in Rawhide.
The team also reviewed the recent "Zapscape" kernel vulnerability (CVE-2026-64561). They decided to issue an out-of-band kernel update for the testing and next streams to mitigate the issue for VM workloads immediately, rather than waiting for the scheduled stable release next week.
testing and next streams to address the Zapscape vulnerability (CVE-2026-64561) prior to the next scheduled stable release.See the detailed report for the CoreOS team.
Learn more about the CoreOS team.
During this week, the ARM group had a brief discussion regarding kernel availability for the Raspberry Pi 5. A community member inquired about a Fedora 44 (F44) kernel, noting the reliability of the current F43 kernel updates. It was confirmed that F44, F45, and Rawhide kernels are already available for the device in the existing COPR repository.
Learn more about the ARM team.
In their recent meeting, the Alternative Images group announced that RISC-V tags and targets have been successfully set up, representing a major first step toward creating new RISC-V images. Furthermore, Kiwi descriptions for RISC-V have been provided by Andrea.
The group is designating the upcoming week as "image week." During this time, they will conduct their regular quarterly image updates and officially begin generating RISC-V images specifically for QEMU virtual machines and P550 hardware.
Learn more about the Alternative Images team.
The AI & ML SIG met to discuss the upcoming ROCm 7.14 update for Fedora 46 and the use of the pi-coding-agent tool (available in Fedora 45) for automating day-to-day packaging review tasks. A major point of discussion was a proposal to split the AI/ML SIG into two distinct groups (packaging vs. end-user AI adoption). The group unanimously decided against the split, opting to maintain a "big-tent" approach while improving documentation to clarify roles. In other news, an all-new Electron RPM was submitted to unblock Podman Desktop in Fedora, alongside updates to Podman Desktop in COPR and a proof-of-concept Atomic Fedora CSB bootc image.
ai-ml-sig FAS group does not grant packaging commit rights, maintaining a clear security boundary for compliance efforts like the EU Cyber Resilience Act.See the detailed report for the AI & ML team.
Learn more about the AI & ML team.
The Fedora 45 RISC-V mass rebuild is 85% completed (around 20,000 packages), significantly aided by community members and Red Hatters who contributed new builders to parallelize the process. You can view the rebuild status numbers here. Other focus areas included investigating a failed LLVM build with RISC-V patches, co-writing Koji querying scripts, and exploring "Agentic SDLC" ideas for automated FTBFS triage and image boot testing.
A major challenge this week involved AI scrapers bringing down the Koji hub over the weekend, which resulted in numerous build failures.
See the detailed report for the RISC-V team.
Learn more about the RISC-V team.
The Security group held an open-floor meeting this week, where members discussed their roles, kernel maintenance, and the upcoming packaging of module-jail for Fedora. On the forums, a mass scan report from OpenScanHub was published for Fedora 45 Critical Path Packages, calling for maintainers to review AI-flagged security findings. Additionally, a complex architectural issue regarding systemd-run0 and SELinux was brought to the mailing list, with a request for community input on the best path forward.
module-jail and work to integrate it into the proper repositories as an opt-in security feature.See the detailed report for the Security team.
Learn more about the Security team.
The Go SIG met this week and primarily discussed the upcoming Go 1.27.0 release, which is expected soon alongside embargoed CVE patches for the 1.26 and 1.25 branches. The group also discussed architecture support, noting that i686 (32-bit x86) builds are increasingly being excluded from specific packages, though linux/386 remains a first-class port in the Go ecosystem and cannot be entirely purged yet due to system dependencies.
See the detailed report for the Go team.
Learn more about the Go team.
This week, the PHP group received an update regarding an ongoing dependency resolution issue in EPEL where php-devel incorrectly pulls in php8.4-devel instead of the default PHP 8.3 stack. Remi Collet reported that although the package itself has been fixed, both the affected and fixed versions currently coexist in the EPEL-10.3 buildroot, meaning the issue remains unresolved.
Learn more about the PHP team.
This week, the Python group evaluated a provisional dependency patching macro to simplify package builds and discussed formalizing its behavior. They also reached consensus on an RFC to expand automatic python(abi) dependencies to all file types installed in Python library directories.
Additionally, discussions were opened regarding a migration strategy for the upcoming flit-core v4 release to ensure compatibility ahead of the Fedora 46 branch, and guidance was provided to packagers dealing with upstream applications that pollute the global Python namespace.
See the detailed report for the Python team.
Learn more about the Python team.
This week in Fedora, there were updates to the package review process and SCM request infrastructure, along with a multitude of package updates, soname bumps, and mass branching for Fedora 45.
createrepo_c, promising significantly faster execution and lower RAM usage.npm2rpm, providing new test packages for evaluating node dependency bundling.xkill already claimed by Artur Frenszek-Iwicki.separate_check config option and a system_monitor plugin, though manual side-tag builds were needed to bypass some Bodhi gating issues.Community members with hardware access or environments for testing can immediately contribute to quality assurance efforts across various groups without needing prior team membership. Testers are needed to validate Fedora 45 bare-metal and VM builds, monitor Rawhide for CoreOS key signing breakages, and test new out-of-band CoreOS kernel updates addressing Zapscape. Users with specific hardware can test kernels on Raspberry Pi 5 or prepare to test upcoming RISC-V and P550 alternative images. Additionally, general contributors can test pi-coding-agent in Fedora 45, evaluate the provisional Python %pyproject_patch_dependency macro, run the Home Server README image build, clone the experimental docs-fp-o-ci-test site builder, or evaluate the separate_check feature in Mock 6.8. Those experiencing performance drops on modern hardware can also assist the Quality team in debugging TuneD configuration profiles.
Developers and packagers can step up to adopt orphaned packages (such as python-avocado, evtest, bottles, and Zim), or sponsor new maintainers like Dirk Nehring (Ticket #13470 for rust-plotters-backend). There is a high demand for fixing Fails To Build From Source (FTBFS) issues during the Go 1.27.0 mass prebuild, RISC-V LLVM patches, and EPEL migrations. Scripting opportunities include refining mass rebuild scripts (Ticket #13428, PR #13051), improving Bodhi update checks (Ticket #13468), assisting with a test assets repository server, packaging Zig applications for Workstation, or designing UI-side Ansible tasks for Zabbix. Additionally, package maintainers should review the August 2026 OpenScanHub report to resolve static analyzer findings or take over the retrace.fedoraproject.org service.
Contributors with writing or visual design skills can pick up valuable tasks without deep technical setups. The Design team welcomes interns and new contributors to illustrate Community Personas or create event flyers using tools like Inkscape. Writers can restructure the Server post-installation guide into self-contained AsciiDoc topics, write Kickstart coverage for dnsmasq, clean up legacy wiki pages (Issue #43), fix documentation links like relval (Issue #61), or propose content to the AI/ML documentation (Issue #38). Contributors can also clear legacy pagure.io links from the Fedora Ansible repository comments. Translators, however, are asked to pause localization on Ptyxis until a new default Workstation terminal is finalized.
Anyone in the wider community can provide valuable feedback on overarching project governance, legal policies, and community advocacy. Open discussions seeking input include the Fedora Forge Usage Policy, the Innovation Lifecycle proposal, Workstation WG issue #520 regarding terminal emulators, and the overarching policy on packages containing AI-powered features. Legal experts can evaluate open-source licensing edge cases involving dynamic linking or draft the GPU Acceptable Use Policy (Issue #35), while SELinux experts can advise on systemd-run0 integration. Finally, all contributors are encouraged to share their Fedora-related expertise by submitting session proposals to the Everything Open 2027 conference before September 6, 2026.
fale )
on 2026-08-17 00:00:00 UTC
Over the last year, I’ve watched AI models and tools that find vulnerabilities in code take a central role in security industry communications. Every few weeks, a new product announcement promises impressive results, such as AI tools that detect SQL injection, spot memory corruption bugs, identify logic flaws at scale, or chain tens of known vulnerabilities together. This can be impressive for attack purposes, but it is more an interesting novelty than defensive security.
llaumgui )
on 2026-08-16 08:30:08 UTC
kevin )
on 2026-08-15 19:59:50 UTC
Another week gone by, hard to understand that it's almost fall here now. Here's a recap of things from this last week:
Fedora 45 has branched off of rawhide. rawhide is now marching toward Fedora 46. Overall the actual branching went pretty reasonably, a few minor issues. There was a lot of issues with the last minute dnf repos move change that landed hours before branching. This caused a lot of work to try and get a compose with it, without reverting. Perhaps we should make sure all changes that affect the compose process have to land a week or so before branching or will just be reverted.
Some minor things:
The new rawhide release in bodhi had 'f46' as it's branch name, but it was supposed to be 'rawhide' because this is used to match against the git branch. Easily fixed, but hopefully not something that happens next time.
The openh264 repo is a bit of a problem at branching time. We need things setup for the new rawhide before we can build it and sign it with the new key and send it out to cisco. The choice then becomes if we want it to just 404 (not be there) or redirect it to the fedora-45 one (which is signed by the fedora-45 key). I've done the latter for now and we are syncing the new rawhide build out. Hopefully updated early next week.
noarch_arches wasn't set on the new rawhide build tag in koji. I submitted a pr to fix the branching script for this case and it's corrected for f46-build
eln composes were not fully resigned by the new rawhide key, the docs around this process were not very clear, we should fix them for next time. However, eln is going to just move to their own seperate key, so we just don't have to worry about this next time.
Somehow fedora 44 base repos got their permissions messed up. I can only assume it was a script failing somewhere, but I've not been able to track it down. This meant that some mirrors deleted their f44 trees and then had to sync it again. Lots of unwanted churn when there's already a bunch of mirror churn due to the new branched compose and newly resigned rawhide.
It was suggested to me by John 'Warthog9' Hawley that we might want to look at moving our download servers to BBR. Bottleneck Bandwidth and Round-trip propagation time (BBR), is a tcp congestion control algorithm developed by Google. It's used by them at youtube and other places.
So, I switched our download servers over and... it seems to have resulted in a nice performance increase for mirrors syncing from the master mirrors.
We will see how it goes moving forward.
Managed to get in a few migrations this last week. There are now just 33 hosts left. Of those:
I am hoping to do the last 5 vmhosts next thursday (see below)
We have a plan for rabbitmq clusters (6).
zabbix is planned soon (2)
The last bastion server and logs server I also plan to do thursday.
The database servers ( 12 ) I plan to start on once we are in beta freeze for staging, then prod after we are out.
A few oddball ones will be hard to do now due to resource constraints (fedorapeople and torrent), so might defer them for now.
We will be doing a mass update/reboot/reinstall fest next week. Monday I am out on PTO (it's my b-day!). Tuesday will be staging, Wed a bunch of non outage causing things, and thursday the main event. Everything will get updated/rebooted, then I will reinstall the last 5 vmhosts and our last bastion server. Friday will be openshift clusters (but those should just not cause much notice).
The week after next we go into beta freeze. I have to say I have thought about doing away with them, but I find them a nice time to focus on other work and relax a bit. Faster is not always better.
So, of course I can't post one of these these days without talking about the scrapers. (Whats the collective noun for scrapers? :)
We were getting hit really hard last weekend and early this week, but... Ryan thought to fight ai with ai and had a LLM dig through a bunch of our logs for any patterns. It managed to come up with some patterns that we likely wouldn't have seen, but blocking those things has made a MASSIVE improvement. Basically it's like they aren't even there right now.
Load on the backend for src.fedoraproject.org that had started hovering at 180 or so is down under 1 pretty much all the time now. I know that this will not last and they will change their patterns, but it's nice to have some respite at least for a little while.
As always, comment on the fediverse: https://fosstodon.org/@nirik/117101412562880287
Yesterday I released replyfast version 0.4.0, which is a Python module to receive and send messages on Signal
You can install it via
python3 -m pip install replyfast
or
uv pip install replyfast
I have a script to help you to register as a device, and then you can send and receive messages. You can use the same script to re-register.
I also have a demo bot which shows both sending and rreceiving messages, and also how to schedule work following the crontab syntaxt.
scheduler.register(
"*/5 * * * *",
send_disk_usage,
args=(client,),
name="disk-usage",
)
replyfast is written using presage library, which does the actual work of communication via Signal protocol.
admin )
on 2026-08-14 17:22:24 UTC
Fedora 45 has several system-level changes that need testing on real hardware. The first test day up is GNOME 51, starting on 17 August, with more events planned for RPM 6.1, installation media and others. You can participate with a VM for most tests; some hardware-specific testing is more useful on a real machine.
Details are contained in this article.
Fedora 45 is bringing several changes that deserve testing beyond CI and automated test suites. Here are some of the bigger ones:
Automated tests catch regressions in known scenarios, but they won’t tell us if the new boot.iso works on your particular laptop, or if enforced RPM signature checking breaks a workflow nobody on the team thought of. We need people trying this on real machines and in real scenarios.
That’s what test days are for. A few days focused on a specific change, developers on Matrix to help debug, and anyone can show up and run through the test cases. You don’t need to be a Fedora QA expert. If you can install Fedora, reproduce a problem and report what happened, you can help.
At our July 20 Quality meeting (transcript), we went through the ChangeSet and picked out the changes that would benefit most from community testing. That turned into a planning ticket on Forge with individual tickets for each event.
GNOME 51 Desktop — August 17-21 is the first test day this cycle and it’s happening right now . Desktop, graphics, peripherals, core applications. If you’re reading this in time, jump in. (#GNOME_51_Desktop)
I18n test week —September 7-13 input methods, locales, keyboard layouts. . (#924)
RPM 6.1 — NSS support for user/group lookups is back, queries work again during transactions, new macro modifiers for packagers, and better rpmkeys verification output. Looks like a smooth update, but RPM touches everything — worth making sure nothing slipped through. (#917)
Installation media — boot.iso and live images, physical hardware, VMs. Try booting the new images on whatever hardware you have. Does the installer work? Does the live environment behave? (#918)
KDE — likely KDE 6.7. (#922)
Cockpit — it’s been years since the last Cockpit test day. (#920)
GRUB EFI / Confidential Computing — relevant mainly to specific hardware and VM environments. (#919)
The list isn’t final. We’re still looking at kmscon, OpenSSL 4.0, CoreOS, and Kernel 7.2. Keep an eye on testdays.fedoraproject.org for the current schedule.
Try upgrading your system to the latest packages. Boot the new boot.iso on physical hardware. Test suspend/resume, Wi-Fi, external displays, NVIDIA/AMD/Intel graphics, or whatever hardware you actually use. Each test day has a wiki page with specific test cases, but your own daily workflows are often where the interesting bugs hide.
You need a Fedora Account to report results. Pick a test day from the schedule, follow the wiki instructions, report through the test day app, and if you find something odd, come talk to us on Matrix in #test-day:fedoraproject.org.
The test day app itself is open source at quality/testdays-web on Forge. If something about it bugs you or you have an idea, file a ticket.
This doesn’t all have to come from us. If you maintain a package with a big change in F45, or you see something in the ChangeSet that you think needs broader testing — propose a test day. Create a ticket at forge.fedoraproject.org/quality/tickets, tag it “test days”, and tell us what you’d like to test. You don’t need test cases or wiki pages ready. The QA team will help with that.
Test days are focused events around specific changes, but testing Fedora is something you can do any day. fedora-easy-karma is a CLI tool that picks up testing updates already installed on your system and lets you submit karma to Bodhi right from your terminal. See the installation instructions to get started. Like the test day app, it’s an open source project hosted on Forge — feel free to report issues or suggest features.
Catch you in #test-day on Matrix.
Note about AI usage: I wrote this article myself. I used Claude (Anthropic) to significantly refine the grammar, wording, and sentence structure; the technical content and all claims are my own.
My tip for this week: search for more videos of Danny Leon’s amazing skate in front of the eclipse. If you speak German, the podcast about people believing in pseudoscience is great too.
Roadmap decisions rather than dates. - I find dates generally a bad smell and a throwback to quarterly thinking.
bcotton )
on 2026-08-12 12:00:00 UTC
We all like to think that we’re very rational and make decisions logically. We’re not and we don’t. Like it or not, we’re humans and that comes with emotions. Frustratingly, means our very rational decisions are often greeted by other people’s emotions.
People form attachments to identities, like being a user of or contributor to a project. Of course, they also form attachments to things both physical and abstract. When something goes away, they do not like it. We do not like it.
There are, of course, many rational reasons to take away something that people want and have grown accustomed to having. Many projects have long ago dropped support for the i386 CPU architecture because the hardware is less prevalent and they no longer want to bear the burden of testing and supporting a rarely-used architecture. Nobody is shipping new software for Windows 95 or Red Hat Linux 8 — those operating systems were out of date 25 years ago. You might stop hosting personal websites for contributors because that’s not a scarce resource anymore. Maybe you stopped funding travel scholarships because your donation streams have dried up.
No matter how rational your decision-making process, someone will be upset about the loss of something they hold dear. (If no one cares, maybe you should have made this decision long ago.) Of course, not all of the objections will be emotionally-driven. Most decisions will have rational arguments against them — if there is only one reasonable course of action, there’s no need for a decision, after all.
You don’t need to get unanimous buy-in for a decision to take something away. You do want to minimize the stress the decision causes. Here are some tips that I’ve learned over the years:
This post’s featured photo by Matthew Henry on Unsplash.
The post Be prepared for big feelings when you take something away appeared first on Duck Alignment Academy.
This outage impacts the copr-frontend and the copr-backend.
admin )
on 2026-08-11 14:00:00 UTC
Fedora 45 Mass Branching is currently in progress. Koji is unavailable for the duration of this process.
Once Mass Branching is complete, Rawhide will advance to Fedora 46, Koji will be re-enabled, and an announcement email will be sent to devel-announce@lists.fedoraproject.org.
If you are interested in following …
Across various Fedora groups, a major shared focus this week was preparing for the upcoming Fedora 45 release cycle, which included executing mass rebuilds, coordinating early manual validation testing, and finalizing change proposals ahead of the imminent branching deadline. Infrastructure transitions were another critical common item, particularly the project-wide effort to gather requirements for replacing Red Hat Bugzilla and the successful migration of source control requests from Pagure to Fedora Forge, which requires maintainers to update their fedpkg toolchains. Hardware architecture improvements were also prominent, with multiple groups dedicating resources to testing and expanding build capacities for ARM and RISC-V devices. On the community front, organizing teams focused heavily on preparations for the FrOSCon 2026 event, while several other groups—including Packaging and Diversity & Inclusion—chose to pause regular meetings or shift to ad-hoc structures to prevent organizer burnout. Finally, navigating the rise of Artificial Intelligence emerged as a cross-cutting theme, prompting discussions around user privacy, default opt-in policies for third-party packages, and strategies for local AI development.
Major workflow transitions are underway for Fedora contributors, starting with the planned decommissioning of Red Hat Bugzilla within the next six months. FESCo has opened a ticket tracker for planning and gathering requirements for a future Red Hat BugZilla replacement to document workflows impacted by this shift. Additionally, the fedora-scm-requests queue has officially migrated from Pagure to Fedora Forge following its scheduled start on August 5th. Maintainers must update to the new fedpkg version 1.48 to continue submitting new package and branch requests, as the old Pagure system is now obsolete. In other maintenance news, a final reminder was issued listing long-term FTBFS (Fails to Build From Source) packages slated for retirement from Fedora 45, urging maintainers to fix or seek exemptions for affected software. Finally, the Fedora RISC-V community is seeking testers for an updated Fedora 44 server image that features out-of-the-box support for SpacemiT K3 boards and improvements for K1 hardware.
For the broader Linux community, new guides are available detailing how to run Ollama locally with Podman on Fedora Linux for containerized, private AI development, and how to monitor your drive health with Performance Co-Pilot to prevent sudden data loss from failing NVMe or SSD drives. Lastly, a recent attendee shared a positive retrospective on developing with Fedora and their first Flock conference, highlighting the community's welcoming culture and the behind-the-scenes efforts of volunteers and sponsors.
Between August 3 and 9, 2026, the Council discussed a new user concern regarding the introduction of AI-powered features in third-party packages, highlighting the need for packaging guidelines around user privacy and opt-in defaults. The Council also continued reviewing the proposed Fedora Forge Usage Policy, incorporating community feedback into a new draft. Additionally, a temporary "private issues" workaround was proposed for Fedora Forge while native support is being developed upstream, sparking discussions on how the Council and other sensitive groups will handle private tracking.
See the detailed report for the Council team.
Learn more about the Council team.
This week, FESCo focused heavily on reviewing and voting on F45 and F46 Change Proposals, handling administrative tickets, and addressing updates policy exceptions. Several major Change Proposals were formally approved for Fedora 45, including the modernization of the ODBC Stack, enabling systemd-oomd and zram swap for CoreOS, and transitioning to Sequoia for openpgpverify. Conversely, the committee rejected the proposal to hardcode nss-altfiles in authselect profiles, encouraging further collaboration among affected initiatives like CoreOS and atomic bootc.
In addition to changes, FESCo initiated a project-wide requirements gathering phase for Fedora's eventual Bugzilla replacement. They also approved an urgent updates policy exception for thermald to resolve power management issues on newer Intel laptops, and handled several non-responsive maintainer tickets to ensure long-term package health.
See the detailed report for the FESCo team.
Learn more about the FESCo team.
The Packaging Committee held a brief meeting this week. The agenda was notably light, with no new tickets submitted for review. The only active item mentioned was a work-in-progress pull request for Node.js. Due to upcoming vacations for key members, the committee agreed to suspend meetings for the rest of August.
See the detailed report for the Packaging Committee team.
Learn more about the Packaging Committee team.
Mindshare held a brief meeting this week but concluded early due to a lack of quorum. Despite the early adjournment, organizers noted ongoing progress on various tickets and highlighted upcoming events, specifically FrOSCon and Data Con LA.
Additionally, community members are actively organizing the Fedora presence for FrOSCon 2026. The project booth is confirmed and swag items are being gathered, alongside an open call for volunteers to assist at the booth and share their work with attendees.
See the detailed report for the Mindshare team.
Learn more about the Mindshare team.
The Ambassadors group focused entirely on final preparations for the Fedora booth at FrOSCon 2026, which takes place August 15-16 near Bonn, Germany. The team has successfully secured a booth space, promotional materials, and a new tablecloth, and they are actively seeking volunteers and project showcases from the community to help run the event.
See the detailed report for the Ambassadors team.
Learn more about the Ambassadors team.
The Diversity & Inclusion group is putting its regular team meetings on hiatus to prevent organizer burnout and shift focus toward concrete, event-driven goals. Discussion in the "Time to take a break?" thread confirmed that regular meetings have become stagnant without specific deliverables, and organizers will now lean into forming ad-hoc teams for events like the Fedora Mentor Summit, Fedora Week of Diversity, and Fedora Appreciation Week.
Calendar entries for the regular DEI meetings are being removed, but this will not halt ongoing initiatives. Future activities will be organized through dedicated calls for volunteers and planned in their respective event repositories.
See the detailed report for the Diversity & Inclusion team.
Learn more about the Diversity & Inclusion team.
The Workstation Working Group discussed upcoming upstream GNOME changes, including plans for GNOME 52+ to replace GNOME Software with a Flatpak-focused installer called "Bazaar" and a new system updater, though Fedora will stick with GNOME Software for the time being. The group also evaluated newly integrated features like the IBus speech-to-text functionality, noting performance delays and missing default models, and reviewed the transition of GNOME Boxes to a Flatpak-only application which currently requires further polish on fractionally scaled screens.
On the forum side, community members engaged in a technical discussion regarding Btrfs RAID1 and nodatacow files (such as Libvirt virtual machine images), proposing theoretical file system mechanisms to ensure data recoverability during bit rot without full metadata checksumming.
See the detailed report for the Workstation / GNOME team.
Learn more about the Workstation / GNOME team.
The KDE group discussions this week focused on a user-reported issue regarding computer freezes under Plasma (Wayland) after upgrading to Fedora 44. The system becomes unresponsive during screen lock, with the nvidia-modeset/kthread_q process consuming 100% of the CPU, requiring a sysreq reboot to resolve.
See the detailed report for the KDE team.
Learn more about the KDE team.
This week, the Server Working Group officially reached quorum with the addition of new members and made progress on release testing and automation infrastructure. Discussions centered heavily on upcoming Fedora 45 changes, identifying bugs in VM and ARM partition types, and reviewing default packages to prevent unnecessary bloat in server environments.
The group also advanced its Ansible support project by merging initial post-installation modules and beginning work on a CI pipeline using self-hosted Forge runners. Furthermore, the WG continued refining its documentation structure, debating the best ways to present post-installation configuration tasks to users.
See the detailed report for the Server team.
Learn more about the Server team.
The Infrastructure team was highly active this week, handling multiple system migrations, upgrades, and investigating service anomalies. Key efforts included advancing the RHEL 10 migrations for miscellaneous hosts, rolling out OpenID Connect enrollment for the Release Schedule Planner, and addressing intermittent authentication issues following the recent IPA cluster reinstall. The team also announced an upcoming scheduled outage for the Copr servers and discussed transitioning Matrix moderation duties to official Fedora infrastructure, including a formalized policy for official Matrix rooms.
Additionally, developers introduced substantial updates to Tahrir, the Tahrir API, and Forgejo, improving performance and enabling new features like private issue tracking in the forge environment. Investigations were also launched into src.fedoraproject.org 503 errors caused by heavy scraper activity and Fedora mailing list emails being falsely flagged as spam by the SpamHaus blocklist.
@moderation:fedoraproject.org).:fedoraproject.org room alias, and appropriate sub-space assignment.netfyr and sosreport.See the detailed report for the Infrastructure team.
Learn more about the Infrastructure team.
This week, the Release Engineering team focused heavily on infrastructure migrations and preparations for the Fedora 45 release cycle. A major milestone was the successful migration of the scm-requests repository from Pagure to Forgejo on August 5th, which necessitates that community members update their fedpkg utilities to version 1.48 or greater. The team also began extensive preparations for the F45 mass branching scheduled for August 11th, which included executing the mass re-signing of F45 content with the new F46 key.
In addition to release cycle preparations, the group handled various system and package fixes. They deployed a fix to prevent releng-bot from pinging unrelated users during SCM requests, resolved an issue where ELN packages were signed with the wrong key, and bypassed a Bodhi sidetag limitation affecting shadow-utils. Multiple package unretirement and stalled maintenance requests were processed, and the team highlighted that unretirements can now be executed directly via the updated fedpkg CLI without requiring a ticket.
fedora-scm-requests repository was officially migrated from Pagure to Forgejo; maintainers must update to fedpkg v1.48 or greater to submit new package and branch requests.fedpkg request-unretirement command.forge-releng-scm-validators group to handle SCM request approvals, preventing releng-bot from unnecessarily pinging unrelated community members.quay.io/fedora/eln-bootc repository to enable the uploading of ELN bootc images from composes.See the detailed report for the Release Engineering team.
Learn more about the Release Engineering team.
The Quality team focused heavily on early manual validation for Fedora 45 this week, placing a special emphasis on ARM devices to catch significant bugs before the branch and freeze periods. The team is also actively organizing the next round of Fedora Test Days and collaborating with the Data team to identify interesting QA and build metrics—such as Bodhi karma and Koji completion rates—for future data visualizations.
In addition to testing, the group discussed hardware monitoring defaults, noting that the mcelog daemon consistently fails on modern AMD CPUs. They are currently gathering community feedback on potentially replacing it with rasdaemon. Tooling improvements were also a major theme, with updates to fedora-easy-karma, a revived issuebot in staging, and discussions around deploying a shared test asset server for openQA and Fedora CI.
mcelog daemon with rasdaemon by default due to hardware incompatibility on modern CPUs.See the detailed report for the Quality team.
Learn more about the Quality team.
The Design team concluded the community poll for the Fedora 46 wallpaper inspiration, selecting American mathematician Karen Uhlenbeck as the winner. Following the poll, the team is organizing a mind map meeting to brainstorm the wallpaper's conceptual design. In other activities, community members shared a proposed wallpaper on the mailing list, and drafts for revamped Design Documentation pages were posted for review.
See the detailed report for the Design team.
Learn more about the Design team.
The Internationalization (i18n) group held a meeting this week to review the progress of Fedora 45 changes and coordinate upcoming release deadlines. Key discussions involved tracking the completion of F45 changes, ongoing bug triaging efforts for Fedora 43, and scheduling the upcoming internationalization test week.
See the detailed report for the Internationalization team.
Learn more about the Internationalization team.
This week, the EPEL group focused significantly on improving the repository structure and mirror paths for EPEL 11 to avoid user errors during mirroring and upgrades. The steering committee successfully voted to adopt a new "de-z-ification" policy for EPEL 11, which will rely on the $stream variable for CentOS Stream users rather than adding a 'z' suffix for RHEL minor versions. Additionally, the community discussed potential breaking updates to packages like certbot, uv, and ruff in EPEL 10, and highlighted a new way to track RHEL lifecycle milestones via the Red Hat Insights roadmap.
$stream variable for CentOS Stream rather than the $releasever_minor 'z' suffix for RHEL systems.11s.See the detailed report for the EPEL team.
Learn more about the EPEL team.
The ELN SIG met this week to discuss significant updates to their build pipeline and image generation processes. Key highlights include the production deployment of ELNBuildSync 2.0.1, the inclusion of bootc images in standard composes, and the successful migration of all major cloud images (EC2, Azure, GCE, qcow2) to image-builder.
Additionally, the group discussed restructuring ELN variants, introducing a new AltImages variant for live images and a new Extensions variant to decouple RHEL Extensions from EPEL. Plans were also outlined to completely split ELN Extras into its own target to cleanly bootstrap EPEL N+1 and preview CentOS SIGs, with a call for community feedback on the design.
image-builder following the successful migration of hyperscaler cloud images.go-vendor-tools and cut a new release.See the detailed report for the ELN team.
Learn more about the ELN team.
The Fedora Atomic Initiative met this week to discuss infrastructure updates and package releases. Progress was made on configuring Konflux service accounts for the Fedora Forge, with a new merge request proposed to unblock testing. Additionally, a recent policy change for the bootc package means that Bodhi updates now only require a +1 score to proceed, which should clear up the backlog of aging updates. In release news, bootc 1.16.6 has reached the stable repository, and work is underway for the 1.16.7 release.
bootc package now only require a +1 score to proceed, which will prevent updates from sitting in the backlog until they become obsolete.See the detailed report for the Atomic team.
Learn more about the Atomic team.
CoreOS held a meeting on August 5 to review ongoing action items and prepare for the upcoming Fedora 45 branching. Key discussions included ongoing tests for the /boot partition size to prevent data corruption during re-provisioning, preparations for the Fedora 45 Test Day, and the integration of approved FESCo changes into Rawhide. Additionally, the team discussed the pending archival of the Butane repository into Ignition.
See the detailed report for the CoreOS team.
Learn more about the CoreOS team.
This week, the AI & ML group focused on administrative tasks, specifically processing a membership update. A contributor requested to be removed from the group and related access lists due to time constraints and the challenges associated with packaging complex upstream AI projects. The request was completed, and the contributor was successfully removed from the relevant groups.
salimma from the AI/ML and PyTorch Special Interest Groups (SIGs).See the detailed report for the AI & ML team.
Learn more about the AI & ML team.
The RISC-V group focused primarily on the ongoing Fedora 45 mass rebuilds, successfully resolving a major Python 3.15 Beta 4 ABI breakage and completing the bootstraps for Perl 5.44 and Rust. Rebuilds for OCaml have started, with Golang and R queued up next.
Significant hardware additions were made to the build pool, including five Milk-V Titan (DP1000) machines and four SpacemiT K3 systems, to improve build capacity. The team also addressed hardware instability challenges with SpacemiT K1/K3 SoCs linked to vector instructions and OpenSBI issues, and discussed a gnulib/glibc conflict that required a workaround.
See the detailed report for the RISC-V team.
Learn more about the RISC-V team.
This week, the Security group discussed recognizing vulnerability reporters with a dedicated Fedora badge and evaluating compliance with the linux-distros mailing list rules. In the forums, a community review of the new Fedora-maintained hardening documentation led to minor improvements, while the OpenScanHub team published their latest static analyzer findings for Fedora 45 critical path packages.
See the detailed report for the Security team.
Learn more about the Security team.
The DotNET group confirmed the final steps for the end-of-life (EOL) transition for .NET 8 and .NET 9. Omair Majid announced that the dotnet8.0 and dotnet9.0 packages will be dropped from Rawhide shortly, timed to occur just before the Fedora 45 branch day on August 11, 2026.
While they are being removed from Rawhide, both versions will remain available and continue to receive updates in existing Fedora versions (up to Fedora 44) until their official EOL in November 2026. Michael Cronenworth acknowledged the change, noting that Jellyfin 12 is currently on the horizon with release candidates available.
dotnet8.0 and dotnet9.0 packages will be dropped from Rawhide ahead of the Fedora 45 branch day.See the detailed report for the DotNET team.
Learn more about the DotNET team.
This week, the Perl group focused heavily on routine package maintenance, consisting of upstream version bumps and importing packages into EPEL branches. Key updates included merging newer releases for packages like perl-ExtUtils-CppGuess, perl-PDF-Reuse, perl-HTTP-Cookies, perl-Crypt-SMIME, and perlbrew. Additionally, successful efforts were made to integrate perl-Protocol-WebSocket into EPEL8 and EPEL9, alongside establishing the first EPEL10 build for perl-SQL-Abstract.
See the detailed report for the Perl team.
Learn more about the Perl team.
Vít Ondruch announced that following the recent landing of Ruby on Rails 8.1 in Fedora, an update for version 8.1.3.1 was also released this week. The community is encouraged to test these new releases and report any issues they might encounter.
See the detailed report for the Ruby team.
Learn more about the Ruby team.
This week in the Fedora community, discussions focused on transitioning away from Red Hat BugZilla, establishing style guides for mailing lists, and managing the email volume on the devel list. Additionally, there were multiple package soname bumps, discussions about orphaning outdated packages, and warm welcomes to several new package maintainers.
Contributors with testing and quality assurance skills can easily jump into numerous highly accessible opportunities. The community is invited to test the Packager Dashboard staging environment and report bugs on its issue tracker. Testers are also needed for Fedora 45 manual validation (especially on ARM), F45 Server bare-metal/VM images, fedpkg v1.48+ features, Flatpak-only GNOME Boxes on fractionally scaled displays, newly landed Ruby on Rails 8.1, dotnet10.0, and Atomic's bootc 1.16.6. Hardware owners can evaluate /boot partition scenarios (notes), test Omni F44 images on SpacemiT K1/K3 or Milk-V Titan, and assist with testing LLVM pull request 629. Additional opportunities include Fedora 43 i18n bug triaging and contributing to Test Day planning.
For those with strong communication, writing, or organizational skills, community feedback is actively sought on the Fedora Forge Usage Policy, the AI-powered features policy, and hardware monitoring defaults (mcelog vs. rasdaemon). Contributors can submit user stories to the FESCo Bugzilla replacement tracker, restructure Server post-installation guides, or review Design Processes documentation. Event enthusiasts can volunteer for the FrOSCon 2026 booth, give talks, create A4 teaser pages for project showcases, or join organizing efforts for Fedora Week of Diversity, Appreciation Week, and the Mentor Summit.
Developers, designers, and system architects can tackle highly specific technical challenges across the project. Programmers can debug memory leaks in GNOME's new IBus speech-to-text, troubleshoot KDE Plasma Wayland screen lock freezes with NVIDIA drivers, and investigate OpenSBI bugs on RISC-V K1/K3 SoCs. System architects are invited to help design the ELN and ELN Extras separation (Issue #61 and Issue #62). Designers can streamline GNOME's action dialog buttons, design the Vulnerability Reporting Badge, or join #design:fedoraproject.org for the Fedora 46 wallpaper brainstorm. Data enthusiasts can also suggest QA-related data visualizations.
Contributors experienced in package maintenance and systems administration can make an immediate impact by adopting orphaned or non-responsive packages such as nextcloud-client, rust-zoxide, cinnamon-screensaver, and python-pivy, or by helping the AI & ML group package PyTorch. Packagers are also needed to resolve Failing to Install (FTI) EPEL packages, test EPEL 10 uv and ruff updates, minimize go-vendor-tools dependencies, and apply OpenScanHub security patches. Systems administrators can write Server Ansible roles, configure self-hosted Forge runners, and help implement RPM macro and Lua support for the Fedora 45 PURL proposal.
admin )
on 2026-08-10 08:00:00 UTC
You wake up one morning to find your home server unresponsive, after some investigation you discover a failed NVMe drive taking your self-hosted services and data with it. Perhaps you’re a system administrator and a workstation’s SSD has been silently accumulating errors for months, and now a user is reporting corrupted files.
Drive failures are rarely instant, they give subtle warnings (through rising temperatures, increasing error counts, and wear indicators) but only if you’re watching. Most people will only check on disk health after problems start, by then it may be too late.
Performance Co-Pilot (PCP) is an open source framework for collecting, monitoring, and analyzing system performance metrics. Recent updates have expanded its drive monitoring capabilities with:
In this post, you’ll set up PCP drive monitoring on Fedora, learn which metrics matter most, and build a Grafana dashboard to visualize your drive health over time.
To follow along, you’ll need:
You can verify smartmontools is available:
$ rpm -q smartmontools
If it’s not installed:
$ sudo dnf install smartmontools
SMART (Self-Monitoring, Analysis and Reporting Technology) is a monitoring system built into modern hard drives, SSDs and NVMe devices. SMART continuously tracks indicators like wear leveling, error rates, temperature and power-on hours. These are reliability metrics that can help point towards impending failures.
Most people only check SMART data once, using tools like smartmontools (smartctl -a /dev/sda) and only when they already suspect a problem. That approach only gives you a single snapshot. PCP takes a different approach: its SMART agent collects these metrics continuously in the background, building historical trends that you can analyze.
Did your drive’s temperature spike yesterday during a large file transfer? Has your NVMe wear indicator increased from 5% to 15% over the past six months? Continuous monitoring catches these patterns. Drive failures rarely happen without warning, clues are given through SMART values that shift over time.
Getting started is straightforward. Install the required packages:
$ sudo dnf install pcp pcp-pmda-smart
The pcp-pmda-smart package provides the SMART monitoring agent. Next, install the PMDA (Performance Metrics Domain Agent):
$ cd /var/lib/pcp/pmdas/smart/ $ sudo ./Install
The installer will prompt for configuration options. The defaults work well for most setups, so press Enter to accept them.
Start and optionally enable the PCP collector daemon:
$ sudo systemctl start pmcd $ sudo systemctl enable pmcd
Verify the SMART metrics are available:
If you see metrics listed, you’re ready to go.
Now that monitoring is running, let’s look at the metrics that matter most.
Drive temperature is one of the easiest health indicators to track. Query it with:
$ pminfo -ft smart.attributes.temperature_celsius.value
For NVMe drives, use:
$ pminfo -ft smart.nvme_attributes.temperature_sensor_one
As a general guideline: sustained temperatures above 60 °C for HDDs or 70 °C for SSDs and NVMe drives indicate potential cooling problems. Consistent high temperatures accelerate wear and reduce drive lifespan.
To watch temperatures update in real time (every 5 seconds):
$ pmrep -t 5s smart.nvme_attributes.temperature_sensor_one smart.attributes.temperature_celsius.value
Press Ctrl+C to stop.
Every drive has a finite lifespan. These metrics help you track where a drive is in its lifecycle.
Power-on hours tracks total runtime:
$ pminfo -ft smart.attributes.power_on_hours.value $ pminfo -ft smart.nvme_attributes.power_on_hours # NVMe
A drive with 50,000 hours (roughly 5.7 years of continuous operation) is significantly older than one with 5,000 hours.
Power cycle count shows how many times the drive has been powered on and off:
$ pminfo -ft smart.attributes.power_cycle_count.value $ pminfo -ft smart.nvme_attributes.power_cycles # NVMe
Excessive power cycling can accelerate mechanical wear in HDDs and contribute to flash cell wear in SSDs.
For NVMe drives, smart.nvme_attributes.percentage_used is the most important wear metric. It runs from 0 to 100%, reflecting the drive’s consumed endurance. Above 80% means significant wear. Above 90%, start planning a replacement.
$ pminfo -ft smart.nvme_attributes.percentage_used
These are the metrics you hope stay at zero. Any non-zero value or an increasing trend points to physical drive problems.
Reallocated sector count shows bad sectors that the drive has detected and remapped to spare areas. Modern drives reserve sectors for this purpose but once remapping starts it signals deteriorating media:
$ pminfo -ft smart.attributes.reallocated_sector_count.value
Current pending sector count tracks sectors waiting to be remapped. A non-zero value suggests the drive is actively struggling with bad areas:
$ pminfo -ft smart.attributes.current_pending_sector.value
For a quick overview of all drives at once:
$ pmrep -s 1 smart.health smart.attributes.temperature_celsius.value smart.nvme_attributes.temperature_sensor_one smart.nvme_attributes.percentage_used
A common challenge with drive monitoring is that device names can change. Your NVMe drive might be /dev/nvme0n1 today but after a reboot or BIOS update it could become /dev/nvme1n1. Hot-plugging USB drives or adding new storage can also shuffle device assignments.
PCP solves this with the smart.wwid.* metric namespace. WWID (World Wide Identifier) is a unique identifier assigned to each drive during manufacturing. It never changes regardless of how the operating system names the device.
Here’s the difference in practice:
The WWID-based namespace is particularly useful for multi-drive setups (home lab servers, workstations with external drives, or laptops with docking stations). Your monitoring history stays consistent even when device names don’t.
Beyond standard SMART attributes, NVMe drives maintain a detailed error log (log page 0x01) that records every error event the drive encounters. The SMART PMDA can collect and decode these logs giving you visibility into issues that basic SMART counters won’t reveal.
While smart.nvme_attributes.media_and_data_integrity_errors gives you a count, the error log tells you what happened, when it happened, and where on the drive it occurred. Each log entry includes:
This level of detail helps diagnose intermittent problems. Maybe your NVMe drive only throws errors under specific workloads or errors cluster in a particular address range.
Query the error log metrics:
$ pminfo -ft smart.nvme_error_log
The most important metric is smart.nvme_error_log.error_count which should be zero on a healthy drive. If you see non-zero values, check smart.nvme_error_log.status_code for human-readable error descriptions. Common error codes include:
Recurring errors, especially with the same status code or affecting the same LBA range indicate a real problem that needs attention.
If you have Seagate drives, PCP offers additional monitoring through the FARM (Field Accessible Reliability Metrics) PMDA. FARM is Seagate’s extended monitoring that goes beyond standard SMART, providing deeper insights into drive behavior.
FARM logs capture operational data that SMART doesn’t track:
FARM support works for both SATA and SAS Seagate drives. Install and enable it:
$ sudo dnf install pcp-pmda-farm $ cd /var/lib/pcp/pmdas/farm/ $ sudo ./Install
Query available FARM metrics:
$ pminfo farm | head -10 farm.smart_attribute.power_on_hours farm.environment.current_temperature farm.reliability.uncorrectable_read_errors farm.reliability.uncorrectable_write_errors ...
FARM is especially useful for tracking long-term health trends, diagnosing subtle issues not visible in basic SMART data and verifying that drive specifications match actual usage.
Note: FARM metrics are Seagate-specific. They won’t work with Western Digital, Samsung, or other manufacturers. For universal monitoring use the SMART PMDA covered earlier.
PCP integrates with Grafana through the grafana-pcp plugin, letting you build dashboards that visualize drive health over time. This is where continuous monitoring pays off. You can spot trends, set up alerts and keep an eye on your entire fleet of drives from a single dashboard.
Install Grafana and the PCP plugin:
$ sudo dnf install grafana grafana-pcp
Start the required services:
$ sudo systemctl start grafana-server pmproxy $ sudo systemctl enable grafana-server pmproxy
Open Grafana in your browser at http://localhost:3000 (default credentials: admin/admin).
Before adding a datasource, you may need to enable the Performance Co-Pilot plugin. Go to Administration > Plugins and data > Plugins, search for Performance Co-Pilot, and click Enable. If the plugin is already enabled, you can skip this step.
Go to Connections > Data sources > Add data source and select PCP Vector. The only required field is the URL:
http://localhost:44322
Click Save & Test to verify the connection.
Below are panel configurations you can use in your dashboards. To add a panel, click Add > Visualization on any dashboard, select the PCP Vector datasource and enter the metric name in the query field.
Drive temperature timeseries panel:
This panel shows drive temperature over time, with color thresholds for warning levels.
{
"type": "timeseries",
"title": "Drive Temperature",
"datasource": {
"type": "pcp-vector-datasource",
"uid": "PCP_VECTOR"
},
"targets": [
{
"expr": "smart.nvme_attributes.temperature_sensor_one",
"format": "time_series"
},
{
"expr": "smart.attributes.temperature_celsius.value",
"format": "time_series"
}
],
"fieldConfig": {
"defaults": {
"unit": "°C",
"thresholds": {
"mode": "absolute",
"steps": [
{ "color": "green", "value": null },
{ "color": "yellow", "value": 50 },
{ "color": "orange", "value": 60 },
{ "color": "red", "value": 70 }
]
},
"custom": {
"thresholdsStyle": { "mode": "area" }
}
},
"overrides": [
{
"matcher": { "id": "byType", "options": "number" },
"properties": [
{ "id": "unit", "value": "°C" }
]
}
]
},
"gridPos": { "h": 8, "w": 24, "x": 0, "y": 0 }
}
NVMe wear percentage gauge panel:
A gauge showing how much of each NVMe drive’s endurance has been consumed.
{
"type": "gauge",
"title": "NVMe Wear Level",
"datasource": {
"type": "pcp-vector-datasource",
"uid": "PCP_VECTOR"
},
"targets": [
{
"expr": "smart.nvme_attributes.percentage_used",
"format": "time_series"
}
],
"fieldConfig": {
"defaults": {
"unit": "percent",
"min": 0,
"max": 100,
"thresholds": {
"mode": "absolute",
"steps": [
{ "color": "green", "value": null },
{ "color": "yellow", "value": 50 },
{ "color": "orange", "value": 80 },
{ "color": "red", "value": 90 }
]
}
},
"overrides": [
{
"matcher": { "id": "byType", "options": "number" },
"properties": [
{ "id": "unit", "value": "percent" }
]
}
]
},
"gridPos": { "h": 6, "w": 8, "x": 0, "y": 8 }
}
Drive health status panel:
A stat panel showing the overall health assessment for each drive.
{
"type": "stat",
"title": "Drive Health Status",
"datasource": {
"type": "pcp-vector-datasource",
"uid": "PCP_VECTOR"
},
"targets": [
{
"expr": "smart.health",
"format": "time_series"
}
],
"fieldConfig": {
"defaults": {
"unit": "string",
"mappings": [
{
"type": "value",
"options": {
"PASSED": { "text": "PASSED", "color": "green" },
"FAILED": { "text": "FAILED", "color": "red" }
}
}
]
},
"overrides": [
{
"matcher": { "id": "byType", "options": "string" },
"properties": [
{ "id": "unit", "value": "string" }
]
}
]
},
"gridPos": { "h": 6, "w": 8, "x": 8, "y": 8 }
}
A complete, importable Grafana dashboard JSON file is provided alongside this post as pcp-drive-monitoring-dashboard.json. Import it via Dashboards > Import in Grafana.
PCP includes pmie (Performance Metrics Inference Engine), a rule-based tool that evaluates metric expressions and triggers actions when conditions are met. Where Grafana dashboards require someone to be watching pmie can alert you automatically.
To start and optionally enable pmie:
$ sudo systemctl start pmie $sudo systemctl enable pmie
Before writing alerting rules you can use pmie in verbose mode to view metrics from the command line. This is a useful way to get familiar with the syntax:
$ echo 'temp_check = smart.nvme_attributes.temperature_sensor_one;' | pmie -e -v -t 5second temp_check (Mon Jun 30 10:15:01 2026): 35 temp_check (Mon Jun 30 10:15:06 2026): 35 temp_check (Mon Jun 30 10:15:11 2026): 36
Press Ctrl+C to stop. The -e flag shows the evaluated expression, -v shows values even when no action fires, and -t sets the evaluation interval.
You can add conditions and actions to turn this into a rule. Here’s an example that prints a message whenever an NVMe drive’s temperature is above 0 (effectively showing all drives):
$ echo 'temp_check = some_inst(smart.nvme_attributes.temperature_sensor_one > 0) -> print "NVMe temp:" " %i:%v";' | pmie -e -v -t 5second Mon Jun 30 10:15:01 2026: NVMe temp: nvme0n1:35 temp_check (Mon Jun 30 10:15:01 2026): true Mon Jun 30 10:15:06 2026: NVMe temp: nvme0n1:36 temp_check (Mon Jun 30 10:15:06 2026): true
The %i token expands to the instance name (the drive) and %v to the metric value.
Now let’s create practical rules that alert on real problems. Save the following to /etc/pcp/pmie/smart-health.pmie:
// Alert if any NVMe drive temperature exceeds 70 °C
some_inst(smart.nvme_attributes.temperature_sensor_one > 70)
-> syslog 10 min "NVMe drive temperature critical:" " %i at %v °C";
// Alert if any NVMe drive wear level exceeds 80%
some_inst(smart.nvme_attributes.percentage_used > 80)
-> syslog 24 hour "NVMe drive wear level high:" " %i at %v%";
// Alert if any drive has reallocated sectors
some_inst(smart.attributes.reallocated_sector_count.value > 0)
-> syslog 24 hour "Drive has reallocated sectors:" " %i with %v sectors";
The syslog action writes to the system log with the tag pcp-pmie. The time after syslog (e.g., 10 min, 24 hour) is a throttle that prevents repeated alerts, so you won’t flood your logs if a condition stays true.
Test your rules from the command line first:
$ sudo pmie -v -c /etc/pcp/pmie/smart-health.pmie -t 10second
This evaluates the rules every 10 seconds and prints verbose output so you can see them firing. Once you’re happy with the rules you can run pmie as a persistent service. The system-wide pmie instance is managed by pmie_check and configured in /etc/pcp/pmie/control. Add an entry pointing to your rules file to have them evaluated continuously alongside the default PCP rules.
A complete smart-health.pmie rules file covering temperature, wear and error alerts for both NVMe and SATA drives is provided alongside this post in the conclusions section. Copy it to /etc/pcp/pmie/ to get started.
Other actions are available beyond syslog. Use shell to run arbitrary commands (such as sending an email or desktop notification), print for stdout output or chain actions with & to run multiple actions when a rule fires.
pmlogger is a core utility included with PCP, and automatically logs metrics when running. To start it and enable it on boot:
$ sudo systemctl start pmlogger $ sudo systemctl enable pmlogger
By default, pmlogger captures a broad set of system metrics. To ensure SMART drive metrics are included, run:
$ sudo pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
When prompted, enable the S.M.A.R.T drive statistics [Linux] group. This ensures drive health metrics are captured continuously, allowing you to review historical trends using tools like pmchart, pmrep, or Grafana with the PCP Valkey datasource.
With pmlogger running, you build a historical record of your drive health. If a drive starts failing in six months, you can look back and see exactly when the warning signs began.
Drive failures give warnings, through SMART metrics, error logs and performance degradation. With PCP’s drive monitoring capabilities you have the tools to catch these warnings before they become data loss.
In this post we covered setting up the SMART PMDA for universal drive health monitoring, interpreting key metrics like temperature, wear levels, error counts and tracking drives reliably with WWID-based identifiers. NVMe users can go deeper with error log collection and Seagate drive owners have access to extended FARM telemetry. Combined with Grafana dashboards and pmlogger you get continuous visibility into your drives’ health.
The key takeaway: continuous monitoring catches trends that one-time checks miss. A few minutes of setup today can save hours of recovery work (or worse, unrecoverable data loss) tomorrow.
For more information, visit the Performance Co-Pilot documentation and the grafana-pcp plugin documentation. The Grafana dashboard used in this post is available to download here and can be imported via Dashboards > Import in Grafana. The pmie alerting rules are also available to download here and can be copied to /etc/pcp/pmie/ for use with pmie.
Because artificial intelligence competes with humans, especially for our planet’s resources, I’ve chosen my side: the human.
I also think that AI is terribly bad for what should be our priorities:
Everything on my website, in my repository, in my personal work, and my contributions to the Open Source community is the result of my skills and my experience. No AI is used; no AI will be used.
Yes, I'm aware that AI may help in some projects (e.g., medical diagnostics, live translation), but I don't think the benefits outweigh the costs.
Yes, this is very political.
You can read Artificial Intelligence Controversies or Why No AI?
Another saturday spent dealing with scrapers, so now time for a recap of the previous weeks events.
I am not sure if they have some reason for hitting on saturday mornings, but they did so again this week. Once again targeting src.fedoraproject.org, which is unfortunate in that it's a single backend server without much ability to scale horizontally, running rhel8 and since we are moving away from it someday soon we don't want to spend too much time on it.
So, the two approaches left for me here are:
Block/filter/delay/cache at the proxy level to keep traffic managable
make the single backend process requests better/faster to keep up
I tried a number of things this time and ended up with a combo. Some things increased and blocked on proxies and the backend tweaked and given more cpu/memory. I'm not sure if this is going to last, but for now things seem to be back to 'normal'.
I am hopeful we can scale forgejo much better here. It's running in openshift and we have a lot more options there.
A bunch more hosts done this last week. I have about 3 more 'easy' ones to finish up and then we will get to ones that will need an outage. (database servers, vmhosts that host important services, etc).
Next week is Fedora 45 branching, so will keep things quiet, but I am tenatively thinking about a mass update/reboot cycle + rhel10 migrating things the week after. Will see how much I can line up next week. It would be good to get as much done as we can before we head into freeze the week after.
The rest of the week has been a blur. :)
As always, comment on the fediverse: https://fosstodon.org/@nirik/117061938567047801
renich )
on 2026-08-07 13:00:00 UTC
Let us be real for a moment: we have all been burned by AI hallucinations.
You sit down, ask an LLM to write a helper script or refactor an awkward class, and it hands back something that looks strikingly professional. The indentation is crisp, variable names are elegant, and docstrings read like poetry. You compile it, and... kaboom.
The model confidently imported a non-existent package, called an API method that exists only in its imagination, and invented three CLI flags out of thin air. It stared right into your terminal and insisted with absolute conviction that everything was tested and ready to ship.
If you have ever caught an AI model quietly lying about compiler output, you know the feeling. Trusting an LLM to blindly hallucinate its way through code generation is a speedrun to broken builds and late-night debugging sessions.
Warning
Blindly copy-pasting LLM code without verifying imports, checking types, or running strict linters is how phantom dependencies and swallowed exceptions sneak into production.
The standard industry reaction is to clip the model's wings—turn down temperature, tighten context windows, and treat every output with extreme suspicion.
Yet the core issue might not be that the AI sees ghosts, but where we tell it to look.
When you force a language model to hallucinate code logic, it invents fake syntax. But when you ask it to hallucinate a human being, the dynamic shifts completely.
Instead of prompting an AI assistant to "write a module," step back and ask it to imagine someone using your software.
Let us call him Gus. Gus is a 15-year veteran Principal Infrastructure Architect. He is tired, he has seen three cloud migrations come and go, he hates over-engineered abstractions, and he just wants his scripts to run fast without breaking his weekend.
Now, instead of asking the AI to write functions, you ask it to step into Gus's boots and map out his day-to-day pain:
Suddenly, the AI stops fabricating imaginary library calls. Instead, it starts uncovering genuine operational friction points, edge-case hazards, and ergonomic traps that you—the human developer—were too close to the code to see.
Note
Recording decisions in Architecture Decision Records (ADRs) ensures that future maintainers understand why a trade-off was made, protecting the design from architectural decay.
The quiet hazard in persona simulation is sycophancy—the model's default instinct to tell you your ideas are brilliant.
When an AI partner reflexively agrees with your proposals ("You're completely right!"), the simulation breaks. Bypassing this trap requires enforcing a strict Peer Consensus Rule:
Tip
If your AI assistant agrees with your architectural proposal on the first try, ask it to launch an adversarial attack pass on its own recommendation. You will be amazed at what turns up.
Generative models remain engines of probabilistic imagination; treating them as deterministic compilers is a fundamental mismatch.
When that imagination is redirected toward human empathy, operational friction, and adversarial edge cases, hallucination ceases to be a liability. It becomes an architectural asset.
This week I really enjoyed the podcast about compression (The Hutter Prize) and the one about seashells.
Board Meetings: Your Notetaker Is Not Welcome Here - this might be true for more meetings.
admin )
on 2026-08-05 12:00:00 UTC
The fedora-scm-requests ticket queue is being migrated from pagure.io/releng/fedora-scm-requests to forge.fedoraproject.org/releng/fedora-scm-requests.
As part of this migration, fedpkg has been updated to file new requests against Forgejo instead of Pagure. Toddlers, the automation that processes these requests and performs the actual dist-git operations (creating …
admin )
on 2026-08-05 08:00:00 UTC
Running Large Language Models (LLMs) locally has become increasingly popular for development, privacy, and offline testing. Ollama makes this incredibly straightforward, allowing you to run models like Llama 3 or Mistral directly on your machine.
By leveraging Podman on Fedora Linux, you can isolate Ollama inside a container. This approach keeps your host system clean while making it effortless to spin up, manage, and tear down your AI development environment.
Ollama is an open-source framework designed for running, creating, and sharing large language models. It packages model weights, configuration, and data into a unified management system. Running it inside a container means you don’t have to deal with complex local dependencies, Python environments, or complex GPU driver configurations on your base OS.
Podman is available by default in Fedora Workstation. It can be easily install, if missing, using DNF:
$ sudo dnf install podman -y
For Fedora Linux Silverblue users, Podman is natively available in the immutable base system and no extra steps are necessary.
To verify your installation and ensure everything is running smoothly, execute a quick check:
$ podman --version
LLM weights can be huge—often ranging from 4 GB to over 40 GB, depending on the model size. To avoid downloading these models every time you restart your container, create a persistent Podman volume to store them safely on your host disk:
$ podman volume create ollama_storage
Next, spin up the Ollama container. The following command pulls the official image, attaches the volume we just created, and maps the communication port (
$ podman run -d \ -v ollama_storage:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama
The command above runs Ollama using your CPU. If you are on Fedora Workstation or Silverblue and want to pass through an Nvidia GPU for fast hardware acceleration, make sure you have the Nvidia Container Toolkit installed and append the GPU flag:
--device nvidia.com/gpu=all
With the container running in the background, you can interact with it using Podman’s execution command. Let’s pull and run Llama 3, a highly capable, lightweight model perfect for local development:
$ podman exec -it ollama ollama run llama3
The first time you execute this, Podman will download the model weights into your
>>> Send a message (/? for help) >>> Tell me a fun fact about Fedora Linux. Fedora Linux is named after the iconic felt hat worn by the Red Hat shadowman logo! It started as a community project to provide extra packages for Red Hat Linux. >>> To exit the interactive prompt, simply type /exit.
Because we mapped port 11434 to our host system, you can also interact with your local Ollama instance via its built-in REST API. Open a standard terminal window and send a curl request:
curl http://localhost:11434/api/generate -d '{
"model": "llama3",
"prompt": "Why use containers?",
"stream": false
}'
This returns a structured JSON payload containing your answer, allowing you to easily hook your local model up to web apps, scripts, or IDE extensions.
To monitor your running local AI instance, use the classic Podman management commands, perhaps starting with:
$ podman ps
You can also inspect the logs to make sure the API server is listening properly:
$ podman logs ollama
When you are done with your development session and want to free up system memory, stop the container:
$ podman stop ollama
If you ever need to completely remove the container environment, use:
$ podman rm ollama
Note: Your downloaded models are completely safe inside the ollama_storage volume and will instantly reattach the next time you spin up the container.
Using Podman to manage Ollama on Fedora Linux or Fedora Silverblue offers a clean, containerized way to build and test applications with LLMs completely offline. It bypasses host environment pollution, isolates large model storage cleanly into a named volume, and treats your AI stack exactly like any other microservice.
You visited FrOSCon 2026