This outage impacts the copr-frontend and the copr-backend.
This outage impacts the copr-frontend and the copr-backend.
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.
Translating these persona insights into production software requires a structured pipeline:
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
I have spent the last two years rebuilding GNOME Boxes from the ground up, driven by three main factors. I spoke extensively about this effort in my recent Linux App Summit, GUADEC 2025 and 2026 talks, but today I am excited to share the result for general testing.
First, shifting to a Flatpak-first (and only) model. As a solo developer, maintaining code paths for countless distributions isn’t sustainable. Since Boxes acts as a frontend for libvirt/qemu, its functionality relies heavily on the backend configuration. Flatpak lets me bundle the entire virtualization stack, giving me the control I need to fine-tune it for our specific use cases.
Second, migrating Boxes to GTK4 and Libadwaita. Beyond the obvious benefits (a modern UI, better responsiveness, and tighter desktop integration) this makes the codebase significantly easier to maintain. This transition required moving away from the GTK3-based SPICE display widget, which was too tightly coupled to older input and drawing methods. We’ve replaced it with Libmks, which has proven to be a solid alternative.
Lastly, modernizing the codebase to make it sustainable for new contributors. That meant adopting modern GNOME app design patterns and rethinking our underlying architecture.
I am now ready to share this work with a wider audience. However, please keep in mind that this is a Beta release meant for testing, not for production environments. If you plan to try it out, make sure to back up any important data in your virtual machines first.
If you want to test this new implementation of GNOME Boxes, you can set up the GNOME Nightly Flatpak Repository and install it with:
flatpak install org.gnome.Boxes.DevelThis new version already covers most of what the classic Boxes could do: creating virtual machines from ISO media and disk images (qcow2), configuring VM resources, sharing clipboard content, sending files to the guest, and more.
It can install Windows 11 without any manual workarounds. Boxes configures Secure Boot and a virtual TPM device automatically. Everything required to pass the Windows 11 hardware compatibility checks out of the box. This was the most requested feature for the classic version, so I am particularly glad it is fully functional in this rewrite.
As distributions shift toward image-based OSes, this Flatpak-only approach becomes even more valuable. Most other virtual machine managers rely on host services or privileged daemons that are difficult to configure on immutable systems. While hardware and host combinations vary, bundling the backend stack directly inside the Flatpak gives us a controlled baseline that we can actively support, configure, and refine over time.
Accessing VM contents used to be tricky due to Flatpak sandboxing. This version addresses that by introducing a VSOCK device to the box, allowing guests with systemd v256 or newer to be accessed directly over SSH. It also adds initial support for port forwarding, letting you reach services running inside the VM from your host.
All of this and more is detailed on our new website, nightly.gnomeboxes.org, where you can also learn how to help by testing and reporting issues.
Please keep in mind that I am working on this in my free time alongside maintaining GNOME Settings and my day-job responsibilities at Red Hat. I ask for your patience with issue responses, but I will do my best to address bugs and keep pushing feature development forward as time allows.
I love building GNOME Boxes, and I am constantly motivated by the positive feedback from our community. People appreciate Boxes because it lets them set up a VM quickly and get straight to work without needing deep knowledge of virtualization or operating system internals. That remains the core mission, and that is the user experience I want to continue building for.
A lot of this implementation will still change as I gather feedback and it matures. I have also drafted a series of follow-up blog posts to this one, which will describe and elaborate a bit more on the new features, explaining how to use them and how they have been implemented. Stay tuned!
bex )
on 2026-08-03 08:20:00 UTC
This one is a bit light. I think that reflects the craziness of the summer and how I have worked through the backlog of my Instapaper. I’ve also been reading actual books (see below) so maybe you should too :D.
Chasing life goals is a recipe for disaster – so try these tiny experiments instead
Becoming the kind of parent you didn’t have a model for.
These are amazing words and regardless of our actual lived experience, I think we all feel this way when we have children.
Not only are communities not fungible, but JA makes it crystal clear how they differ from person to person inside the community because they are overlapping Dunbar circles. Before I left Twitter, I remember thinking that I must be using a different Twitter from everyone else because my experience was nothing like what I was hearing about. The same is now true for me on Mastodon.
Opinion | The Environmental Case Against Data Centers Is Misguided
Data centers should be held to the same environmental standards as any other project.
Why is this even controversial? I also believe we should price consumables at the correct cost reflecting our view on their impact as well as their production. I realize this will increase costs for many, including low-income members of our society, so instead we should surface the subsidy as a real subsidy line item. People should understand what things cost and what they have received as support.
For bonus points we can make the subsidy refundable to encourage people to conserve.
Hyperrealist Datacenters And Potemkin McRibs | blarg
I like it when an article finally acknowledges the power of smaller models for many uses when talking about the LLM Data Center bubble. If you choose to use LLMs start running some experiments with non-frontier models, whether cloud hosted or local, I think you’ll be pleasantly surprised.
While you’re reading this article, stay for the bonus McDonalds anecdotes. Per my daughter, as I am sad to admit, it has the best chicken nuggets a pork-market arbitraging real estate company can make.
Opinion | Is France poorer than America? You don’t have to ‘walk around’ to know.
This is such an American question. It’s like a reverse Tucker Carlson in a Russian grocery store. You know it is hard to toe the line when the best polish you can put on this turd of a proposition is, “[rural france is also] humdrum highways rather than picturesque public transit. The European endowment of beautiful architecture feels much richer than American acreage when you’re, well, walking around. That effect is magnified by lower crime and public disorder in Europe.” But yeah, let’s talk about raw dollars baby.
I’ve been tracking my book reading on my blog, but it never gets surfaced anywhere. I’ve decided to start including them here. Head to my reading page to find detailed notes or reactions for each book, similar in style to this post.
A pan that won’t let me rush dinner - Down the Road
I’m learning that turning the burner higher doesn’t actually make dinner happen appreciably sooner. It just makes it easier to burn dinner. So I’m going to learn to go low and slow.
I remember reading somewhere that you should almost never set a burner above medium. These days when I cook, I’m using gas :( - but low and slow has paid off. The other day I was cooking a chicken breast in our go-to nonstick IKEA skillet. I’d done basically no prep due to a child who hates flavor and hadn’t even tried to make it a similar thickness throughout. I wound up putting my skillet on too small of a burner, setting it to low, and hanging the pan half off the burner. This put the chicken on the off side recreating the indirect heat of a grill. I had juicy AF chicken. Suck it George Foreman!
admin )
on 2026-08-03 08:00:00 UTC
Flock 2026 was my first Fedora conference, and it won’t be my last. I came home with new ideas, new friendships, and even a new project to work on for next year.
I want to start by appreciating the Flock organizers and volunteers. Putting together an event like this takes a lot of quiet, unglamorous work, and it showed in how smoothly everything ran. Thanks for that!
I’d also like to thank the event sponsors. Their support makes it possible for contributors from all over the world to come together, learn from one another, and strengthen the Fedora community.
I also want to appreciate my mentor, Jona, for pushing and supporting me until I finally made it. And a big thank you to Fedora for the sponsorship that got me there.
This year I also got to be part of the Mentor Summit organizing team myself and helped put together the very sessions I used to just attend as a newcomer. Full circle moment here 
It has always felt rewarding to contribute to something I love, and Fedora has always been one of my favorite communities. Along the way, I’ve made great friends and met many wonderful people.
Finally, I’d like to thank the Nairobi GNU/Linux Users Group for supporting Fedora’s Recognition Program this year by sponsoring the trophies and keychains. It was great to see our local community play a part in recognizing Fedora contributors, and I hope it’s the beginning of a lasting tradition.
Our winners this time were; Fabio Valentini, Justin Forbes and Ankur Sinha in that order. Congratulations to you, and keep going
You might want to hear from them in our podcast Fedora Contributor Recognition Program 056.
I love how Fedora is so supportive of people from under-represented groups. Being at Flock felt like a reward for the work I’ve been doing with the community too – I had been organizing and mentoring from home. Being there in person and seeing that my work was appreciated meant a lot.
This is what I love about Fedora: it’s welcoming, and it lives by the Four Foundations every day.
I also believe the in-person inclusive checklist I worked on last year helped make this year’s event a success. I loved the venue – I guess that’s why we went back to the same place as last year.
Honestly, I’d say everything was perfect. So hey, Flock organizers – the venue was perfect.
There was so much to take in: design, the mentor summit, docs and the docs initiative, lessons from FOSDEM and SCaLE, and so much more.
There was also the fbrnch workshop, Fedora data and analytics, and honestly too many good sessions to list them all here.
If there’s one thing I keep learning about this community, it’s that nothing happens unless you ask. People, or I would say, I personally don’t wait to be picked here, I just find ways to engage, go deep, and just ask, ask, ask. I wanted to help with speaker logistics this year for Fedora Linux 44 release party, so while I was checking open tickets, I found it and asked if I could manage it. And I did it. I know some people might hesitate to just raise their hand like that, but Fedora is always welcoming, and honestly, we can always use the support. Get involved, it feels good to contribute to something you love.
Funny enough, a friend paid me a compliment (I think?) that I know how to navigate open-source communities and always find something to do. I’m still not sure if that’s just a “community person” thing, or if it’s because I genuinely like understanding people and learning new things. Maybe both.
The candy swap – I totally loved this! Super awesome idea. Sorry to disappoint that I couldn’t find time to bring anything, but I promise I will next time.
This was the 5th edition of the Fedora Mentor Summit, and it packed a lot into a few days. Lunch & Learn sessions ran across all three days, the informal, team-themed gatherings where you could step out of your usual circle and sit with people from Docs, Infra, Marketing, Packaging, Design, wherever you wanted to learn something new. No pressure, just conversation over food.
There was also a sticker-matching icebreaker, and everyone got a Fedora mascot sticker at registration, and the game was to go find your match and have a chat with them about anything open source.
Being on the organizing side of this for the first time gave me a whole new appreciation for how much quiet coordination goes into making something feel effortless for the people attending. Read more about how Mentor Summit came together here.
This is where the real magic happens. Daniel gave a brief, informal talk about eBPF, and honestly, that conversation ended up being one of the best parts of the whole trip.
I got to connect and meet team members, make new friends, and it was exciting just to sit and learn from them in a way a formal talk doesn’t always allow.
And out of that hallway conversation, I actually found another thing to do within Fedora. I have a project I’m hoping to finish and present at the next Flock – mentored by Daniel on eBPF. (Putting this here for accountability, so you can hold me to it. 
)
I keep meeting super kind, good Fedora friends who are willing to mentor and give their time. It says a lot about how welcoming this community really is.
Everyone I met was kind, and always down to talk about their experiences and their love for open source – and how they hope more people get to know it, try free software, and enjoy it wherever they are, in their own languages. That last part is thanks to the i18n and translation teams across open source communities, doing work that often goes unnoticed.
Being early in my career, of course I had to ask people how they got in. I won’t turn this into a rant, but if I had to summarize the advice: be a problem solver, and contribute to what you believe in – something you enjoy or find genuinely interesting.
*Thanks for reading this far. What’s below isn’t a big deal – just the city.*
I extended my stay by 3 days to explore Prague. I took so many pictures my phone storage nearly gave up on me – I found almost everything lovely and fantastic. I’ll link one of my best shots of the museum and the city below.
Thanks to my friend MatH for being my tour guide!
I totally loved it. It says something that the organizers knew just how magnificent this city is, and believed we’d love it again – and they were right.
I wish I could include every beautiful photo I took, but for now, these few will have to tell the story.
Every day with Fedora, I get to know more about open source, and I get to give back to my community back home.
I am Fedora
If any of this made you curious, here’s where to start: come join us in Fedora Join SIG, or if you’re just getting started, the Beginner’s Guide is the friendliest place to land.
Your Friend in Open Source, and Open-Source Freedom Fighter.
Across the various Fedora teams, a major shared focus is the ongoing infrastructure migration to Fedora Forge (Forgejo) and the formalization of its usage policies, a coordinated effort involving the Council, Infrastructure, Release Engineering, and Security groups. Quality assurance and release readiness for Fedora 45 also dominate the updates, highlighted by approaching testable deadlines, mass branching preparations, and FESCo's system-wide approval of gating all stable release updates using the rmdepcheck dependency checker. Meanwhile, user-facing and quality teams are heavily collaborating to troubleshoot critical system issues—most notably a Fedora 44 Workstation login lockout bug—while language-specific SIGs (Go, Perl, Ruby, Rust) are addressing routine maintenance, unannounced soname bumps, and evolving packaging standards. Finally, community outreach and organization remain highly active, with teams like Mindshare and Ambassadors rallying volunteers for upcoming events like FrOSCon 2026, and multiple working groups actively streamlining their documentation and meeting structures to improve contributor onboarding and combat maintainer burnout.
Important deadlines and policy updates are approaching for Fedora contributors. First, the Fedora 45 Changes TESTABLE deadline is set for August 11, 2026, requiring all change owners to verify their tracker bugs are in a testable state. Additionally, maintainers should review the list of long-term FTBFS packages scheduled for retirement from Fedora 45 around August 5. On the infrastructure side, the Fedora Council has opened the proposed Fedora Forge Usage Policy for community feedback until August 13, establishing clear scopes and guidelines for the project's internal Forgejo instance. Finally, the long-running CLE "Community update" is officially retiring and being replaced by this new "This Week in Fedora" report to keep contributors informed.
In broader community news, a recent article highlights Peter Boy's work with the Docs Team to explain why Fedora needs more than just technical contributors. For those who missed the recent contributor conference in Prague, a new Flock 2026 Afterburn retrospective shares insights and survey results from the successful event. The project's multimedia outreach continues to see steady audience growth across platforms according to the Fedora Podcast 2026-Q2 metrics report. As part of that ongoing output, the team has just released Episode 057 diving into the history and mechanics of EPEL with Red Hat's Carl George, exploring a tool relied upon across the entire enterprise Linux ecosystem.
The Council focused heavily on policy formalization and infrastructure migration this week. During their bi-weekly meeting, they agreed on edits to the Fedora Forge Usage Policy, settling debates on automated repository archiving by favoring manual oversight, and initiated the official community feedback phase. They also debated a draft Conflict of Interest Policy to handle sensitive governance decisions, and officially closed outdated requests to abolish the Fedora Contributor Agreement. Furthermore, discussions opened regarding the transition of the Digital Public Goods Alliance representative role following the FCA transition.
The Council also handled several operational and community requests. They approved an exception for FreeIPA to be hosted on Fedora Forge and decided to migrate the Fedora Budget repository while explicitly purging old private financial issues. Finally, the Council addressed trademark and organizational queries, declining a suspicious SIG creation request, signaling support for a trademark request for community stickers in Slovakia, and clarifying rebranding requirements for Fedora Remixes.
Learn more about the Council team.
This week, FESCo approved several significant system-wide changes, most notably retargeting the Enable Shadow Stack by Default on x86_64 change to Fedora 46 to ensure ample time to fix PyPI and Nvidia driver compatibility. Other major approvals include ODBC Stack Modernization, Native Butane Config Support in Ignition, and the libxml2 2.15 update which officially deprecates Python bindings and requires a mass rebuild. FESCo also fast-tracked and approved a proposal to gate all stable release updates on rmdepcheck to enhance update stability.
In contributor and project news, FESCo granted Proven Packager status to mschorm, merged an adjusted mid-term election policy, and sent final reminders for the upcoming 2FA requirement for all provenpackagers. Ongoing discussions are exploring the Forgejo distgit migration, a Bugzilla replacement tracker, and handling prohibited pre-built binary executables in node_modules. Furthermore, proposals to enable systemd-oomd and zram swap for CoreOS and use Sequoia's OpenPGP implementation are currently under active vote.
Learn more about the FESCo team.
This week, Mindshare welcomed a new contributor who expressed interest in joining the CommOps team, pointing them to the Matrix chat and Forgejo issue tracker for immediate engagement opportunities. Additionally, preparations are actively underway for FrOSCon 2026, a free FOSS conference happening August 15-16 near Bonn, Germany. The team has secured a booth and is calling on community members to volunteer, create A4 project teasers to spark conversations, and join the pre-event hike to Drachenfels castle.
Learn more about the Mindshare team.
The Ambassadors group is calling for all hands on deck to prepare for FrOSCon 2026, scheduled for August 15-16 near Bonn, Germany. A Fedora booth is confirmed, and contributors are highly encouraged to engage by joining the Matrix room, adding their names to the event Wiki, or creating A4 teaser pages to spark conversations about their Fedora projects at the booth. Additional community-building activities include a planned Friday evening hike to Drachenfels castle, while work on the official event badge is currently pending.
Learn more about the Ambassadors team.
Justin Wheeler proposed putting DEI Team meetings on hiatus to protect the mental health of the chairs and prevent burnout. The team agreed that regular meetings had become stagnant and decided to shift their focus toward ad-hoc, event-specific teams with concrete goals and timelines, such as the Fedora Mentor Summit or Fedora Week of Diversity. General discussions will continue in the team chat room as needed.
Learn more about the Diversity & Inclusion team.
This week, the Workstation/GNOME team discussed a login bug in the Fedora 44 Workstation ISO where users are occasionally locked out after setting their credentials. Contributors are working to gather logs and pinpoint the exact cause within gnome-initial-setup. Additionally, a new implementation restoring Google Drive integration in GNOME is currently under review by upstream maintainers, presenting a great opportunity for community testers to provide feedback.
In networking discussions, the team explored IPv6 prefix delegation issues involving routers that fail to invalidate old prefixes after rebooting, which leads to dropped connectivity. It was noted that router manufacturers like Mikrotik are currently working on firmware updates to align with RIPE recommendations, circumventing the need for immediate workarounds in Fedora's default network behavior.
gnome-initial-setup or shadow-utils) rather than Anaconda, which does not handle user creation on the Workstation Live image.Learn more about the Workstation / GNOME team.
A user reported experiencing system freezes under Plasma (Wayland) after upgrading to Fedora 44, specifically noting that the nvidia-modeset/kthread_q process was consuming 100% CPU. The issue occurred on a hybrid graphics setup utilizing an AMD CPU and a discrete NVIDIA GPU running the proprietary NVIDIA drivers (610.43.03).
In the ensuing discussion, a community member advised checking the system and user journals via SSH before performing a forced reboot to isolate the root cause. The user was also directed to seek further assistance on the Fedora Discussion forum, which hosts a larger pool of contributors experienced with NVIDIA troubleshooting.
Learn more about the KDE team.
During this week, the Server Working Group held a meeting to coordinate Fedora 45 release testing, Ansible support, and the Home Server spin-off. Contributors are encouraged to help test Brett's newly finalized Kiwi development environment for the Home Server project. On the automation front, the group is exploring the "AnsibleByExample" standard project layout and GitLab workflows for their upcoming Ansible roles, and an initial post-install role PR is being merged for member testing. For F45 testing, Emmanuel Seyman will review the upstream release changes for potential Server Edition impacts, and interested contributors were directed to the QA SIG to assist with openQA test automation.
Outside of the meeting, a forum discussion regarding IPv6 preferred_lft address routing issues with non-persistent prefixes concluded. A user shared a temporary workaround using Unique Local Unicast (ULA) and NAT while awaiting an upcoming patch from router manufacturer Mikrotik.
Learn more about the Server team.
This week, the Infrastructure team focused heavily on resolving post-migration issues following the upgrade of the IPA cluster to RHEL 10. Efforts were directed at stabilizing authentication services, addressing sporadic login errors on accounts.fedoraproject.org, fixing Ipsilon auth failures caused by browser tracking protection, and correcting LDAP schema replication errors. In the forums, a proposal was introduced to place an HAProxy load balancer in front of the IPA cluster to bypass ongoing DNS TTL caching problems. Work also continued on restoring the Koji staging database and migrating miscellaneous infrastructure hosts to RHEL 10.
Other notable discussions included optimizing Zabbix monitoring by implementing service-level layers, re-notifying on critical alerts, and exploring read-only guest access. The team also reviewed a proposal for a "test assets server" designed to drastically reduce network traffic by caching update repositories for Fedora CI and openQA. In parallel, Forgejo integration saw substantial updates, with new monitoring templates and continued progress on the highly requested private issues feature.
ipsilon02 as a backup server in HAProxy to mitigate authentication transaction failures caused by browser tracking protection.ensure absent) the mod_mime_magic Apache module on proxies and package servers to fix dist-git lookaside cache HTTP header issues.Learn more about the Infrastructure team.
The Release Engineering team focused heavily on the final steps for migrating fedora-scm-requests from Pagure to Forgejo. To minimize disruption for contributors, the team agreed to coordinate the fedpkg tooling updates with a firm "flag day", ensuring developers receive appropriate upgrade warnings before the legacy Pagure API is fully disabled. Meanwhile, preparations are underway for the upcoming mass branching tentatively scheduled for August 11th, which includes updates to related Ansible tooling.
On the operations side, the group processed a dozen tickets, yielding several updates relevant to the broader Linux community. The F47 Release Signing Keys have been generated, a new eln-bootc repository was created on Quay to host bootc images for ELN composes, and the f45-perl side tag was successfully merged into Rawhide. Contributors are also reminded that package unretirements (for packages retired less than 8 weeks ago) can now be handled directly via the fedpkg request-unretirement command without needing to open a manual releng ticket.
fedora-scm-requests Forgejo migration using a synchronized 'flag day' to safely transition users to the updated fedpkg CLI, rather than attempting to maintain dual APIs.sysadmin-releng staging group.f45-perl side tag into Rawhide following successful openQA testing.fedpkg request-unretirement CLI command for recent unretirements rather than processing manual infrastructure tickets.Learn more about the Release Engineering team.
This week, the Quality team saw a major workflow change as FESCo approved gating all stable release updates on the rmdepcheck tool, a rule that has already taken effect for in-flight updates. In the forums, contributors highlighted a critical login lockout bug on the Fedora 44 Workstation ISO and issued an important call for testers to evaluate a new Google Drive integration implementation for GNOME.
Additionally, quality engineering efforts successfully pushed a large Python rebuild update through testing and identified issues with Fedora 45 backgrounds via openQA. The team is actively preparing for upcoming Test Days and making numerous infrastructure updates to tools like Issuebot, Testdays-web, and Fedora Easy Karma ahead of the upcoming Fedora branches.
Learn more about the Quality team.
This week, the Websites and Apps group discussed a proposal to add a warning banner to the Fedora 44 download page regarding a login-blocking bug that reportedly prevents users from logging in after a fresh Workstation install. While the initial request suggested pointing users to a Respins SIG image with a patched Anaconda, QA representatives clarified that user creation is handled during first boot (gnome-initial-setup or plasma-setup), not by Anaconda. Consequently, the discussion pivoted to accurately reproducing the issue, presenting an opportunity for contributors to help collect diagnostic logs for first-boot login failures before any website changes are considered.
Learn more about the Websites and Apps team.
The Design team saw a community member propose a custom wallpaper set for future Fedora releases, though it was noted it may not fit the current Fedora 46 theme. In ticket discussions, progress continued on the Contributor Onboarding Video Series, with the team agreeing on specific public-domain music tracks and moving forward with generating video previews.
Additionally, new UX/UI design requests were opened for a Fedora website credits page and a Project Resistor site redesign, prompting the team to propose a discovery call for the latter. Finally, the team discussed modernizing the outdated "What can I do for Fedora" site, ultimately closing the ticket with the decision to contact the upstream infrastructure maintainers before committing to new mockups, while also dropping the broken link from a new contributor poster.
Learn more about the Design team.
During the July 28 meeting, the Docs team discussed information architecture updates for the site's frontpage. Visual redesigns are delayed for 2-3 months while the Design team is busy, but a new staging landing page (docs.stg.fedoraproject.org) is currently live to test structural changes. The team also evaluated technical challenges regarding Antora repository module splits, noting that future structural updates might require significant URL redirects to maintain links. In broader community news, attendees were informed that a Flock 2026 recap and session videos will soon be available on Fedora Magazine and YouTube.
To improve contributor engagement, the staging site now features a dedicated section for new contributors, and the team is actively seeking collaboration with the Join SIG to refine it. There are also immediate, bite-sized opportunities for community members to get involved: volunteers are highly encouraged to help clean up obsolete Wiki pages in the Docs_Project category by applying a simple redirect macro, and anyone with CSS experience is welcome to help style the new frontpage.
Learn more about the Docs team.
This week, the Legal team addressed questions regarding firmware distribution and open-source license text anomalies. In a discussion about the foo2zjs printer driver, contributors asked if Fedora could package scripts that download necessary HP printer firmware. Legal clarified that scripts downloading from unofficial third-party mirrors (getweb) are not permitted, but a script fetching from the official OpenPrinting website (getweb-hpplugin) could be acceptable, pending a formal license review of the firmware to ensure it meets Fedora's technical criteria.
Additionally, in a thread concerning "All rights reserved" clauses appearing alongside FOSS licenses like BSD-3-Clause, the team concluded that this phrase is largely a redundant "cargo-cult" addition. Contributors are advised not to worry about it, as it can be safely ignored provided it is associated with a clear, acceptable open-source license grant.
Learn more about the Legal team.
This week, the EPEL team focused heavily on the EPEL 11 and EPEL 10 directory naming scheme proposal to address feedback from enterprise rebuild communities (such as AlmaLinux and Rocky Linux) regarding private mirrors and repository redirection. During their weekly meeting, the team laid out a timeline to evaluate and implement these changes before the RHEL 10.3 branching to avoid disrupting early adopters. Additionally, on the mailing list, it was announced that FESCo has approved gating all Fedora stable release updates using the rmdepcheck reverse dependency static checker, a policy that will soon be evaluated for EPEL as well.
In broader contributor and community news, routine package maintenance and quality assurance continued, including the introduction of new EPEL 10 packages and efforts to resolve failing-to-install (FTI) and policy-breaking packages in EPEL 9. Community engagement was also highlighted, with an upcoming Fedora Podcast interview featuring Carl George to discuss the EPEL 11 proposal and raise broader Linux community awareness.
Learn more about the EPEL team.
During the July 28 ELN meeting, the team announced that ELN bootc images are now building regularly on Konflux. Contributors are currently resolving minor early-testing issues and working to establish an automated pipeline to the production registry (quay.io/fedora/eln-bootc). Additionally, qcow2 and ec2 images are now being successfully built using image-builder and have been validated on AWS, with pull requests open to integrate Azure and GCE support.
Looking ahead to RHEL 11, the group also debated whether to drop hardware firmware (such as linux-firmware) from cloud images. Acknowledging that hardware passthrough is still utilized on some hyperscalers, the group opted to move this conversation to a dedicated issue to carefully evaluate how closely ELN should mirror future RHEL decisions without disrupting existing use cases.
bootc builds to the quay.io/fedora/eln-bootc registry.Learn more about the ELN team.
In the weekly meeting, the team highlighted continued progress on ELN and Konflux integration, specifically regarding plans to migrate base images from GitLab. A blocker regarding a Konflux service account is currently being addressed by the infrastructure team, which is expected to unblock development shortly. Leadership also noted pending action items to formalize the SIG's setup process and establish a dedicated Fedocal calendar for contributors.
Meanwhile, an ongoing forum discussion regarding the proposed systemd-sysexts SIG focused on the administrative steps for launching the group. To navigate confusing documentation rules, contributors agreed to initially outline the new SIG's scope on a standard Fedora Wiki page before requesting a dedicated Forge organization and Matrix channel.
Learn more about the Atomic team.
This week, the CoreOS group focused on upcoming release testing, tentatively scheduling the Fedora CoreOS 45 Test Day and live video meeting for September 21st. Technical discussions highlighted the Ignition Native Butane Support proposal, which will remove the need for an external conversion step during provisioning; the team plans to gather feedback on this from the Flatcar community. Additionally, contributors addressed issues with the CodeRabbit PR bot leaving unprofessional comments in the Afterburn repository, planning to establish a dedicated repository to manage global configuration defaults.
In the forums, progress continued on establishing the systemd-sysexts SIG. Contributors discussed the optimal way to host the SIG's initial documentation, ultimately recommending starting with a Fedora Wiki page before requesting a dedicated Forge organization to bypass current procedural documentation challenges.
coreos/coderabbit repository for global default configurations.Learn more about the CoreOS team.
This week, the AI & ML group announced that GPU CI testing is now operational and available for contributors in the AI/ML SIG. Furthermore, the AI Developer Desktop has achieved its initial integration with OpenShell, marking an exciting step forward for the project.
In administrative updates, a contributor requested to be removed from the SIG due to time constraints and burnout. The group processed this request, removing the member from the SIG-related GitLab groups and the pytorch-sig membership to ensure an accurate representation of active contributors.
Learn more about the AI & ML team.
During their weekly meeting, the Security SIG focused on formalizing internal vulnerability management processes and establishing documentation standards. A primary initiative is preparing for Fedora's representation on the private linux-distros mailing list to safely handle embargoed pre-disclosure vulnerabilities. To support this, the team is defining clear policies, establishing a secure Bugzilla workflow, and setting up dedicated access groups. In news relevant to the broader Linux ecosystem, the group is defining and documenting Fedora's role as a CVE Numbering Authority (CNA) and auditing existing documentation to align with the EU Cyber Resilience Act (CRA) requirements.
To improve contributor engagement opportunities, the team successfully migrated the Defensive Coding Guide from Pagure to Forgejo, opening the door for new community contributions. Discussions are also underway on the forum to review Fedora-maintained hardening guidelines and on the tracker to explore creating a vulnerability reporting badge as a non-monetary bug bounty alternative.
sec-bugzappers to manage access for Fedora representatives handling the linux-distros pre-disclosure mailing list.distribution-private or fedora-security) to track embargoed vulnerability reports.Learn more about the Security team.
During the Go SIG meeting, the team discussed standardizing CGO_CFLAGS and related compiler flags across Fedora by introducing a new %go_set_cgo_flags macro, which will undergo mass prebuild testing to avoid disrupting existing packages. The group also approved a new SIG membership policy that will be appended to the project README, clarifying the justification required for elevated package privileges. For contributors looking to get involved, assistance is needed to patch downstream packages broken by recent Go 1.27 updates, specifically those affected by changes to json v2, compress/flate, and grpc.
In broader Linux ecosystem news, the unmaintained license-scanning tool askalono has been forked into a newly maintained project named scallion. Fedora's Go packaging stack will pivot to use scallion as its default license detector. Additionally, efforts are underway to provide a minimal go-vendor-tools package for RHEL 11 by stripping optional build-time dependencies, an initiative that presents immediate opportunities for contributors to write tmt-based integration tests.
scallion as the replacement for the unmaintained askalono license scanner, with upcoming changes planned for both go-vendor-tools and go2rpm.go2rpm v2 with the default configuration set to the vendor profile.go-vendor-tools in RHEL 11 by isolating the RHEL-specific changes in a separate GitLab branch and developing new tmt-based integration tests.Learn more about the Go team.
This week, the Perl group focused heavily on package maintenance, compatibility updates, and version bumps. Several pull requests were merged, including conditionalizing dependencies for perl-Module-Build-Tiny, disabling optional dependencies for perl-Compress-Raw-Lzma in RHEL, and addressing Wx 3.2.9 compatibility in perl-Wx. A patch for OpenSSL 4 ASN.1 strings was integrated into perl-Crypt-SMIME. Additionally, routine version bumps were applied to perl-LWP-Protocol-https (6.17), perl-HTTP-Message (7.04), and perl-ExtUtils-XSpp (0.19).
Other ongoing discussions involved resolving an expected installability failure during the bootstrap of perl-SQL-Abstract and addressing MySQL 9.7 rebuilds for perl-DBD-MySQL, though the latter's PR was closed as the fix was committed directly to the rawhide branch.
CPAN::Requirements::Dynamic dependency in perl-Module-Build-Tiny.perl-Compress-Raw-Lzma in RHEL.perl-Wx.perl-Crypt-SMIME.perl-DBD-MySQL PR for the MySQL 9.7 rebuild without merging, as it was fixed directly in the rawhide branch.perl-LWP-Protocol-https (6.17), perl-HTTP-Message (7.04), and perl-ExtUtils-XSpp (0.19).Learn more about the Perl team.
A contributor raised a packaging question regarding the dupeguru package (Bugzilla 2497737), which is currently waiting for review. The upstream code uses generic top-level modules (core, hscommon, qt), which could cause namespace conflicts with other applications. The main subject of inquiry was whether reorganizing the source tree to place these folders under a specific dupeguru namespace is the recommended approach for Fedora packaging.
Learn more about the Python team.
Vít Ondruch announced that the upgrade to Ruby on Rails 8.1 (specifically version 8.1.2) has officially landed in Fedora. An update to the recently released version 8.1.3.1 is planned for the near future, as it was temporarily delayed to meet the change deadline. From a packaging perspective, there were no major structural changes, with the notable exception of Trix being extracted into a separate new package. Contributors and users are highly encouraged to test the new release and report any issues.
Learn more about the Ruby team.
Frank Dana proposed a new packaging method for Rust and Python that would replace feature-specific subpackages with a conditional Requires: ... for syntax in RPM. He argued that the current glut of subpackages creates excessive metadata, bloats dnf search results, and clutters local systems.
During the discussion, Fabio Valentini pointed out that Rust packaging tooling must maintain backward compatibility with RHEL 9, making this unfeasible to implement in the near future, and suggested using fedpkg mockbuild instead of local builds to avoid cluttering personal environments. Carl George noted that since some Python extra subpackages contain actual files (like CLI commands or man pages), the proposed mechanism could not fully replace subpackages, though both systems could potentially coexist.
Learn more about the Rust team.
geoclue2 was installed as a dependency via xdg-desktop-portal. Community members shared configuration workarounds to disable the service's tracking capabilities.fedora-scm-requests and to finalize ForgeFiler, a tool handling private issues temporarily missing from Forgejo.test-reports mailing list.ffmpeg.clifton application.blitz.nettle3.10-devel compat package was shipped to unblock builds while maintainers port to Nettle 4.openssl-pkcs11 broke dependencies for nextcloud-client, requiring provenpackagers to merge PRs and rebuild the client in a side-tag.clifton and Typst.Betterbird.supercollider package.qTox who is interested in deep neural networks and machine learning.
neil )
on 2026-08-02 00:40:00 UTC
A couple weeks ago I shipped a swamp workflow that tells me what Fedora wants from me on a given day. Three models fan out in parallel, pull bugs and builds and package state, and one command writes a markdown snapshot I can diff against last week’s. It’s the workflow I wanted, and it runs every time I have the spoons for it.
Two of the three models are pure fetch, and carry no external dependencies. The third isn’t.
The FASJSON service speaks only Kerberos/GSSAPI: every endpoint requires
WWW-Authenticate: Negotiate, and there’s no password or token fallback of any
kind. The standard answer (the one every integration I’ve ever seen uses) is to
shell out: kinit, then curl --negotiate, and now your model depends on a
subprocess, an ambient credential cache, and whether the machine happens to have
krb5-workstation installed.
Another saturday, and another really really busy and anoying week. Lets recap!
I'm sure it will be appreciated by many readers of this blog, but I definitely am very happy that we finally managed to get our production IPA clusters all replicating and happy again. Many thanks to Michal Konečný for all his work on it.
Now that the cluster is all back happy, we plan to make some changes in our application configuration. Many of our openshift apps had been hard coding one ipa server, which was no good when that one was down. I need to do some testing in staging, but we should be able to move almost all of those to just use dns for the servers, which of course adds dns into the mix, but also means it's just one place to change things.
There's also still an outstanding issue where accounts.fedoraproject.org refuses to login some people some of the time seemingly randomly. I hope we can fix that fully early next week. In the mean time if you get a denial there, just retry after a few minutes and it should hopefully work for you.
There's still also a long standing (happened before/still happening sady) issue where you login to an application and get a 400 page. But if you go to the application page you can see that you are logged in. We came up with a really nice sounding theory as to why this was happening, but sadly it didn't seem to actually be the issue. We have 2 ipsilon instances and the theory was that sometimes load balancing (which is supposed to use a header in the requests to make sure it keeps going to the same instance) wasnt working and someone would auth against one, but then get a request against the other one that didn't yet realize what was going on. I changed it to only go to one and keep the other only as a backup, but it didn't seem to fix the problem for those that were seeing it, so back to the drawing board.
The scrapers have been hitting src.fedoraproject.org hard again. For the most part this is not a super bad event because of all the resource adding and tuning we have done. It does result in things being slower for maintainers sometimes and there are sporadic 502/503s.
At this point I am not sure whats left to tune or block, so if it gets worse we may have to consider putting more barriers in place, which I really would like to avoid (ie, a login requirement or something).
But we will see how it goes.
As always, comment on the fediverse: https://fosstodon.org/@nirik/117022212131589361
RPMs of Redis version 8.10 are available in the remi-modular repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
Packages are available in the redis:remi-8.8 module stream.
# dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %rhel).rpm # dnf module switch-to redis:remi-8.10/common
# dnf install https://rpms.remirepo.net/fedora/remi-release-$(rpm -E %fedora).rpm # dnf module reset redis # dnf module enable redis:remi-8.10 # dnf install redis --allowerasing
You may have to remove the valkey-compat-redis compatibility package.
Some optional modules are also available:
These packages are weak dependencies of Redis, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).
The modules are automatically loaded after installation and service (re)start.
The modules are not available for Enterprise Linux 8.
redis
redis-bloom
redis-json
redis-timeseries
RPMs of Redis version 8.8 are available in the remi-modular repository for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
Packages are available in the redis:remi-8.8 module stream.
# dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %rhel).rpm # dnf module switch-to redis:remi-8.8/common
# dnf install https://rpms.remirepo.net/fedora/remi-release-$(rpm -E %fedora).rpm # dnf module reset redis # dnf module enable redis:remi-8.8 # dnf install redis --allowerasing
You may have to remove the valkey-compat-redis compatibility package.
Some optional modules are also available:
These packages are weak dependencies of Redis, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).
The modules are automatically loaded after installation and service (re)start.
The modules are not available for Enterprise Linux 8.
redis
redis-bloom
redis-json
redis-timeseries
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 built my current house server back in 2019. It had an upgrade from the original Ryzen 2700 to a 5700G in late 2021, but otherwise is still running with the original setup. Back in November it developed some erratic behaviour (initially manifesting as problems with the TPM, which is ironic as I’ve spent a bunch of time at my day job trying to improve TPM reliability), culminating in unreliable reboots. I had a limited amount of ability to swap parts out, but ultimately decided it was a motherboard issue (thinking perhaps VRM problems), found a replacement locally, and everything seemed fine.
Until May.
At that point I rebooted the machine for a Debian point release, and it failed to come back. Fans would spin, but there was no sign of actual life. I ended up pressing a temporary machine into service (that could at least run the Home Assistant container, and a few other critical bits) while I tried to work out what was wrong. I’d kept the previous motherboard, and still had the Ryzen 2700, so I did a bunch of swaps (and obtained a motherboard buzzer to try and get some indication about whether there were useful beep codes being emitted), and ultimately came to the conclusion that the CPU had died.
I’m not quite clear what happened here. I played it safe and replaced the PSU at the same time, in case that was the original cause back in November and ultimately damaged the CPU, but both old + new motherboards worked just fine with the 2700.
That left a decision about what to do. This previous server was from 2013, so this machine has now lasted longer than that and I could justifiably upgrade. However when I went to look at what the equivalent modern machine would be it’s only a couple of generations later (Zen 5 vs Zen 3), and 64GB RAM alone would have set me back ~ £1k. For not a lot of gain. So I ended up buying a replacement Ryzen 5700G, hopefully allowing me to put off thinking about an upgrade until Zen 6 is out, and RAM prices are saner (though I understand that might take a couple of years).
It’s not the first time I’ve had a faulty PSU be the cause of a dead machine, but it was a pretty frustrating experience.
I liked the “Border Collie” post today, the podcast about air conditioning in Europe, and the interview with Mike D.
TBM 433: The Border Collie Faustian Bargain - fun model. I think this applies to other ways of buy-in too.
After extensive review and discussion on the ticket request and in recent council meetings (see meetbot for 29 July and 15 July 2026), the Fedora Council would like to initiate the policy change policy process for ratifying the Fedora Forge Usage policy. This document is open to public feedback (if any) for a minimum of two weeks. If there are no significant changes to be made to the policy based on community feedback after Thursday, 13 August 2026, this policy will go to a formal ticket vote for Council to approve or reject.
If there are significant changes to be made to the document, Council will review the policy and, if necessary, extend the feedback period before calling for an official vote. Please provide feedback on the discussion post.
The policy can be found on the Council wiki page in Fedora Forge, posted on discourse, and pasted below here for convenience.
Thank you everyone for your contributions to this policy so far, and on behalf of the Council, we look forward to working with you all to ratify this policy soon.
Welcome to the Fedora Forge. This Forgejo instance is provided by the Fedora Infrastructure team to support the daily operations, development, and collaboration of the Fedora Project.
To ensure this service remains reliable, secure, and useful for everyone in the Fedora community, all users must adhere to the following usage policy.
The Fedora Forge is a dedicated workspace for the Fedora Project. Historically, the Fedora Project utilized pagure.io, which operated as a general-use public forge where Fedora repositories coexisted alongside personal projects, unrelated upstream software, and individual portfolios.
The Fedora Forge (powered by Forgejo) intentionally adopts a narrower scope. It is not a public, general-use Git hosting provider. It is an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.
To qualify for hosting on the Fedora Forge, a repository must meet at least one of the following criteria:
While general upstream development should happen on public forges (like GitHub, GitLab, or Codeberg), the Fedora Project recognizes that certain large-scale upstream projects are so deeply intertwined with Fedora’s infrastructure and history that they qualify as exceptions.
Recognized Exceptions:
Note: Being packaged in the Fedora repository does not automatically grant a project exception status to use the Fedora Forge as its upstream host.
If a community member is unsure whether their project fits the scope or qualifies as an ecosystem exception, the following process applies:
Access to the Fedora Forge is integrated with our central identity systems to ensure secure and accountable access.
The Fedora Forge is a collaborative space. All activity on this platform is strictly governed by the Fedora Code of Conduct.
To ensure the Fedora Forge remains performant, secure, and legally compliant, the following activities and content are strictly prohibited:
We want to empower Fedora teams with the tools they need, but we must also manage our infrastructure costs and storage effectively.
The post Fedora Forge Usage Policy appeared first on Fedora Community Blog.
admin )
on 2026-07-30 08:00:00 UTC
Evolution, change, and innovation are important parts of Fedora. This applies both to our open source technology and in how we sustain the community that builds it. As Fedora changes with the world around us, so too must the roles that support it. This includes the Fedora Community Architect role. Today, we (Justin & Shaun) are excited to share a strategic transition in how Red Hat supports Fedora’s community operations.
Effective as of time of publication, we are beginning a transition period for the Fedora Community Architect (FCA) role. To continue our commitments to Fedora and CentOS, the Red Hat Open Source & AI Program Office is splitting the current, wide-reaching FCA responsibilities into two distinct, focused roles.
We (being Justin & Shaun) will work in a transitional phase together from now until the release month of Fedora Linux 45, currently planned for October 2026. During this time, we will shift our focuses to ensure a smooth handoff for key community operations, including event logistics, budget management, and both Fedora Council and CentOS board representation.
Shaun McCance will step into the role of Fedora Community Architect. Many may already know Shaun as a longtime person in our community, bringing experience and context from GNOME, a major Fedora upstream project. He also brings significant experience in community event execution, budget management, and existing expertise as the CentOS Community Architect. He will take over the permanent FCA seat on the Fedora Council and Fedora Mindshare Committee, chair the Code of Conduct Committee, lead the annual planning of the Flock to Fedora conference, and continue the financial stewardship of our project resources.
Simultaneously, Justin Wheeler will transition into a new position: AI Alignment Community Architect. This role allows for a dedicated focus to align Fedora’s existing and future AI adoption with Fedora community values and norms. This gives more time and attention for him to participate in Fedora community discussions that explore a future with AI builder downstreams, this role will focus on formalizing community AI services, mentoring contributors, and ensuring that major AI-related initiatives in the default Fedora Linux experience align with Fedora’s Four Foundations: Freedom, Friends, Features, First.
While our day-to-day focuses are shifting, the biggest constant remains our shared commitment to Fedora and CentOS. We are both remaining deeply involved in our current communities through our work at Red Hat, and we are committed to ensuring this transition maintains the health and momentum of our ongoing community work.
This transition marks a strategic expansion of Red Hat’s investment in Fedora, rather than a departure. We are excited about this next chapter and the ability to dedicate more specific focus to both our foundational community operations and our emerging technical horizons.
We look forward to continuing this work with all of you through the Fedora Linux 45 release cycle and beyond. Thank you for your patience as we work through the transition.
renich )
on 2026-07-30 08:00:00 UTC
Hace ya varios meses se me ocurrió una idea para resolver una de las broncas más frustrantes cuando programas con inteligencia artificial. Llevo un buen rato probándola, puliéndola y echándole coco en proyectos reales de infraestructura y desarrollo core y, la neta, los resultados están bien perros. Hoy te quiero compartir exactamente cómo funciona The Crucible Protocol (El Protocolo Crisol) para que tú también lo puedas aplicar en tus flujos de trabajo.
Ya sabes cómo se pone el asunto cuando le pides a un agente de IA que te refactorice un módulo o te arregle un bug complejo: el bato se pone a tapar el sol con un dedo. Para salir del paso rápido, te mete un //nolint:, se traga las excepciones en silencio, o se inventa abstracciones raras que ni al caso. Y si pones a un solo agente a revisar su propio código, el sesgo de confirmación hace que no vea sus mermas. De hecho, hasta creo que los agentes se aburren de tu proyecto y empiezan como niños de 5 años; a hacerse weyes. ;D
Para acabar de una vez por todas con esas alucinaciones y mañas, diseñé este loop iterativo, estricto y de cero confianza (zero-trust) que combina agentes de ataque Red-Team en parejas con auditoría Blue-Team hasta lograr un código 100% puro.
Note
El nombre le queda al putazo: un crisol es ese recipiente donde se funden los metales a temperaturas extremas para separar la escoria del oro puro. Eso mismito le hacemos al código aquí, compa.
En mis primeros experimentos hace meses, intenté usar un solo agente "revisor estricto". Pero me topé con dos extremos igual de malos:
La solución que descubrí tras meses de afinar el jale fue dividir la revisión de ataque en dos roles secuenciales: un atacante sin freno (extreme_adversary) seguido inmediatamente por un juez pragmático (measured_adversary), imponiendo reglas de parada estrictas donde el orquestador no puede decretar el cierre por su cuenta.
Es fundamental entender dónde encaja este protocolo dentro de todo el ciclo de ingeniería. El Protocolo Crisol no trabaja en el vacío; depende de una disciplina estricta de Desarrollo Guiado por Pruebas (TDD):
Dividimos la responsabilidad en cinco etapas bien delimitadas usando sub-agentes especializados:
┌─────────────────────────────────────────────────────────┐
│ 1a. EXTREME ADVERSARY (Ataque Hiper-Pedante) │
│ Busca hasta el mínimo olor a código y fallas de diseño │
└────────────────────────────┬────────────────────────────┘
│ (Pasa reporte de ataque)
▼
┌─────────────────────────────────────────────────────────┐
│ 1b. MEASURED ADVERSARY (Adjudicación y Auditoría) │
│ Filtra alucinaciones y crea lista definitiva de tareas │
└────────────────────────────┬────────────────────────────┘
│ (Entrega lista verificada)
▼
┌─────────────────────────────────────────────────────────┐
│ 2. DEVELOPER AGENT (Refactorización y Corrección) │
│ Aplica correcciones de raíz (Sin Expansión de Alcance) │
└────────────────────────────┬────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 3. SECURITY QA (Verificación Blue-Team) │
│ Corre linter, pruebas automáticas y audita diffs │
└────────────────────────────┬────────────────────────────┘
│
├─── [Fallas en QA] ──► 4. Corregir y Re-verificar
│
▼ [Pasada Limpia]
┌─────────────────────────────────────────────────────────┐
│ 5. CONVERGENCE GATE (Loop Iterativo de Red-Team) │
│ Re-inicia la cadena de ataque hasta obtener 0 hallazgos │
└─────────────────────────────────────────────────────────┘
El desarrollador recibe únicamente la lista verificada y aplica las correcciones de raíz.
Important
Aquí rige la Directiva de No Expansión de Alcance: el desarrollador tiene estrictamente prohibido andar inventando características nuevas nomás porque sí. El loop es primordialmente para limpiar, refactorizar y reparar.
Sin embargo, existe una excepción de último recurso: si para resolver un problema de diseño grave o una falla estructural no queda más remedio que desarrollar una nueva implementación o un componente de soporte totalmente nuevo, esto se permite únicamente como medida excepcional de último recurso con el fin de sanar la arquitectura de raíz.
Para que esto te jale al cien en tu entorno (ya sea con Antigravity, Opencode o la herramienta de agentes que utilices), te comparto las definiciones clave de los prompts que uso:
Prompts del Red-Team:
{
"extreme_adversary": {
"role": "Extreme Adversarial Code Reviewer",
"prompt": "Inspect code brutally and pedantically. Hunt for architectural smells, coupling leaks, SOLID violations, error swallowing, missing context propagation, and unhandled edge cases.",
"enable_write_tools": false
},
"measured_adversary": {
"role": "Measured Adversarial Auditor",
"prompt": "Evaluate extreme_adversary's report against the codebase. Understand that extreme_adversary is highly skilled at finding subtle bugs but prone to hallucinating or exaggerating due to extreme prompt pressure. Filter out hyper-pedantic noise, exaggerations, or hallucinations. Validate genuine defects and deliver the definitive task list.",
"enable_write_tools": false
}
}
Un detalle técnico crítico que descubrí en la práctica es que los agentes no deben intentar revisar todo el proyecto de un solo jalón. Si pretendes que un adversario audite un repositorio entero en una sola ejecución monolítica, el modelo se satura, se brinca archivos o termina haciendo una revisión superficial nomás por pura fatiga.
La clave está en fijar límites de pasos acotados y trabajar mediante múltiples pasadas enfocadas:
Tip
Llevo meses usando este protocolo en módulos críticos donde un fallo en producción sale muy caro. La neta, el tiempo extra que toma la convergencia se paga solo con la tranquilidad de tener un código impecable.
Note
Para que el Protocolo Crisol brille en todo su esplendor, se complementa de maravilla con mi estructura de especificaciones (specs) y roadmaps por fases. Mis especificaciones no son cualquier borrador rápido; abarcan tres niveles clave: técnicos, funcionales y de negocios, lo que le da a los agentes los límites exactos de la arquitectura y la visión del proyecto. Ese tema de la metodología de especificaciones y roadmaps está tan chingón que merece su propio espacio, así que te lo platicaré a detalle en un próximo artículo.
El Protocolo Crisol demuestra que la mejor forma de trabajar con IA no es pedirle que haga todo a la primera, sino poner a competir a agentes especializados dentro de una estructura de cero confianza. La separación entre ataque y adjudicación es lo que marca la diferencia entre un código parcheado y una arquitectura sólida como roca.
Pruébalo en tu próximo refactor complejo y verás cómo cambia la jugada. ¿Qué te parece este enfoque? ¡A poco no está perrísimo, no?!
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.9RC1 are available
RPMs of PHP version 8.4.24RC1 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)
remi )
on 2026-07-03 04:31:00 UTC
RPMs of PHP version 8.5.8 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.4.23 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.3.32 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
RPMs of PHP version 8.2.32 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-12184, CVE-2026-14355), 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)
feborges )
on 2026-07-29 11:45:27 UTC
We’ve just rolled out a new feature on Planet GNOME to bring our community discussions together! You can now opt in to automatically create a topic on discourse.gnome.org whenever you publish a new blog post.
Having comments centralized on Discourse makes it much easier for readers to discuss your posts, while also ensuring that all interactions are moderated under the GNOME Code of Conduct for a safer, healthier space. It is also a great way to give your content a bit more visibility with the active Discourse community without any extra manual work.
This is especially handy if you run a statically generated blog without an existing comment section, giving your readers a dedicated space to share feedback.
This feature is completely opt-in, so nothing will change for your feed unless you choose to turn it on. To get started, simply send a merge-request to Planet GNOME adding discourse_comments=1 to your blog entry in our config.ini file.
For this to work, I got the Planet’s static generator to produce a custom RSS feed for the blogs that flag the discourse_comments property. Then, Emmanuele Bassi configured our Discourse instance with the RSS Polling plugin, which creates a topic for each RSS feed entry.
Since this is brand new, there might still be a few rough edges. If anything breaks or acts weird when you try it out, let us know and we’ll get it fixed as soon as we can.
Happy blogging!
For many years, I didn’t think that Tor could be useful for me. However, I’ve recently found a Gist on GitHub that describes how you can use it to harden your central syslog-ng server. And while I have yet to try it, at least now I have a reason to actually test Tor.
The Tor website describes the project as follows: “Protect yourself against tracking, surveillance, and censorship.” I live in a country where thankfully I do not need these, nor do I perform any activities for which Tor would be useful. However, sometimes I hear from syslog-ng users that they want to hide their logging infrastructure with something more than what mutual TLS authentication makes possible. This is where this short how-to might be useful for you:
https://gist.github.com/hashgh0st/19bcfa4bfc96fbf0bbd2897b66c77db7/
The Gist is about how to install / configure syslog-ng and Tor on a FreeBSD client and server. I have a couple of FreeBSD boxes lying around, so I will test the instructions there. However, with minimal changes, the procedure should work on any Linux distribution as well.
Originally published at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-hardening-using-tor
admin )
on 2026-07-28 08:00:00 UTC
When I heard that Flock was the most awaited event every year for the Fedora community, and that I was going to be a part of it, I was genuinely excited. Gradually, I found myself involved right in the middle of Flock 2026 planning. Months of planning. Dozens of meetings. Meeting notes referenced and re-referenced every single week. New ideas, new proposals, sponsor packages, food logistics, team gifts, a candy swap, a games night, a Foundations Wall made of sticky notes and community feelings all of it building toward one event. Three days in Prague. That’s what Flock to Fedora is. And this year, Flock 2026 delivered.
This article is a brief summary and recap of what happened at Flock 2026 this year in Prague, Czechia. It covers my perspective as an intern in the Fedora community, working in the middle of all the action. Read on to know more about what happened at this year’s annual contributor conference!
Flock to Fedora 2026 ran from June 14–16 in Prague, Czechia, in the same city for the second time in a row. Sponsorship hit record numbers this year, with more unique sponsors committing to Flock than any past edition. A huge thank you to AlmaLinux, Arm, AWS, CentOS, Fleet, Framework Computers, Meta, Microsoft Azure, openSUSE, Red Hat, Rocky Enterprise Software Foundation, and Zabbix for making it possible.
The schedule this year was planned starting with “Day 0” (Sunday, June 14) with workshops and team meetups. Day 1 and Day 2 were about keynotes and streamed sessions built around Flock’s four themes:
Behind the execution of Flock, there was an incredible organizing team which handled everything from CfP logistics and on-site execution to design, travel coordination, website improvements, and a Matrix virtual experience that brought the conference to people who couldn’t make it to Prague in person (one like me). Planning kicked off months before the event, with weekly meet-ups, shared meeting notes, and sprint-by-sprint coordination across time zones and contributors. Flock doesn’t happen without these people.
Two community-driven additions gave Flock 2026 its own identity. The #CommitHistory interview campaign brought eight Flock speakers to Fedora Magazine, before the event even started, to share their first commit stories, contributor journeys, the very human reasons people keep showing up for this project, and why it really matters in this community. Also the Foundations Wall, a new interactive installation at the registration desk, asked attendees to share what Fedora’s Four Foundations mean to them on a whiteboard.
The post-event survey closed on 8th July with 117 responses and a 57.35% response rate. The results told a clear story. Nearly every single respondent said they felt more connected to the Fedora community after attending Flock in-person. In a community that does most of its work asynchronously across time zones, mailing lists, and Matrix channels, that response is everything.
The hallway track rated highest of all. Above the keynotes, above the workshops, above the sessions. The informal conversations, that’s what people came for. One respondent put it perfectly:
“Flock is starting to feel like a family gathering, but a good one.”
Sessions were rated valuable or extremely valuable by 92% of respondents. The venue and organization scored Excellent or Good from 97% of respondents. The reception night, the candy swap, the games night on Day 0, all of it landed warmly in the open responses.
The constructive feedback? Noise levels made hallway conversations harder than they needed to be. People wanted more unstructured hacking space. Virtual attendees wanted clearer navigation instructions for the online experience. As the organizing team begins to review the data and compare against our own feedback, we hope to take these ideas for improvements into the next edition of Flock.
The real measure of Flock is never the event alone. Another big part is what contributors do once they get home.
In the 30 days since Prague, the conversations that started in corridors have continued in Fedora Discussion threads. A fuller picture of survey responses and feedback will be part of a future Fedora Council town hall video meeting later this summer.
Survey respondents have spoken on what comes next. The organizing team is processing the feedback as we begin setting our sights on the next edition.
Flock 2027 is coming. And honestly? This time I’m hoping to be there in person. Fingers crossed.
mhayden )
on 2026-07-28 00:00:00 UTC
It’s been a while since I rented a dedicated server for my own personal infrastructure, but with the prices I’ve seen lately on cloud and virtual infrastructure, getting my own server seemed like a better detal. I prefer to do my own custom installation of Fedora Linux on my servers and this meant another deep dive into the world of Supermicro’s IPMI interface, horribly old versions of Java, and lots of frustration.
With some help from Claude, I found a better way to mount virtual media! ✨
It turns out I rented a machine with a fairly old ATEN-based BMC without any support for Redfish and that means no HTML5 console access. The Java console was the only remaining option.
Next, I downloaded Supermicro’s standalone IPMIView client.
It launched and connected without an issue.
Once I tried to mount an ISO, I ended up with a crash:
SIGSEGV (0xb), JRE 11.0.25 (bundled)
Problematic frame: V [libjvm.so] jni_CallObjectMethodV+0x83
C [libSharedLibrary64.so] AppendDataIntegrity(unsigned char*, int)+0xc6
C [libSharedLibrary64.so] MtMethod_Media+0x105
C [libSharedLibrary64.so] MtVM_Engine+0xba
C [libSharedLibrary64.so] Core_Mount_VM+0x45
C [libSharedLibrary64.so] UI_Mount_VM+0x227
C [libSharedLibrary64.so] Java_tw_com_aten_vstorage_VirtualStorage_VUSPlugIn+0x146
j tw.com.aten.vstorage.VirtualStorage.VUSPlugIn(...)
I tried bumping the java heap size and it didn’t help. Downgrading IPMIView didn’t help either. I even loaded up a Windows virtual machine with IPMIView and it crashed there, too.
Supermicro ships another utility called SMCIPMITool that talks to the BMC in a different way than the GUI does.
I always prefer a command line tool over a Java GUI. 😉
Download SMCIPMITool from Supermicro: https://www.supermicro.com/wdl/utility/SMCIPMItool/
Extract it:
$ tar xzf SMCIPMITool_<version>_bundleJRE_Linux_x64.tar.gz
$ cd SMCIPMITool_<version>_bundleJRE_Linux_x64
Confirm that the basic IPMI auth works before touching virtual media. If your account isn’t a full ADMINISTRATOR, specify the privilege level explicitly:
$ ipmitool -I lanplus -L OPERATOR -H <bmc-ip> -U <user> -P '<password>' chassis status
If this fails with a cipher suite error, try -C 1, -C 2, or -C 3.
Launch SMCIPMITool in interactive shell mode. This is required — the vmwa subcommands don’t work as one-shot CLI arguments:
$ ./SMCIPMITool <bmc-ip> <user> '<password>' shell
Ignore any Cannot login to <bmc-ip> banner printed at startup. That’s an unrelated SNMP trap-receiver warning, not an auth failure.
List the vmwa subcommands at the shell prompt to confirm the tool is talking to the BMC correctly:
vmwa
Mount the ISO on virtual device 2 (device 2 is CD/DVD/ISO; device 1 is HDD/USB/floppy):
vmwa dev2iso /full/path/to/your.iso
You may see a com.supermicro.ipmi.IPMIException stack trace print first — that’s a non-fatal internal retry. Look for the actual result right after it:
Mounting ISO file: /full/path/to/your.iso
Device 2 :VM Plug-In OK!!
Verify the mount:
vmwa status
You should see something like this:
Device 2: ISO File [/full/path/to/your.iso]
Keep the shell session open. On this firmware, the mount is torn down the instant the shell exits — there’s no detached or background mount mode. For an unattended mount-and-install, script it end-to-end instead of typing interactively:
( echo "vmwa dev2iso /full/path/to/your.iso"
echo "vmwa status"
sleep 3600 # keep mounted for up to an hour — adjust to your install time
echo "vmwa dev2stop" ) | ./SMCIPMITool <bmc-ip> <user> '<password>' shell
While that session is running, set the next boot target to USB CDROM in the IPMIView tool.
Then reboot the server.
The server should boot into the ISO that you mounted. The BMC network interface isn’t very fast and you’re also limited by your upload bandwidth, so be patient.
When you’re done, either let the sleep in step 8 expire (it auto-unmounts via vmwa dev2stop), or run vmwa dev2stop manually in an active shell session to unmount immediately.
Here’s the actual command I used, end to end:
$ D=~/Downloads/SMCIPMITool_2.27.2_build.230221_bundleJRE_Linux_x64
$ cd "$D"
$ ( echo "vmwa dev2iso /home/major/Downloads/Fedora-Server-netinst-x86_64-44-1.7.iso"
echo "vmwa status"
sleep 3600
echo "vmwa dev2stop" ) | ./SMCIPMITool <bmc-ip> operator '<password>' shell
Our ipa cluster is all reinstalled, but some issues remain:
https://accounts.fedoraproject.org is sometimes not allowing people to login. It gives a 'Unauthorized: bad credentials'. This seems sporadic and unclear how many people it effects.
fasjson is working, but slow to respond. This can result in things like …
Across the various Fedora working groups, the primary shared focus this week was the successful completion and subsequent fallout management of the Fedora 45 Mass Rebuild, which required extensive coordination from Release Engineering, Quality, and language-specific SIGs (like Python and Perl) to triage build failures and ABI changes. Another major cross-team initiative is the ongoing infrastructure migration to Forgejo, with the Docs, Infrastructure, Design, and Release Engineering teams actively working to transition repositories away from Pagure ahead of strict deadlines. Security, cryptography, and compliance also emerged as a prominent theme, highlighted by FESCo's new two-factor authentication (2FA) mandate for packagers, the Security SIG's efforts to align with the EU Cyber Resilience Act (CRA), and system-wide cryptography updates like the transition to Sequoia. Finally, teams are heavily engaged in Fedora 45 feature stabilization and policy refinement, actively addressing cross-desktop bugs—such as the memory-crashing default wallpaper in KDE—while updating governance and packaging guidelines to reduce contributor burnout and streamline community workflows.
For Fedora contributors, the Fedora 45 Mass Rebuild has officially completed, and a reminder was issued that the F45 Self-Contained Change proposal deadline has closed. To reduce contributor burnout and avoid split-brain conversations, an F46 Change Proposal aims to move all future Change discussions exclusively to the devel mailing list, ending simultaneous threads on Discourse. In other community news, the long-running Community weekly updates are being replaced by "This Week in Fedora". Developers looking to test new tools can engage with a proposed F45 Change to introduce encapsule, a new CLI utility for safely running untrusted internet scripts in isolated containers, which pairs nicely with a recent Fedora Magazine guide on sandboxing AI coding agents with microVMs.
Numerous technical Change Proposals were announced this week, notably for Fedora Atomic Desktops, which are slated to adopt the new Anaconda WebUI and gain web-based remote installation support. On the security and cryptography front, Fedora plans to transition RPM signature verification to Sequoia via a new %openpgpverify macro to support Post-Quantum Cryptography, and will begin phasing out the deprecated in-kernel Crypto Userspace API. System-level updates include deprecating the low-memory-monitor package in favor of native GLib handling, enabling systemd-oomd and zram swap by default on CoreOS, and updating authselect to both hardcode nss-altfiles and remove the outdated NIS profile. Finally, desktop users will benefit from an update to IBus 1.5.35, which improves XKB keymap handling across Wayland environments.
The Fedora Council is currently seeking community feedback on a draft Conflict of Interest Policy intended to guide governance groups. Following initial discussions, the draft will be revised to ensure it only applies to governance bodies, removes overly strict recusal requirements (such as preventing FESCo members from voting on their own changes), and protects contributor privacy under GDPR by not requiring the disclosure of the specific nature of a conflict. In infrastructure news, the Council advanced the Fedora Forge usage policy after reaching a compromise to mandate a "tickets" repository for all organizations as a unified contact method, rather than automatically archiving inactive repositories after 12 months.
Additionally, the Council addressed a few administrative requests. They investigated suspicious Forge organization requests originating from newly created accounts; while a vague Software Engineering SIG request was rejected, the situation successfully led to the revitalization of the Java SIG by an established contributor. The Council also reviewed a trademark permission request to sell Fedora community stickers on a Slovak open-source web shop, and granted an exception for FreeIPA to host an organization on the Fedora Forge due to its foundational role in Fedora Infrastructure.
Learn more about the Council team.
FESCo had a highly active week reviewing numerous Fedora 45 Change Proposals and discussing project policies. Major technical discussions included the Forgejo dist-git migration planning, a proposal to restrict Change Proposal discussions to the devel mailing list to prevent "split-brain" conversations, and a fast-track proposal to gate all stable release updates on rmdepcheck. The Enable Shadow Stack by Default on x86_64 proposal was deferred pending a clarified mitigation plan for affected software like Rust, Python extensions, and NVIDIA drivers.
On the security and contributor front, FESCo is officially requiring two-factor authentication (2FA) for all provenpackager group members, with a three-month grace period for existing members before their access is temporarily downgraded. A broader proposal to require 2FA for all packagers is also currently in the works. Additionally, the FESCo election policy was adjusted so that replacements for members stepping down mid-term will serve a full year if only one person drops out.
barrier and input-leap packages will be retired without Provides being added.Learn more about the FESCo team.
During their 2026-07-23 meeting, the Packaging Committee addressed broken links in the DefaultServices guidelines (FPC#1556), agreeing that linking directly to the fedora-release source tree is too fragile and difficult to maintain. They also reviewed a draft update for NPM packaging guidelines (FPC PR#1553). Contributors noted concerns with the draft's example spec file—specifically regarding how bundled libraries are handled as separate source tarballs and the disabling of automatic requirements. The committee will wait for the Node.js SIG to finalize the draft and address these concerns before conducting a deeper review.
Additionally, the committee discussed the need for clearer versioning guidelines for pre-release snapshots. A pull request is currently being drafted to explicitly define the use of the ~^ syntax, ensuring that untagged snapshots sort correctly before tagged pre-releases (e.g., beta1). This clarification will be proposed for gradual adoption to avoid disrupting existing packages and to help maintainers avoid sorting errors.
fedora-release package directly.Learn more about the Packaging Committee team.
In their July 23 meeting, the Mindshare committee discussed shifting their social media strategy to rely on "Digital Ambassadors" rather than a dedicated Marketing team, proposing the use of Buffer to securely manage account access. This new direction will be tracked in a fresh ticket, replacing the outdated issue #26. The team also addressed regional support by reviewing a swag request for the French community (issue #126) and noted the need to update the Meetbot documentation to reflect Matrix-native commands.
On the contributor engagement front, the CommOps team is actively seeking new members and a committee representative, prompting the reopening of CommOps issue #145. Highlighting this opportunity, a new contributor with a communications background recently introduced themselves on the forum to join CommOps. Meanwhile, the committee continues to seek asynchronous votes to finalize the Mindshare representative for the Fedora Council.
Learn more about the Mindshare team.
The f45-backgrounds package is now available in Rawhide, introducing wide-gamut color support for the default Fedora 45 wallpaper. To provide a cleaner Appearance menu, the "Time of Day" animated wallpapers have been separated into optional, dedicated sub-packages for GNOME and MATE. Shortly after the release, testers reported that the default wallpaper was rendering as solid grey in KDE due to memory allocation limits being exceeded by the massive 12800x12800 .jxl image file (mailing list thread). The design team will shrink the image to 8K in the next update to resolve this.
On the networking side, a forum discussion highlighted an issue with Fedora's IPv6 behavior on networks with non-persistent prefixes. When a router reboots and fails to invalidate old prefixes, Fedora attempts to route through older IPv6 addresses instead of defaulting to the newest one, causing connectivity drops until the old lease expires. Contributors are looking into a proper NetworkManager or kernel-level fix, but in the meantime, users can employ NetworkManager dispatcher scripts listening for dhcp6-change events as a temporary workaround.
f45-backgrounds-gnome-time-of-day and f45-backgrounds-mate-time-of-day).Learn more about the Workstation / GNOME team.
This week, the KDE group discussed a multi-monitor window management behavior where connecting an HDMI display automatically moves all open windows to the external screen, even if the laptop screen remains the primary display. Participants identified that KDE remembers window layouts and specific monitor hardware identities from previous sessions, which is likely a side-effect of the desktop environment's new "session restore" feature. While some users appreciate this persistent layout, others find it disruptive, particularly when applications do not open on the currently active desktop.
Contributors noted that this is an upstream KDE matter rather than a Fedora-specific bug. The behavior has been reported to the KDE bug tracker, and users clarified that it persists even when virtual desktops are configured to switch independently for each screen. Developers and contributors interested in refining session restore logic, multi-monitor window placement, or adding options to clear saved monitor layouts are encouraged to engage with the upstream KDE community to help improve this functionality.
Learn more about the KDE team.
During the weekly Server WG meeting, contributors advanced the Fedora home server spin-off by outlining a minimal KIWI development environment using libvirt, which will be documented in the home-server repository README. The group also discussed standardizing documentation styling, with a strong preference emerging for using backticks for CLI commands and file paths; a formal proposal will be added to the open pull request. In community news, voting to officially add Brett and Ro as working group members remains open until July 31, and contributors are encouraged to participate in manual installation testing for the upcoming Fedora 45 release.
In a forum discussion about Fedora's handling of non-persistent IPv6 prefixes, a community member provided a workaround for routers that fail to invalidate old prefixes after a reboot. Users experiencing connectivity drops can use NetworkManager's dispatcher.d to run a cleanup script on dhcp6-change, as there is currently no native kernel or NetworkManager option to force the system to exclusively use the newest IPv6 address.
Learn more about the Server team.
This week, the Infrastructure team made significant progress on the RHEL10 migration, successfully transitioning the batcave Ansible control host and IPA (FAS) systems, which caused some expected temporary monitoring alerts. Preparations for the Fedora 45 Mass Rebuild are also underway, including the removal of the F45 autosign config to prevent unnecessary re-signing by robosignatory, aligning with the recent F45 self-contained change deadline. On the Forgejo front, the team packaged Forgejo 15.0.5, deployed a new CI runner for the Marketing team, and began prototyping ForgeFiler—a Flask web application designed to securely handle sensitive reports like Code of Conduct violations and GDPR requests in private repositories.
There are several excellent opportunities for contributor engagement this week. The team is actively looking for help investigating broken image links on older MediaWiki pages, resolving grokmirror missing repository issues, and improving Zabbix monitoring by investigating SLA structures to reduce alert fatigue. Additionally, work continues on a Grafana proof-of-concept for the Fedora Data Working Group and the deployment of the new siguldry signing bridge in the staging environment.
public-inbox for SCM commits, utilizing yearly archives and placing it behind Anubis to evaluate its performance and manageability before a potential production rollout.Learn more about the Infrastructure team.
The Fedora 45 Mass Rebuild has successfully concluded, utilizing new retry logic scripts and updated, beginner-friendly documentation. Following the rebuild, Release Engineering ran the mass tagging script and filed FTBFS bugs for failing packages. To stabilize the buildroot and unblock Rawhide composes, several problematic builds—including desktop-backgrounds, jsoncpp, and openssl-pkcs11—were untagged. In other release news, F47 keys have been added to fedora-repos and are now available in updates-testing, and the f45-perl side tag was successfully merged to Rawhide.
Infrastructure migrations are progressing, with toddlers changes prepared for moving scm-requests from Pagure to Forgejo; a coordinated "flag day" will be scheduled once fedpkg updates land. For contributors looking to get involved, there are active efforts to consolidate mass rebuild script configurations and fix false positives in the need_rebuild.py tracker. Finally, maintainers are reminded to use the fedpkg request-unretirement command for automatic package unretirements rather than opening manual Releng tickets.
fedora-scm-requests repository will be archived only after the new Forgejo repository and related fedpkg changes are fully deployed and verified to prevent synchronization issues.Learn more about the Release Engineering team.
The Fedora 45 mass rebuild is now complete, with the next major milestone—the branch point and first change completion deadline—scheduled for August 11th. During their weekly meeting, the Quality team reviewed upcoming F45 Changes to plan community Test Days, highlighting features like RPM 6.1, Podman 6, and DrmPanicFrontend. In news relevant to the broader Linux ecosystem, the team investigated unexpected font changes caused by freetype 2.18 that may also impact CentOS and RHEL. Additionally, it was noted that the mcelog package is currently unmaintained, prompting discussions about finding a new maintainer or replacing it with rasdaemon by default.
For contributors looking to get involved, nightly composes for Fedora 45 Rawhide are actively seeking release validation testing. Testers can also evaluate the new f45-backgrounds package, which separates the "Time of Day" animated wallpapers into optional sub-packages, though an update is pending to fix a bug where the massive 12K image size breaks KDE Plasma. The team also made a major revision to the Fedora CI documentation, added new KDE start/stop tests to openQA, and welcomed a new young contributor looking for a QA sponsor.
Learn more about the Quality team.
The Fedora 45 backgrounds are now available in Rawhide, introducing wide-gamut color support and splitting the "Time of Day" animated wallpapers into dedicated sub-packages. Following reports that the initial 12800x12800 resolution caused memory crashes in KDE and GIMP, the wallpapers are being scaled down to 8K. Looking ahead, the Fedora 46 wallpaper inspiration poll is live until July 31st, asking the community to choose between four STEM figures whose names start with "U". In infrastructure updates, the team successfully migrated the upstream fedora-logos repository from Pagure to the Design team's Forgejo space, alongside updates to the fedora-remix-logos package.
For contributors looking to get involved, new UX and web design opportunities are available. The Fedora Websites and Apps team is seeking a design for a new credits page to showcase project contributors. Additionally, Project Resistor, a Fedora Remix, needs UX assistance to improve its Jekyll-based website. The team also finalized the YouTube thumbnails for Flock 2026 and continues iterating on a community onboarding flyer and an onboarding video series.
fedora-logos and fedora-remix-logos repositories have been officially adopted by the Design team and migrated to Forgejo.Learn more about the Design team.
The Docs team's primary theme this week was platform migration and content consolidation. A major focus remains the Forgejo migration tracker, driven by the strict July 31, 2026, deadline to move all active documentation repositories off Pagure.io. While the majority of Pagure repositories have been successfully migrated, contributors are finalizing the last few pending moves, including the Defensive Coding Guide and the i3 SIG docs. To further streamline information, the team also opened a new ticket to coordinate with Commops to resolve duplicate Special Interest Group (SIG) documentation that is currently split between the legacy Fedora Wiki and the official docs site.
Contributors looking to get involved can assist with the next phase of the Forgejo migration. With the Pagure deadline approaching, the team needs help opening separate planning tickets for remaining GitLab repositories (which involve more complex CI pipeline migrations) and reaching out directly to the owners of various GitLab and GitHub repositories to coordinate their moves.
Learn more about the Docs team.
During the Internationalization meeting, the team reviewed upcoming Fedora 45 changes, noting that proposals for fontconfig (System Wide Change) and LibreOffice Dictionaries (Self Contained Change) are currently moving through the approval process. The F45 mass rebuild has also finished with under 1,000 failures, and package maintainers are urged to check the failure logs for their packages. Specific rebuild failures with ibus-table and ibus-typing-booster were noted and are actively being investigated.
To help prepare for upcoming releases, contributors are encouraged to assist with Fedora 43 bug triaging by fixing outstanding issues or deferring them to a later release. The team also reviewed the upcoming schedule, highlighting the July 21 deadline for Self Contained Change proposals and the August 11 deadline for both branching Fedora Linux 45 from Rawhide and the testable completion checkpoint.
Learn more about the Internationalization team.
This week, EPEL focused on infrastructure improvements and package maintenance, prominently featuring a proposal for EPEL 11's minor version design that was also discussed in the weekly meeting. To prevent private mirroring errors, the proposal suggests keying URLs off the CentOS $stream variable rather than the RHEL $releasever_minor variable, though this first requires RHEL derivatives to stop improperly defining $stream. In package news, an accidental soname change in ImageMagick broke dependencies in EPEL-8 and EPEL-9, but patched builds have been published and are awaiting testing karma. Additionally, a slightly incompatible update replacing p7zip with 7zip is pending further discussion in upcoming meetings.
For contributors, feedback is requested on a planned migration to libgit2 v1.9 for EPEL 9 and 10 to resolve multiple CVEs; the maintainer plans to submit pull requests to affected packages soon. Other notable updates include CVE fixes for ntfs-3g and a contributed fix to fedpkg that enables feature branch workflows directly from EPEL minor version branches.
Learn more about the EPEL team.
During the July 21st meeting, the SIG announced that image-builder is now successfully building ELN qcow2 images, with hyperscaler images up next. The ELN mass rebuild is currently in progress following the F45 mass rebuild, presenting an engagement opportunity for contributors to help fix over 40 packages currently failing to build (F45FTBFS). Another contribution opportunity involves providing a ppc64le VM to the upstream retsnoop developer to fix architecture-specific bugs. In broader news, LXQt has been added to Extras in preparation for EPEL 10, python-wheel was dropped from ELN proper, and progress continues on bootc with a Konflux tenant merged and plans to explore composefs native images in the future.
boot.iso images will now only be created for BaseOS to match CentOS Stream and RHEL, which saves disk space and speeds up composes by over 30 minutes.Learn more about the ELN team.
This week, the Atomic group saw a brief but helpful update regarding system recovery. In a forum discussion on how to reset the root password in Silverblue, a community member highlighted that official documentation is now available for resetting passwords via rescue mode on Atomic Desktops. This provides a standardized and reliable resource for the broader Linux community when troubleshooting locked atomic systems.
Learn more about the Atomic team.
During the CoreOS meeting on 2026-07-22, the team highlighted that the proposal to merge Butane into Ignition has officially entered the FESCo voting phase. As part of this transition, Butane will undergo a procedural freeze to shift active development directly into the Ignition repository, a move expected to greatly improve configuration composability for users. Additionally, the group reviewed the Fedora 45 release schedule, noting that the proposal submission deadline for Self-Contained Changes has passed, with the next checkpoint for retiring orphaned packages scheduled for August 4th.
A significant portion of the meeting focused on a potentially disruptive proposal to increase the default /boot partition size for new installs. Developers raised concerns that older nodes retaining the smaller partition might eventually lose the ability to upgrade, forcing users to reprovision. To prevent users from accidentally clobbering custom data partitions during this process, an action item was created to form a small working group. This group will brainstorm failure scenarios and design safeguards against inadvertent data destruction, presenting an excellent opportunity for contributors to get involved in shaping safe upgrade paths and documentation.
Learn more about the CoreOS team.
This week, the AI & ML SIG focused on team roster management and establishing infrastructure for AI agent skills development. A notable change in membership occurred as a contributor requested to step down from the SIG due to time constraints and LLM-related burnout (Issue #36). On a broader scale, the group is actively working on standardizing AI capabilities using the Agent Skills specification, which allows guided, agent-neutral skill definitions to be shared, improved, and used by any model.
To support this growing initiative, the SIG successfully established a new "Skills Reviewers" sub-team to create, review, and curate shared AI skills in the skills-library repository (Issue #31). The necessary infrastructure, including a new FAS group and a linked Forgejo team, has been fully deployed and seeded with initial volunteers. For contributors looking to get involved, there is an immediate opportunity to provide feedback on the initial draft of the human reviewer guidelines, which has just been submitted as a pull request.
skills-reviewers sub-team in FAS and Forgejo, granting them write access to the ai-ml/skills-library repository. A lightweight review process was instituted, requiring at least one reviewer approval before merging skill PRs (Issue #31).salimma from all AI/ML SIG access control lists (FAS, Forgejo, and Discourse) per their request to step away from the group (Issue #36).Learn more about the AI & ML team.
The Fedora 45 mass rebuild is actively underway, with core components like binutils and annobin completed, and GCC 16 and Python 3.14 currently in progress. The team is managing build times across 19 RISC-V builders, noting intermittent build failures on RVA23 hardware and system hangs on P550 boards during Rust builds—though a recent SiFive firmware update resolves the latter. To improve build infrastructure, new high-RAM Titan boards from Arace are arriving, and contributors can help optimize Koji builder profiles to automatically route heavy packages to these faster nodes. Meanwhile, the transition from the K3 vendor kernel to Fedora RISC-V "omni" kernels continues, supported by updated documentation for K3 bootstrap and Milk-V Jupiter.
In broader ecosystem news discussed during the July 21 SIG meeting, PR 778 was merged into upstream rhboot/shim, paving the way for proper signed shim packaging in future releases. Additionally, the team is conducting virtualization testing on remote K3 hardware (including OVMF firmware tests) and engaging in technical discussions with Qualcomm engineers regarding a hardware-probing syscall to detect RISC-V extensions.
shim, the SIG will continue using the current standalone shim-unsigned-riscv64 package for the time being to ensure boot stability while the official Fedora packaging is sorted out.Learn more about the RISC-V team.
This week, the Security SIG focused heavily on aligning Fedora's security documentation with the EU Cyber Resilience Act (CRA) requirements (Ticket #14). During their weekly meeting, the team discussed creating a unified SECURITY.md file that designates Red Hat as the formal CRA steward while maintaining Fedora's community security processes. To improve visibility, contributors proposed surfacing these new policies and a standard security.txt file on Fedora's main marketing sites once completed (Ticket #16).
The group is also working on formalizing private vulnerability reporting channels and embargo processes. Ongoing discussions include setting up a secure Bugzilla component for incoming package and platform reports (Ticket #17), establishing Fedora representation on the private linux-distros mailing list alongside a pre-disclosure agreement (Ticket #13), and potentially creating a Fedora Badge to act as a "hall of fame" reward for external security researchers who submit valid reports (Ticket #18).
forge/security/docs repository to prevent bureaucratic delays while drafting the content.Learn more about the Security team.
This week, the Go packaging community discussed the introduction of docker-credential-helpers to Fedora. In a thread about packaging the application, contributors shared guidance on handling empty vendor archives and properly configuring CGO_CFLAGS and GO_LDFLAGS using macros to correctly build the pass and secretservice helpers. Additionally, an excellent contributor engagement opportunity has arisen: a call for reviewers and sponsors was made for a new contributor who has successfully recreated the SRPM to adopt the orphaned fx package and is currently awaiting a package review.
modules.txt warning from rpmlint (caused by a lack of vendored modules) is not considered a blocker for package approval.Learn more about the Go team.
The major focus this week is the Perl 5.44 upgrade, which has been approved by FESCo. A dedicated f44-perl build-root has been created for the delicate process of bootstrapping core modules. To avoid disruptions, contributors are explicitly instructed not to build anything into this new build-root, though they may freely continue pushing upgrades to Rawhide in parallel. In other ecosystem news, a rebuild for MySQL 9.7 was initiated for perl-DBD-MySQL, and perl-Coro-Multicore was manually patched to resolve an atfork_child naming collision with Perl 5.43.2+. Several routine version bumps were also merged for packages like perl-HTTP-Message and perl-ExtUtils-MakeMaker-CPANfile.
perl-HTTP-Daemon with Module::Build on RHEL was rejected and closed. Maintainers decided against carrying custom, untested patches in the repository, opting instead to strictly follow upstream development.Learn more about the Perl team.
Due to an incompatible ABI change in the Python 3.15.0b4 release, the team initiated a targeted rebuild of approximately 750 Python packages with extension modules in Rawhide. The rebuild took place in a dedicated side tag and experienced some delays due to slow s390x builders, culminating in a massive Bodhi update. The rebuild was officially completed on July 25, and normal Rawhide package builds have now resumed.
Maintainers of the roughly 30 packages that failed to rebuild during this process are asked to investigate and fix their builds in the side tag. The remaining failing packages are being tracked in a dedicated Bugzilla ticket (PYTHON3.15b4), presenting a clear opportunity for contributors to help get the remaining packages updated for the new Python 3.15 ABI.
Learn more about the Python team.
%openpgpverify macro to replace GnuPG with Sequoia, but developers strongly argued for keeping the existing %gpgverify macro name to avoid massive ecosystem churn and API/ABI breakage.ExcludeArch: %{ix86} to roughly 3,400 leaf packages to save build resources. While some suggested an opt-in approach for i686 instead, the consensus leaned towards moving forward with this opt-out approach via a formal Fedora 46 Change Proposal./openqa test on a PR to trigger tests on the corresponding Packit scratch build, with results reported directly back to the PR./etc to /usr. Adam Williamson raised concerns that this could disrupt existing workflows and scripts, suggesting it be escalated from a self-contained to a system-wide change.mysql8.0 package is retiring in Rawhide as it reached EOL upstream.sugar and sugar-browse).nettle3.10-devel compat package.rng-tools and the compose process, which was quickly fixed in a side tag.alizams and petpvc.e-antic is not yet compatible.apptainer, buildah, podman, and skopeo.jimtcl 0.84 introduced a jimtcl soname bump affecting openocd.
Last week I attended GUADEC in A Coruña, Spain. While I attend the conference every year, this one was extra special because 14 years ago we held the conference at the same location, and it was my first GUADEC ever. Great memories!
Back in 2012, I was an intern in the Google Summer of Code program, traveling abroad for the first time. Now I feel privileged to have spent all the years since then working on the GNOME project as a professional developer. It turned out to be everything (and more) that my younger self had dreamed of.
Now, living in the Czech Republic, my travel this time was quite smooth compared to my first trip to A Coruña. Vienna -> Madrid -> A Coruña. I managed to leave early in the morning and arrive at the accommodation just in time for the conference’s pre-registration party. Other than the nostalgia of being back in the same Rialta cafeteria, I was super happy to meet some of my long time GNOME friends.
While I stuck to all the talks in the first room, I have now caught up with the room 2 talks via the YouTube recordings. The conference was packed with great desktop content, as always.
On day 1, I would highlight Jakub’s “Symbolic Achievements” regarding the future of our UI icons and Matthias’ recent SVG work. The icon animation work opens up a universe of possibilities for building more polished UIs. At the end of day 1, I went on stage for the “Community Update” session, where I represented the GNOME Settings and the Internship Committee teams.
On day 2, Emmanuele Bassi continued his effort to establish more governance in our project. This inspired me (representing GNOME Settings) and some of the GNOME Shell team to sit down and discuss putting together a Core-Components/System Team. This way, we can collaborate and support each other more effectively across components. As we progress on vertically integrating our desktop experience, our projects become more and more entangled. This requires more and more collaboration and shared responsibilities. We will probably announce this team soon.
Continuing on day 2, Joan presented his progress on passwordless authentication in GDM and Carlos presented an interesting initiative for using Mutter as an application test framework. This could complement other testing methods (such as OpenQA) and help us move away from heavily using the accessibility API for some of our current dogtail-type of UI tests. Additionally, Adrian presented his challenges and ideas for session Save/Restore. This work looks promising and is highly desired by the general audience. This has already been reported on by LWN.
At the end of day 2 I had the chance to present “The Future of Boxes”. A demo of the work I have been doing on the side for the past couple of years to refactor and rewrite Boxes to use a new display widget (libmks), GTK4/libadwaita, and to be a Flatpak-first app. I have a blog post version of this talk coming out in a few days. I’m super excited about the progress I made on this project and how close I feel we are to making it useful for a general audience, just as the “old” Boxes served plenty of users and their workflows.
To wrap up day 2, I hosted our traditional “Intern Lightning Talks” session, where we highlighted the work of our Google Summer of Code interns this season. Two interns managed to attend GUADEC in person, while the other four sent pre-recorded presentations.
Day 3, Saturday, started with a morning-long AGM (the Foundation’s Annual General Meeting). The new format was much more engaging than the ones before. I also would like to praise Allan for doing an excellent job explaining the GNOME Foundation’s processes, finances, and initiatives. After lunch, we watched the traditional “State of the Shell” update from Carlos, Florian, Jonas and Michel. I was also happy to watch Andrea Veri’s update on the state of GNOME Infrastructure, and to learn that our project’s infra is in very good hands during these difficult times.
The local GUADEC organizers put together a lovely dinner experience for everyone. Besides the delicious food and drinks, I spent the night catching up with multiple GNOME friends. This was the same location where we held one of our social events back in 2012. The night sky view of the sea, the fresh air, and the memories were great.
With the three talk days finished, we spent two more days of BoFs/Hackfests. Sunday morning started with my “GNOME Settings BoF”. The session was attended by some well known contributors and also by a few newcomers interested in getting involved or getting answers about the future of our settings. We discussed various topics ranging from the maintenance of some subsystems, AI policy ideas, documentation, and plans for GNOME 51 and 52. I demoed some of my own work-in-progress branches and highlighted what others are working on. I was glad that we received some positive feedback on our recent changes and contributors committed to help review and test some of the work.
At the end of Sunday, I hosted a “GNOME Internship Committee Meetup,” where current and former interns joined Aryan, Maria, and me to discuss how we can improve our internship experience in GNOME. Topics ranged from onboarding and community bonding activities to feedback, etc…
On Sunday evening I went to the Plaza de Maria Pita, the main square in town, to watch the World Cup final between Spain and Argentina. As a football fan, I felt privileged to celebrate this game in the home country of the winning team.
On Monday morning I attended the Design Team BoF, where we discussed various topics, from a transparent topbar in the Shell, to action buttons on dialogs. I started prototyping changes to action dialog buttons for some GNOME Settings dialogs so that the team has something tangible to experiment with. At the end of Monday, my farewell from the conference was participating in the “Engagement Team” BoF. I was happy to see the team getting back in shape again, and how enthusiastic they are. Since I work on Planet GNOME and a couple of other websites, I was happy to help them discuss and develop some ideas for promoting more of our development work through engagement channels (social media accounts, blogs, news reporting, etc…).
On Tuesday, July 21, I flew back home through Barcelona and then Vienna (which is a couple of hours drive from where I live in the Czech countryside).
All in all, I would like to thank the GUADEC organizers for another unforgettable conference, the GNOME community for always raising the bar on the conference’s content, and Red Hat for funding my trip and accommodation in Spain.
I am looking forward to seeing you all next year!
Another busy week, another saturday... oh wait, a bit of a delay there. Read on for why.
The lass rebuild last week finished last sunday, and was merged in on monday. Overall it was pretty uneventfull from my perspective. No builders dropped out or had any problems, the upgrade on my rawhide laptop went fine and nothing really broke, some other folks stepped up and fixed some reporting problems and all the bugs for failing to build from source got filed.
There were 2 other smaller mass rebuilds that also landed this week:
python had to rebuild a bunch of packages due to a last minute bug This resulted in a bodhi update with 700+ packages in it, which was caused a few loading and bw issues, but worked pretty well in the end.
perl had their mass rebuild that was done and merged in. No particular issues from it.
Our ansible control host/general admin server got moved to rhel10 this week. Took a fair bit of tweaking. I installed a new batcave02, got it all setup and data synced to it and then on thursday swapped it in. Overall I think it went smoothly, and now we have a newer ansible version along with most everything else.
This has been a long standing annoyance for some folks, but I finally carved out some time to backport a patch and test and deploy things so that we now (at least on devel, users, devel-announce) are always doing DMARC mitigation for redhat.com email addresses.
The problem was that externally, redhat.com uses DMARC to indicate valid senders of the domain, but internally to us, they do not. So, our mailman instance doesn't think their posts need anything and sends them out as normal. That results in some users who have providers that check and reject on that reject those posts.
The patch adds a new admin field to set regex for domains that should alway be mitigated (that is the email shows as coming from the list itself instead of the sender email).
https://forge.fedoraproject.org/infra/tickets/issues/12487 has the nitty gritty
So, now we come to why my saturday was so busy sadly. We are moving our ipa clusters to rhel10. This worked very normally in staging and there were not any problems.
Production has prooved different. However late this week Michal, who had been doing the migration got 2 out of the 3 cluster members moved to rhel10. The last one was ipa01, and it wasn't syncing right. No problem right? We have 2 more servers?
Well, it turns out that ipa01 is 'special' in a lot of places. We had places where ansible just used the first server, where a list of servers was given, but 01 was always tried first, etc.
This resulted in a bunch of instability in various things and was a big pain to track down and fix up.
So, I poked at this friday some (and then a lot more saturday) and got everything using 02/03. As part of that though, I noticed what might be the core problem that we were having getting them moved: we had them using 8GB of ram each, and that was just not enough. I doubled all of them to 16GB and hopefully that makes syncing 01 work as expected on monday.
As always, comment on the fediverse: https://fosstodon.org/@nirik/116987173742608936
llaumgui )
on 2026-07-26 12:35:15 UTC
admin )
on 2026-07-24 22:00:00 UTC
Due to an ongoing upgrade of our IPA cluster, users may not be able to login to the accounts.fedoraproject.org interface. Already authenticated users may whiteness problems like not being able to see people in groups and search not functioning correctly.
Authentication to apps using id.fedoraproject.org and …
Last few years a small team of people in the CLE Team were working each week to prepare a Community update for you. First one published on October 21st 2021. We were starting with only Infrastructure and Release Engineering teams (+ initiatives we did in CPE Team at the time), but later added more teams to our weekly reports to bring people a better picture what is being worked on. We thank to everyone who read our updates and found some value in them.
But as life is going forward even this updates are evolving. Last few weeks @abompard worked together with us to improve his weekly report to include the sources we are using for this weekly reports. So I introduce to you This Week in Fedora as a replacement for Community weekly updates. I’m glad that this initiative I started few years ago was able to live for that long and hopefully helped a few people to find information they were looking for.
I would like to thank people who helped me working on Community weekly updates:
The post End of Community update appeared first on Fedora Community Blog.
I have been on vacations, which means today is a bit longer than usual. AI stuff is taking over, so there is a new section. I’ll keep it balanced, as I bounce between loving and hating it.
If you are looking for something good, check out the videos about Spike Jonze’s skate video and about Belle and locations.
AI entered software development at full speed this year, and it is significantly impacting open-source projects as well. In this article, I discuss several trends I have recently observed in open source in connection with AI, and how these trends are changing the world of open-source software.
This article was originally published on my Czech blog, but it received such an overhelming response that I decided to translate it into English and publish it here as well.
One of the trends that AI brings in general is an explosion of content. Search results are filled with generated websites, and social networks are inundated with generated images and videos. Source code is no exception. Today, GitHub is drowning in an ever-increasing number of repositories.
However, it is not as if a larger number of high-quality projects are being created. On the contrary, these are projects where you have no idea whether you can rely on them or not. In the past, if you stumbled upon a more extensive project with thousands of lines of code, there was a certain assumption that if someone went to the trouble of creating something like that, they would have some knowledge of the problem, a personal connection to their creation, and some willingness to maintain it going forward.
You can no longer rely on this at all. Today, you can generate a project with several thousand lines of code in a matter of moments. It could be complete nonsense or even something dangerous; it could be something functional that someone generated for their own immediate needs and posted to GitHub, but with no interest in turning it into an open-source project. Because a repository with code doesn’t make an open-source project. The difference between a piece of code on GitHub and an open-source project is that an open-source project solves problems and use cases for its users, not just the author’s one-off need. And most authors of such quick-and-dirty code simply aren’t interested in doing that.
This is clearly visible in projects like MeshCore, for instance. There are dozens of forks of everything imaginable. Missing a feature in the official MeshCore firmware? You just fork it, vibe-code the missing piece, and dump it on GitHub as MeshCore-UltimateEdition. The problem is that it was created with minimal effort, the author usually has no relationship to it, gets bored after a month, and it becomes abandonware before it even has a chance to age.
About ten years ago, people started saying that the concept of Linux repositories had run its course. In the 2000s, they were practically the only source of Linux software. If a project didn’t make it into distribution repositories, it had a problem. But then the number of open-source projects grew at such a rate that distributions couldn’t keep up. Users had to start getting their software elsewhere, and software authors learned to do without distributions. Just a few years ago, the “everything I need, I find in Debian” approach seemed definitively dead.
However, it is possible that curated software sources – like Linux distribution repositories – will make a comeback. The open-source software world is becoming so chaotic that users will once again start appreciating sources containing curated software that someone has vetted for them and that they can rely on six months down the road.
Another trend that AI has triggered in open source is ‘review overwhelm’. Previously, writing code acted as a natural filter because it required a non-trivial amount of effort and time investment. That is now gone, making code creation fast and easy. But someone still has to review this code before it goes into serious production. The review processes that worked in open-source projects for years are now at their capacity limits.
In GNOME 50, support for Google Drive was removed because nobody had been maintaining it for a long time. Users were naturally unhappy about it, and eventually, one user stepped up, re-added the support, and submitted it upstream to the gvfs project.
A colleague responsible for maintaining that project lamented that it was a change involving 4,000 lines of code. Even though it seems to work at a basic level, it was clearly generated using AI. He will still have to go through it line by line to verify that it actually works as intended and meets the code quality standards required to commit to maintaining it long-term.
Most of the effort has thus shifted from code creation to code review, which is typical for AI. The problem in open source, however, is that developers experienced enough to review and merge code were already a bottleneck before AI. Now, the problem has deepened significantly. And in the example above, my colleague can count himself lucky that the contributor is responsive and has shown long-term interest in the issue.
Today, that is more of a rare exception. Common contributions consist of someone wildly vibe-coding something without any deeper interest or understanding of the subject, and throwing it over the wall to the maintainers.
I have a fairly recent experience with this in Meshy. Someone submitted a pull request with 9,000 lines of changed code, which was supposed to add support for macOS. I spent an hour one evening doing a very quick review, and even during that short time, I ran into numerous issues: the code was blatantly AI-generated, several thousand lines were just completely useless replacements of single quotes with double quotes, parts of the code unrelated to the problem were modified, and it overwrote all the changes I had made in the main branch over the last few weeks.
The author never responded to my comments and I never heard from him again. My takeaway was that even that one hour was too big of a time investment for contributions like that, and next time I will reject them much faster.
Some projects are responding to this situation by tightening basic contribution requirements. For example, Flathub’s decision to reject AI-generated apps caused quite a stir. Many people criticized it as shooting themselves in the foot, but you have to look at their reality.
Flathub currently hosts several thousand apps, with more added every day. Only three people handle the reviews. Although their review process is highly automated, they do it very thoroughly, and a lot of manual input is still required. It’s clear their goal isn’t just to spot the worst slop, but to maintain a relatively high standard of code hygiene. In the last six months, I submitted two apps to Flathub, and the review process ultimately contributed to improving the quality of the apps themselves.
However, this has now clashed with the reality of people submitting completely vibe-coded apps without a shred of personal effort. The ticket template for requesting inclusion asks a few questions, including a requirement to upload a short video showing how the app works. It really isn’t demanding, and anyone can put it together in 15 minutes. Yet even that is too much effort for creators of AI slop.
Instead of fulfilling these minimal requirements, some labeled it an attack on Linux’s freedom and immediately vibe-coded an alternative to Flathub that was supposed to be open to everyone. Unsurprisingly, it barely lasted a month.
Not only do open-source maintainers lack the capacity to satisfy this demand for code review, but they are also losing the motivation to do it. Often, it would be faster for them to write the feature themselves, but the review process was historically how they cultivated new long-term contributors and potential successors. When someone sends you a vibe-coded contribution that cost them zero effort and which they likely don’t even understand, how do you expect to mentor them into a contributor who will help the project in the long run?
Open-source software was never just about the end result; it was also about the process – where contributors build a relationship with the project and grow into someone who will eventually pass that on to others. This stands in sharp contrast to the world of AI, where it’s all about the result. As fast as possible, with as little effort as possible.
In the 1990s, Francis Fukuyama declared democracy and liberal economics to be the ultimate victors in the arrangement of the world order. Today, as democracy erodes globally and the existing economic order crumbles, that looks like a prematurely bold statement to say the least. Similarly, just a few years ago, impressed by the developments of the last few decades, some hailed open source as the ultimate winner among software development models. Are we about to face a sobering reality check similar to Fukuyama’s thesis?
Lately, I’ve been observing a subtle, yet present trend of stepping back from open-source development. One argument against open development I hear concerns the aforementioned review overload. For some projects, the costs associated with being overwhelmed by AI slop can outweigh the benefits of useful community contributions. They might still publish the source code for transparency’s sake, but they transform from an open-development project into an open-source, closed-development project. And those who don’t care as much about transparency may close off the source code entirely.
Another argument against making source code public is the fear of license circumvention. Today’s LLMs train on source code regardless of its license and can then easily generate a similar solution that you can publish under whatever license you choose.
This isn’t an issue for permissive licenses, as the author has already accepted that anyone can do practically whatever they want with the code. However, AI poses a direct threat to copyleft licenses like the GNU GPL. Authors usually choose these to ensure their work remains open forever and that anyone who uses it shares their improvements back with the community. If an LLM trains on a project you’ve worked on for years and then generates a very similar solution published under a proprietary license, it effectively bypasses this principle.
Take MeshCore again as an example: the protocol itself and the firmware are open-source, but the clients are closed. Recently, it came to light in the community that a core team member secretly applied for the MeshCore trademark and started vibe-coding his own closed-source solutions based on the available code. MeshCore founder Scott Powell cited this as something that reaffirmed his decision to keep the client source code private. Specifically, he wrote:
So, I see open source, in the age of AI, as offering up your blood, sweat and tears for others to rip-off, but in innumerable ways.
We may disagree with Powell’s perspective, but it represents a legitimate stance that I see more and more often around me. I see lifelong open-source advocates – people who used to publish every last helper script because they wanted to share – who now keep those things to themselves, offering them to others only upon request. They have reasons similar to Powell’s.
Open source also grew out of the need to share. Writing code was hard; maintaining it was even harder. Why should everyone implement the same thing independently? Let’s join forces in an open-source project, write a shared library, and everyone can benefit from the results. The infrastructure powering the Internet today was built on this foundation. But AI is suppressing this need.
For instance, I encounter opinions that WordPress is dead because “I can just easily generate my own CMS.” In my view, that severely underestimates what an open-source project actually provides. It is so much more than just writing code, and this strategy of swapping a dependency on an open-source project for a dependency on an LLM might not pay off in the long run.
Nevertheless, the reliance on shared open-source components has indeed decreased to some extent. AI might not replace everything, but why depend on a large external library when you don’t even need 10% of its functionality, if AI can quickly rip off that 10% for you after learning from the original library? And once you have your own implementation, why would you contribute improvements back to a shared open-source project?
The final argument against publishing source code that I’ve been hearing lately is security. Granted, I’ve heard this argument throughout the two decades I’ve been involved in open source, but it has never been this loud. For years, critics have claimed that open source is insecure because it allows attackers to study the code and hunt for vulnerabilities. In response, open-source advocates argue that security through obscurity is not real security and that open-source software is safer because “given enough eyeballs, all bugs are shallow.”
Today, however, open-source projects are literally flooded with security vulnerability reports generated by AI. The volume is so unprecedented that it is genuinely easy to fall into the trap of believing closed code is safer. It’s interesting to note that while news headlines cover how many bugs AI has found, they rarely mention how many security bugs AI has fixed. Fixing them still requires a deep understanding of the codebase and is still done by human programmers. And just like reviewing pull requests, it is overwhelming their capacity.
In this case, though, I believe it’s just a temporary trend. Open-source projects will eventually wade through these security reports, the general security of maintained open-source software will improve, and the ecosystem will benefit in the end. As for the other trends mentioned in this article, it’s hard to say. I’m not quite as unconditionally optimistic there.
feborges )
on 2026-07-23 07:01:18 UTC
Putting on my Planet GNOME editor hat for a quick PSA!
Planet GNOME is a convenient aggregator for personal blogs by members of our community. While all content must follow our Code of Conduct, the views expressed in these posts are solely those of the individual authors.
They don’t represent or reflect the opinions of the GNOME Project as an entity or community.
To help highlight this, we’ve added a “Voices of the community” tagline to the website header. It links directly to our “Add feed” section, which also emphasizes that Planet collects the latest posts from personal blogs.
Enjoy the personal insights and variety of perspectives!
If you want to start a fight, bring up the topic of closing unresolved issues. People have strong opinions on this topic, and for good reason. To maintainers, open issues can be overwhelming. They represent a backlog of work that will never get done. To users, issues represent a real pain point. If bug reports reports are contributions — and they are — then opening an issue is often the first (or only) contribution a particular person will make to the project. A bad bug reporting experience is a bad contributor experience, and it may chase someone away for good.
Just about everyone would agree that there are some cases where closing an unfixed issue makes sense. Not everyone will agree on where to draw the line, though. In general, the best approach is to have a clear, well-communicated policy and to close issues with respect for the time that people put into filing them. The rest of this post has my suggestions for how to approach closing issues. You, of course, can set whatever policy you want for your project.
Not included in the list above are resolved issues: fixed bugs and implemented feature requests. There’s no question that these should be closed. The only question is “when?” I’m partial to closing these when the fix or feature is in a shipped release. The tooling doesn’t always make that easy. Fedora has some automated connections between its update system and Bugzilla that will move reports through automatically. GitHub-hosted projects tend to close issues when a commit or pull request that says “fixes #12345” lands in the primary branch. There are ways to queue closures for when a corresponding release lands, but it tends to be more effort than most maintainers are willing to set up (myself included).
This post’s featured photo by Neringa Hünnefeld on Unsplash.
The post How to close issues appeared first on Duck Alignment Academy.
czanik )
on 2026-07-22 11:56:05 UTC
Choose your poison: Up until version 4.12, when syslog-ng ran into an error jumping to a saved systemd journal position, it read the journal from the beginning. With the latest syslog-ng version, you can configure what happens in case of such an error.
Read more at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-journald-source-how-to-avoid-log-bombs-on-errors
renich )
on 2026-07-22 11:00:00 UTC
Hoy me puse a experimentar con la arquitectura de MicroVMs en QEMU y libvirt, y la neta me quedé impresionado.
Si tú me has seguido por acá, sabes que en varios escenarios de migración desde entornos legacy (como VMware) a clusters hiperconvergentes de 3 nodos con libvirt y Ceph, el reto clásico siempre ha sido la eficiencia: las máquinas virtuales tradicionales tardan entre 30 y 90 segundos en arrancar y tragan gigabytes de RAM nomás para estar paradas.
Hoy te voy a enseñar cómo armé un motor de compilación efímero que arranca una máquina virtual aislada por hardware en menos de 200 milisegundos, compila tu código o empaqueta un RPM, guarda los artefactos y se destruye sin dejar rastro.
Normalmente, cuando un desarrollador quiere compilar algo con dependencias nativas (por ejemplo, una aplicación en Crystal con bindings a libssh como mi proyecto shellmin), se topa con dos caminos incómodos:
Note
La idea aquí es ofrecer un servicio de MicroVM Build-as-a-Service. El desarrollador no necesita acceso shell al servidor ni cuentas en el hypervisor; nomás empuja su código o dispara un webhook y la infraestructura hace todo de volada.
Para mantener las cosas simples y alineadas a la filosofía de Linux, en lugar de obligar al desarrollador a escribir scripts de inicialización complejos o configurar XMLs mamones, la máquina virtual lee los archivos planos repos y build_deps en la raíz de su repositorio.
En proyectos del mundo real, no basta con declarar únicamente los paquetes en build_deps; muchas veces requerimos habilitar fuentes externas (como repositorios COPR o repositorios de terceros como MariaDB o RabbitMQ) en el archivo repos. Por ejemplo, para compilar nuestra aplicación en Crystal con bindings a libssh (shellmin), necesitamos habilitar el repositorio COPR de zawertun/crystal antes de que el manejador de paquetes pueda instalar crystal.
En el archivo repos declaramos las fuentes externas:
# repos
zawertun/crystal
Y en el archivo build_deps declaramos los paquetes requeridos:
# build_deps
crystal
shards
libssh-devel
gc-devel
pcre2-devel
openssl-devel
gcc
make
¿Y cómo regresan los artefactos compilados al host? En lugar de andar extrayendo archivos a mano con herramientas de disco o SSH, la MicroVM utiliza un montaje de directorio compartido por hardware mediante VirtioFS (o 9p). El orquestador monta la carpeta del trabajo en el guest en /etc/build_workspace. Cuando el proceso de compilación genera los binarios o paquetes RPM, los escribe directamente en la carpeta compartida artifacts/, por lo que el host recibe los artefactos terminados de inmediato en su disco local.
Para que la automatización sea totalmente explícita y transparente, desacoplé la configuración en archivos independientes. Nada de andar metiendo bloques culeros dentro del script principal; todo se lee directamente del disco.
Aquí te muestro los componentes principales que utilicé:
<!-- microvm_build.xml -->
<domain type='kvm'>
<name>microvm-shellmin-builder</name>
<memory unit='MiB'>128</memory>
<vcpu placement='static'>2</vcpu>
<os>
<type arch='x86_64' machine='microvm'>hvm</type>
<kernel>/boot/vmlinuz-current</kernel>
<initrd>/var/tmp/microvm-initrd.img</initrd>
<cmdline>console=ttyS0 quiet reboot=k panic=1 pci=off</cmdline>
</os>
<features>
<acpi/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<filesystem type='mount' accessmode='passthrough'>
<driver type='virtiofs'/>
<source dir='/var/tmp/build_workspace'/>
<target dir='build_workspace'/>
</filesystem>
</devices>
</domain>
#!/bin/sh
# microvm_init.sh
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs none /dev
# Montar espacio de trabajo compartido VirtioFS desde el host
mkdir -p /etc/build_workspace
mount -t virtiofs build_workspace /etc/build_workspace
printf "\n[GUEST INIT] MicroVM kernel booted successfully!\n"
# 1. Procesar fuentes externas de repositorios (repos)
if [ -f /etc/build_workspace/repos ]; then
printf "[GUEST INIT] Procesando repositorios externos...\n"
while IFS= read -r line || [ -n "$line" ]; do
case "$line" in
\#*|"") continue ;;
https://*|http://*)
printf "[GUEST INIT] Descargando repo: %s\n" "$line"
curl -sSL -o "/etc/yum.repos.d/$(basename "$line").repo" "$line"
;;
*)
printf "[GUEST INIT] Habilitando COPR: %s\n" "$line"
dnf -y copr enable "$line" &> /dev/null || true
;;
esac
done < /etc/build_workspace/repos
fi
# 2. Procesar paquetes de dependencias de compilación (build_deps)
if [ -f /etc/build_workspace/build_deps ]; then
printf "[GUEST INIT] Instalando dependencias de compilación...\n"
deps="$(grep -v '^#' /etc/build_workspace/build_deps | tr '\n' ' ')"
if [ -n "$deps" ]; then
dnf -y install $deps &> /dev/null || true
fi
fi
# 3. Ejecutar la compilación del proyecto (shellmin)
if [ -d /etc/build_workspace/shellmin ]; then
printf "[GUEST INIT] Compilando aplicación Crystal (shellmin)...\n"
cd /etc/build_workspace/shellmin
shards build --release --without-development
cp bin/shellmin /etc/build_workspace/artifacts/
fi
poweroff -f
#!/usr/bin/bash
# run_microvm_build.bash
set -euo pipefail
IFS=$'\n\t'
readonly ScriptDir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly DomainName="microvm-shellmin-builder"
readonly Timestamp="$(date +%Y%m%d-%H%M%S)"
readonly JobId="job-${Timestamp}-$((1000 + RANDOM % 9000))"
readonly JobResultsDir="${ScriptDir}/results/${DomainName}/${JobId}"
readonly ArtifactsDir="${JobResultsDir}/artifacts"
readonly LogsDir="${JobResultsDir}/logs"
readonly TmpDir="$(mktemp -d --tmpdir=/var/tmp microvm-shellmin-poc.XXXXXX)"
chmod 755 "$TmpDir"
cleanup() {
local exit_code=$?
printf "[CLEANUP] Limpiando dominio %s y directorio %s...\n" "$DomainName" "$TmpDir" >&2
virsh -c qemu:///system destroy "$DomainName" &> /dev/null || true
virsh -c qemu:///system undefine "$DomainName" &> /dev/null || true
rm -rf "$TmpDir"
exit "$exit_code"
}
trap cleanup EXIT
prepare_workspace() {
local -r workspace="$TmpDir/build_workspace"
mkdir -p "$workspace/artifacts" "$ArtifactsDir" "$LogsDir"
# Copiar manifiestos repos y build_deps
cp "${ScriptDir}/repos" "$workspace/repos"
cp "${ScriptDir}/build_deps" "$workspace/build_deps"
# Clonar código fuente a compilar
git clone --depth=1 https://gitlab.com/renich/shellmin.git "$workspace/shellmin" &> /dev/null
}
run_microvm_build() {
local -r runtime_xml="$TmpDir/runtime_domain.xml"
local -r exec_log="$LogsDir/build.log"
virsh -c qemu:///system define "$runtime_xml" &> /dev/null
virsh -c qemu:///system start "$DomainName" &>> "$exec_log" || true
}
Note
¿Por qué usar /var/tmp en lugar de /tmp? En sistemas Linux modernos (como Fedora y RHEL), /tmp está montado en memoria RAM usando tmpfs. Si guardas árboles de código o artefactos grandes ahí, saturas la memoria del servidor de volada y no va a escalar. Por eso usamos /var/tmp, el cual está respaldado por almacenamiento en disco.
Un error común en motores de compilación sencillos es volcar todos los logs y binarios en una carpeta plana como results/. Al hacer esto, compilaciones subsecuentes terminan sobreescribiendo los logs y los binarios producidos.
Para solucionar esto de raíz, cada trabajo de compilación genera un directorio único con espacio de nombres (Namespacing) basado en el proyecto y el ID del trabajo (timestamp o UUID):
results/
└── microvm-shellmin-builder/
└── job-20260722-060942-2579/
├── artifacts/
│ └── shellmin
└── logs/
├── build.log
└── microvm.log
De esta manera, cada compilación mantiene un historial 100% aislable, auditable e inmutable, sin riesgo de sobreescribir artefactos o logs anteriores. Gracias al montaje de directorio compartido por VirtioFS, la subcarpeta artifacts/ recibe los binarios compilados en el host en tiempo real antes de que la VM efímera se autodestruya.
Seamos honestos: en el estado actual de este PoC, mantener scripts de inicialización en shell artesanales (como microvm_init.sh) con montajes manuales de /proc o scripts orquestadores en el host (como run_microvm_build.bash) resulta verboso, intimidante y propenso a errores tanto para desarrolladores como para sysadmins.
Para llevar este patrón de diseño a producción y evitar que el equipo tenga que lidiar con la fontanería interna de KVM/libvirt, la arquitectura se simplifica y abstrae mediante estas cuatro mejoras:
Internamente, el proceso se alinea al estándar FHS (Filesystem Hierarchy Standard) para mantener una estructura organizada:
A final de cuentas, las MicroVMs con libvirt y QEMU nos permiten tener lo mejor de dos mundos: la seguridad total de aislamiento por hardware (KVM) que solías tener en VMware, combinada con la velocidad de arranque en milisegundos (< 200 ms) que esperas de un contenedor.
Si tú estás buscando modernizar tu infraestructura sin regalarle privilegios a nadie ni saturar tus servidores con VMs pesadas, este patrón de diseño te va a hacer un paro chingón.
¿Qué te parece? ¿Te gustaría implementar algo así en tu infraestructura? ¡Platícamelo en los comentarios!
catanzaro )
on 2026-07-20 13:20:06 UTC
Due to the increase in AI-generated security vulnerability reports, it is time for some changes in how GNOME manages vulnerability reports.
These policy changes intentionally do not distinguish between reports that contain AI-generated content and those that do not. Following the same rules for all vulnerability reports is simpler than having two different ways of doing things. Reporters rarely disclose AI use, and it’s nice to not have to guess whether the issue report is AI-generated or not; it’s normally obvious, but not always. Also, vulnerability reports that are not discovered by AI are becoming increasingly rare. Non-AI reports are now moderately unusual, so it really doesn’t make sense to optimize for them.
Traditionally, I have applied a 90 day disclosure deadline to all security issues reported to GNOME Security. 90 days is an industry standard timeline, but it doesn’t work particularly well for GNOME. In practice, almost all GNOME maintainers handle vulnerability reports in one of two ways:
The 90-day deadline is intended to allow project contributors time to fix the issue before it becomes public, but in practice, maintainers do not actually make use of most of this time. I disclose the issue report and request a CVE when it is fixed or when the disclosure deadline is reached, whichever comes first. Once a CVE is assigned, contributors who are not regular project maintainers will sometimes attempt to fix it. Accordingly, keeping the issue reports confidential for 90 days only introduces a delay that is not useful.
Some other projects, notably the Linux kernel, have implemented an immediate full disclosure policy for issue reports that seem to be AI-generated, on the basis that a vulnerability that can be discovered by AI is presumably already known to attackers. But this policy seems pretty extreme, and is certainly unkind to maintainers who might feel pressured to urgently fix the issue. Immediate disclosure would not work well for GNOME.
Instead, I will switch to a 30 day disclosure deadline for issues reported on August 1, 2026 or later. This seems like a good compromise. The shorter deadline would probably work better for GNOME even if not for the increase in AI-generated issue reports.
If a project prohibits issue reports that contain AI-generated content, I will no longer forward security issues reported to GNOME Security to the project’s issue tracker, since the overwhelming majority of vulnerability reports contain AI-generated content and would violate the project’s policy. Instead, I will immediately close the issue report in the GNOME Security issue tracker, then ping the project maintainers to let them know about the existence of the report. If you prefer to receive vulnerability reports in your project’s issue tracker, then please change your project’s AI policy to make an exception for vulnerability reports.
Unfortunately, GNOME maintainers don’t have access to confidential issues in this issue tracker, and GitLab does not allow CCing individual developers on confidential issue reports. I had been planning to adopt immediate disclosure for these issues only, but perhaps we should instead expand the permissions to allow all GNOME developers to see the issue tracker. Opinions welcome.
I have been managing GNOME security issue tracking since November 2020. (Thank you to Red Hat for supporting this work.) Security tracking is largely a secretarial duty: I keep track of issues when they are reported and when they are closed, disclose them when the deadline is reached, and request CVEs when appropriate. It is not a huge amount of work, but I am getting tired of it, so it’s time for a change. 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.
Currently nobody else is tracking GNOME security issues. If you are an experienced GNOME community member and you are interested in taking over this work, let me know and I will help you get started. (Security tracking is not a good task for newcomers.)
This may also be an opportunity to improve our tracking infrastructure. I use a wiki page, but this is fairly primitive and requires considerable manual upkeep. It’s easy to forget to update the page when an issue report is closed, for example. Ideally, we would replace the wiki with a proper web app that dynamically updates based on the actual state of the issue.
asn )
on 2026-07-20 13:09:40 UTC
TL;DR https://codeberg.org/cryptomilk/crane-wyoming
I use Home Assistant, and for text-to-speech (TTS) I’ve been running Piper through Wyoming Piper.
Piper is a fast, local neural TTS engine originally built for the Rhasspy project and now maintained by the Open Home Foundation. It’s designed to run entirely offline, even on modest hardware like a Raspberry Pi.
Wyoming is the open protocol Home Assistant uses to talk to voice components like TTS, speech-to-text, wake word, voice activity detection (VAD, which decides when someone has started or stopped speaking) over the network, so any service that speaks Wyoming can be plugged in as a satellite. Wyoming Piper just wraps Piper so it can be served this way.
Both work well and I have no complaints about reliability. My issue is quality: the German voices aren’t great. Piper depends on open datasets for training, and good open German speech data is scarce, so the German models lag behind the English ones. I also run TTS locally on my desktop for event reminders, so voice quality matters to me beyond just Home Assistant.
I wanted better output quality, so I started looking at alternatives and found Crane, a Rust inference
framework built on Candle.
An “inference model” is a trained neural network used to actually produce output like text, speech, an image, rather than to learn from data (that’s “training”). An “inference framework” is the software that loads such a model and runs it efficiently: managing GPU/CPU memory, batching requests,
and exposing an API around it. Piper and Crane are both inference frameworks.
Crane already had Qwen3-TTS support, and its Serena voice’s German output sounded noticeably better. I also wanted to try Voxtral-4B-TTS-2603, Mistral’s open-weight TTS model, so I added support for it. Voxtral TTS produces expressive, natural-sounding speech across 9 languages including German, with low time-to-first-audio and streaming support. It is a good fit for a voice assistant that needs to start speaking quickly.
Once Voxtral was working in Crane, I built crane-wyoming, a standalone Wyoming protocol server, so Home Assistant could use these models as its TTS service. To make that possible, I added the Tts trait and the surrounding TTS abstractions to Crane, since there was no stable interface for driving a TTS model on its own, separate from Crane’s full inference engine (tokenizer/LLM/VLM machinery). Those abstractions have since been merged upstream: lucasjinreal/Crane#44.
crane-wyoming depends on Crane only for that Tts trait and the concrete model types it needs to construct, not Crane’s engine crate. So it carries its own small TTS-only model runtime (one dedicated worker thread per loaded model) and its own on-disk response cache.
The project grew into a small Cargo workspace. Besides the Wyoming server
itself, it now has cw-say, a standalone CLI client for scripting.
It also has sd_crane_wyoming, an output module for speech-dispatcher. speech-dispatcher is the common Linux TTS abstraction layer that screen readers like Orca, and other accessibility tooling, talk to. It launches output modules as subprocesses and speaks to them over stdin/stdout, using its own line-oriented, SMTP-style protocol. sd_crane_wyoming translates that into Wyoming requests against a running crane-wyoming server. That way, the same server process and cache serving Home Assistant can also serve the desktop. After registering it in speechd.conf, spd-say -o crane "..." works. So does anything else built on speech-dispatcher, like Firefox’s “Read Aloud” or Orca itself. All of it gets the same voice quality as Home Assistant, without running a second TTS backend.
With all of that implemented, you’d have a complete self-hosted Wyoming voice stack with no cloud dependency.
The catch is that you need a GPU to run it well.
If you only need TTS for occasional things like reminders, short announcements, running it on CPU with caching is enough, since repeated phrases just get served from cache instead of resynthesized.
All of this is for advanced users and hackers right now. There’s no polished packaging yet. Systemd units exist for both system and user services, including socket activation, but you still have to build from source.
However testing and feedback are welcome.
Another week, another saturday post recaping things. :)
Bunch more things reinstalled with RHEL10 this last week. Made some good progress. We are soon going to be down to the 'tricky' ones that will require an outage. So, there will likely be an outage or two in upcoming weeks to knock those out before Fedora 45 branching.
The mass rebuild for f45 started this last week and seems to be moving along fine. Of course s390x is the slowest arch, but thats not unexpected.
I did manage to update all the builders and reboot into the latest kernel before the mass rebuild started, along with updating to koji 1.36.1. So far no builders have dropped off or failed that I am aware of, which is nice.
This last week we noticed that out dns geoip setup wasn't updating correctly and had some pretty old data in it. This may have been causing some network blocks in some regions to go to proxies that are... not in those regions. ;(
Thanks to work from Vit Smolík, it's now updating correctly. So, for some fedoraproject.org services hopefully some folks will see improved performance with web application access.
I also added memory to some proxies and removed some from the EU zone that were not really in EU.
Thats about it this week...
As always, comment on the fediverse: https://fosstodon.org/@nirik/116942283487085494
Across the various Fedora working groups, a primary shared focus is the execution of the Fedora 45 Mass Rebuild, which aligns with widespread efforts to modernize core toolchains, system defaults, and developer environments. Another major cross-team initiative is the ongoing infrastructure migration from Pagure to Forgejo, requiring coordination across FESCo, Release Engineering, Design, and Docs. Artificial intelligence and automation have also emerged as a prominent, dual-sided theme: while teams like AI & ML, Security, and Release Engineering are actively developing AI agents to automate nightly compose log analysis and vulnerability scanning, Infrastructure and Release Engineering are simultaneously deploying defensive measures—such as retaining the Anubis system and disabling web-based git blame—to mitigate aggressive AI web scrapers. Finally, there is a strong, unified push toward improving community governance and the contributor experience, evidenced by the drafting of new usage and conflict of interest policies, the creation of the Docs Captain pilot program, and the development of modernized onboarding materials.
For Fedora contributors, the Fedora 45 Mass Rebuild has officially started, and maintainers are encouraged to track build failures on Koji. Related to package maintenance, a list of long-term FTBFS (fails to build from source) packages has been published; these packages have failed to build since Fedora 42 and will be retired in early August unless they are fixed or exempted. On a celebratory note, the latest Fedora Podcast (episode 056) highlights the 2026 Fedora Contributor Recognition Program winners, featuring a great conversation with Justin Forbes and Ankur Sinha about keeping the project running and welcoming.
Several new self-contained Change Proposals have also been announced for Fedora 45. The distribution's default databases are slated to be updated to the latest LTS releases, MySQL 9.7 and MariaDB 12.3. The ODBC stack is being modernized to replace static driver registrations with auto-generated configurations using per-driver drop-in snippets. LibreOffice will see two major packaging improvements: the introduction of upstream-sourced hunspell dictionaries for better version syncing, and a switch to HTML-based, noarch help files to significantly reduce repository space. Finally, to simplify Fedora CoreOS provisioning, a proposal aims to enable Ignition to natively accept Butane YAML configurations directly at first boot, removing the need for a separate transpilation step.
During the bi-weekly meeting, the Council reviewed the draft Conflict of Interest Guidelines and agreed to publish the document on Discourse for a two-week public feedback period, offering a key opportunity for community engagement before the rules are formalized. The Council also discussed the upcoming Fedora Forge Usage Policy, focusing heavily on the proposed rules for archiving inactive repositories. To avoid disruptive surprises for existing contributors, the Council formally took ownership of the policy's publication but decided to delay its release until a consensus is reached on how to handle repository archiving. Additionally, members were reminded of an open ticket regarding the Fedora logo license, which will be closed as the license cannot be changed.
On the forums, the discussion surrounding the Fedora Innovation Lifecycle continued with a focus on re-imagining "Initiatives." Members proposed a lightweight, self-managed alternative to the Sandbox process that would allow contributors to showcase multi-release work without strict deadlines or approvals, relying instead on simple "heartbeat" checks to ensure the projects remain active.
Learn more about the Council team.
This week, FESCo processed a massive wave of System-Wide Change proposals for Fedora 45, establishing a clear theme of modernizing core toolchains, system defaults, and developer environments. Significant proposals under review include switching the default Secrets Service to oo7, disabling DNF vendor changes by default, and updating major stacks like LLVM 23, Ruby on Rails 8.1, and MySQL 9.7. During their weekly meeting, the committee discussed the upcoming Forgejo distgit migration, agreeing to wait for a published roadmap to ensure proper community feedback on permissions, push rules, and CI integrations before proceeding.
FESCo also addressed late-arriving changes impacting the mass rebuild schedule. While the GNU Toolchain Update was approved to proceed, the Shadow Stack enablement was postponed due to unresolved concerns about breaking third-party applications and Rust-based packages. Other common work topics this week included infrastructure housekeeping (such as updating election policies and issue templates) and routine package maintenance, including handling non-responsive maintainers and retiring inactive software projects.
ledger package following the non-responsive maintainer process.Learn more about the FESCo team.
In a brief follow-up to the Fedora Workstation Working Group meeting minutes, it was confirmed that the group will be taking a short break from their regular meeting schedule. Due to members traveling to the GUADEC conference and other scheduling conflicts, all meetings for the remainder of July have been called off.
Learn more about the Workstation / GNOME team.
The Server Working Group held a weekly meeting (with the agenda and summary posted to the mailing list) focusing on release testing, documentation, and the Fedora home server spin-off. To make F45 release testing more accessible for contributors, the team introduced a new project board and ticket system, which will eventually be automated. For the home server spin-off, a contributor volunteered to set up and document a local Kiwi development environment so others can easily join the effort. The group also discussed updating the contributor's guide to remove outdated Pagure links and welcomed upcoming documentation contributions regarding mDNS and Ansible usage on Fedora.
Learn more about the Server team.
The Fedora Infrastructure team kicked off the F45 mass rebuild on July 15th, ensuring autosigning was enabled for the f45-rebuild tag. A significant portion of the week's effort was dedicated to migrating various infrastructure hosts and virthosts to RHEL10, which involved careful timing to minimize builder outages. On the mailing list, the team discussed the effectiveness of the Anubis anti-scraper system. Contributors concluded that Anubis remains absolutely critical for preventing infrastructure outages and managing CPU load, even if some modern AI agents can bypass its proof-of-work challenges.
Operational troubleshooting addressed several immediate issues, including a stalled Bodhi consumer pod that halted Rawhide and ELN updates, PR merge failures on node-exporter, and misrouted EPEL mirrors. The team is also actively improving monitoring by adjusting Zabbix checks and advancing the Forgejo deployment with new metrics templates and foundational work on private issues. Contributors looking to engage can assist with AWS IAM role configurations for projects like Testing Farm and Logdetective, or help refine Apache LoadBalancer timeouts to handle external proxy delays more gracefully.
f45-rebuild tag to support the ongoing mass rebuild.Learn more about the Infrastructure team.
The Fedora 45 Mass Rebuild was a central focus this week, with the tracker ticket coordinating readiness across toolchain updates and a meeting discussion clarifying the standard operating procedure for verifying driving changes before commencing. To improve future rebuilds, contributors are exploring ways to update the mass rebuild scripts so they automatically check Bodhi and skip packages that recently failed gating. In community tooling news, an experimental AI Agent was introduced to autonomously analyze Rawhide nightly compose logs and identify root causes of failures, offering a new way for contributors to help triage issues. Meanwhile, the migration to Forgejo continues, with the kiwi-description repository successfully moved and plans forming to replace Pagure AMQP messages with Forgejo webhooks.
Routine release engineering tasks included resolving git repository unpacker errors, setting up Koji tags for ELN image-builder, and processing side tags for the Perl 5.44 update.
git blame feature in Fedora Package Sources has been deliberately disabled to mitigate massive abuse from AI web crawlers; contributors must now clone repositories and use git blame locally..composeinfo format was updated to include a release_type field, enabling downstream Beaker automation to distinguish between Beta and Final releases.Learn more about the Release Engineering team.
The most significant development this week is the launch of on-demand openQA testing for dist-git pull requests. Contributors can now trigger automated tests by simply commenting /openqa test on a PR, with success or failure states reporting directly back to the interface. In other tooling updates, a compose critical package generation script was merged (with Bodhi integration ongoing), openQA test coverage was extended for KDE and Workstation applications, and UI/UX improvements were applied to the testdays-web platform to clarify when events are ready for result submissions. The "Heroes of Fedora Quality Q2" report was also published to celebrate community contributions.
For ongoing contributor engagement, the QA team is calling for community validation on several new nightly composes. Testers with available time are encouraged to review and submit results for Fedora 45 Rawhide 20260718.n.0, Fedora 45 Rawhide 20260715.n.0, and Fedora-IoT 45 RC 20260713.0.
Learn more about the Quality team.
The Design team is actively preparing for upcoming releases and events, including initial planning for the Fedora 46 wallpaper with community polls focusing on "U"-themed inspirational figures. Emma Kidney published a blog post detailing the new collaborative design workflow used for Flock 2026 branding. In other project updates, the team finalized the LoLa AI Package Manager mascot, resolved data issues to generate Flock 2026 YouTube thumbnails, and is working on migrating the fedora-logos repository from Pagure to the Design team's Forgejo space to streamline package updates.
For contributors looking to get involved, there are ongoing efforts to create a Contributor Onboarding Video Series, where the team is currently crowdsourcing opinions on background music. There are also open opportunities to design avatars for Fedora's Matrix bots, including Zodbot, Meetbot, Nonbot, and the new Moderation bot. Furthermore, the team is heavily refining a community onboarding poster to ensure it serves as excellent "rookie reading material" while remaining visually cohesive, accessible, and cost-effective for community members to print.
Learn more about the Design team.
The Fedora Docs team is finalizing its migration away from Pagure.io ahead of the platform's July 31 shutdown, urging maintainers to move remaining repositories to Forgejo (Issue #35). Infrastructure and workflow improvements are a major focus this week, with ongoing work to refactor the local docsbuilder.sh preview script to use updated, secure containers (Issue #19) and efforts to implement automated Forgejo Actions CI monitoring to catch silent production site build failures (Issue #53). Additionally, the team is exploring a massive UI/UX overhaul to better support knowledgebase-style content in the Antora theme, and community brainstorming is highly encouraged even for those not ready to write code (Issue #51).
To decentralize documentation maintenance, the team is launching the "Fedora Docs Captain" pilot program (Issue #50). This initiative pairs subject-matter experts with experienced technical writers to revamp documentation for the Kernel, Multimedia, and AI/ML SIGs. Volunteers are actively needed to serve as sponsors or team leads for these pods. In a related effort, a community initiative is underway to consolidate scattered multimedia, hardware driver, and third-party codec documentation into a single authoritative source to improve the new user experience (Issue #58).
docs/* repositories will soon be updated to enforce new contribution guidelines, requiring contributors to submit pull requests via forks rather than pushing directly to repository branches (Issue #46).Learn more about the Docs team.
This week, the EPEL team focused on package updates, security retirements, and early planning for EPEL 11. Notably, syncthing has been retired from EPEL 8 and 9 due to unfixable security vulnerabilities and SQLite incompatibilities; users are advised to upgrade to RHEL 10 to continue using it. Concurrently, updates for syncthing v2 were pushed to stable for EPEL 10.2 and 10.3. During the weekly meeting, the steering committee also approved incompatible updates for rust-routinator and ffmpeg, with the ffmpeg update planned to land in epel9-next first to allow maintainers time for necessary adjustments.
Looking ahead, early planning discussions for EPEL 11 have begun. A key topic of discussion is addressing feedback from enterprise users who mirror repositories directly by URL (such as with Satellite or Foreman) and were disrupted by recent changes to metalinks and baseurls. A proposal is currently being drafted to remediate this URL structure in EPEL 11—and potentially implement it smoothly in EPEL 10 as well—to ensure a more predictable experience for users.
rust-routinator (Issue #369).ffmpeg 5 to 7, which will be introduced in epel9-next first (Issue #370).Learn more about the EPEL team.
In the ELN meeting, the primary discussion focused on the delayed enablement of bootc images for Fedora ELN. Progress has been slow due to review bottlenecks on the Konflux side, prompting suggestions to move all ELN container builds into Konflux. By standardizing the pipeline and removing bootc as a special case, the group hopes to resolve structural build issues and improve the overall RHEL-on-Konflux experience.
The team also clarified the roadmap for future bootc images, noting that the Fedora ELN bootc image (to be hosted at quay.io/fedora/eln-bootc) will serve as a precursor to upcoming CentOS Stream 11 builds. Because CentOS Stream 11 is still in early bootstrap, contributors agreed to schedule a dedicated conference call to coordinate the integration of Konflux, pungi, and bootc configurations across both the Fedora and CentOS Stream ecosystems.
Learn more about the ELN team.
During the Fedora Atomic Initiative meeting, progress was shared regarding Enterprise Linux Next (ELN) base images. Contributors are currently waiting on reviews for Konflux tenant configuration merge requests that will switch the setup from minimal-plus to standard, which is required to complete the ELN base image builds. Once merged, the team will need to determine the process for pushing the resulting base image to the correct namespace, presenting an area where contributors familiar with Konflux might be able to assist.
In broader news relevant to the Linux community and bootc users, an initiative is underway to split Ignition into a standalone RPM, allowing it to be included in more workflows such as bootc container image builds. Additionally, a Fedora 45 change proposal was highlighted that aims to provide native Butane configuration support directly in Ignition. If implemented, this will eliminate the need for the intermediate Butane-to-Ignition conversion step, allowing users to use Butane directly for their instances.
Learn more about the Atomic team.
During the CoreOS meeting, the team reviewed the Fedora 45 Release Schedule and warned that the ongoing Mass Rebuild may cause temporary turbulence and CI breakages in the rawhide stream. The change proposal to enable systemd-oomd and swap on Zram by default was finalized and moved forward in the release process. In other community news, contributors are seeking reviews on an Afterburn pull request designed to make logic less Azure-specific, and members discussed strategies for better surfacing bugs caught in the next stream before they reach stable releases.
A significant portion of the meeting focused on the ongoing need to increase the /boot partition size for new installs, an issue recently highlighted by failing tests on aarch64 rawhide. Acknowledging the complexity of this migration, several contributors volunteered to form a dedicated working group to address it, offering an excellent engagement opportunity for those interested in helping architect a solution for core system storage limits.
/boot partition size limits, with an initial action item to draft a comprehensive list of requirements for the migration effort.Learn more about the CoreOS team.
This week, a user reported an issue with the Rawhide nodebug kernels setup process. The repository configuration file required to set up the repo on new systems is currently missing from the server, causing the standard wiki instructions to fail.
While the .repo file is missing, the actual repositories are still present and intact on the server. This presents a quick engagement opportunity for infrastructure or kernel contributors to restore the missing file and fix the setup process for the broader community relying on these nodebug kernels.
Learn more about the Kernel team.
The AI & ML SIG is making strides in integrating AI into Fedora workflows, highlighted by a new proof-of-concept AI agent analyzing Rawhide nightly composes to identify failure root causes. To support these efforts, the SIG is formalizing an AI skills library and has established a new "Skills Reviewers" sub-team to curate shared, agent-neutral AI skills. On the hardware front, the SIG is addressing the growing interest in shared GPU infrastructure by initiating a draft for an Acceptable Use Policy to define trust models and access controls for Fedora's GPU hardware.
There are several immediate opportunities for contributors to get involved. The SIG is actively seeking maintainers for new llama.cpp backends (with a priority on Vulkan) and testers for the newly introduced pi-coding-agent in Rawhide, particularly on non-x86 architectures like aarch64. Additionally, developers interested in LLMs are encouraged to help expand the AI Skills Library or integrate other local LLMs into the existing coding agents.
skills-reviewers sub-team on Forgejo. Seeded with six initial members, the team will manage the ai-ml/skills-library repository and implement a lightweight review process requiring at least one approval before merging new Agent Skills. (Ticket #31)gpu01) will be strictly earmarked for CI purposes during the F45 release cycle. General access requests will be temporarily closed as wontfix while the hardware remains in a "transitionary/exploration" phase and the formal Acceptable Use Policy is drafted. (Ticket #34)Learn more about the AI & ML team.
The Fedora 45 rebuild for RISC-V is currently about 25% complete, and the team continues to make steady progress resolving remaining issues on the Fedora RISC-V tracker. Hardware capacity has expanded, with four RVA23 units—including community-contributed hardware—now active in the Fedora RISC-V Koji. Furthermore, technical discussions are actively underway with hardware vendor SpacemiT's Linux team to improve virtualization support and resolve known issues.
For those looking to get involved with the group, requirements for a potential RISC-V intern have been drafted and published, offering a new engagement opportunity for prospective contributors.
Learn more about the RISC-V team.
The Security SIG held a meeting this week primarily focusing on secure development practices and how end-users can verify Fedora's security posture. The group highlighted existing safeguards like the package review process and mandatory hardening compiler flags, while also discussing the integration of automated vulnerability management tools. Notably, the conversation covered the new ProdSec scanner (Trustshell) and Hummingbird, a tool that uses AI to scan for CVEs and automatically generate pull requests for Rawhide packages. The team also explored the potential of mapping Fedora's practices against the OpenSSF baseline checklist.
Contributors looking to get involved can review the meeting agenda and logs on the forum. Several topics were deferred due to time constraints, providing an excellent opportunity for asynchronous engagement on the SIG's issue tracker, particularly regarding the Cyber Resilience Act (CRA) requirements and Linux-distros mailing list policies.
Learn more about the Security team.
David Campbell announced the release of Hnefatafl Copenhagen 6.1.1, a strategic board game with historical roots similar to Chess or Go. Linux gamers interested in trying it out can install the game by enabling the dcampbell24/hnefatafl-copenhagen Copr repository. Once installed, it can be launched directly from the application menu or by running hnefatafl-client in the terminal.
Learn more about the Gaming team.
In a recent discussion, Tadej Janež sought advice on packaging docker-credential-helpers for Fedora. Because the upstream project includes macOS and Windows-specific helpers (osxkeychain and wincred), the conversation focused on excluding these unnecessary modules and their dependencies from the vendor tarball using go2rpm. Mikel Olasagasti provided a solution to remove the directories prior to archiving, which successfully cleared out the unneeded dependencies.
This process resulted in an essentially empty vendor archive, prompting Tadej to ask follow-up questions about handling SPEC file macros that operate on empty vendor sources and resolving an rpmlint error caused by a zero-length modules.txt file. Contributors with Go packaging experience are encouraged to join the thread to help resolve these final packaging hurdles.
pre_commands and exclude_directories in the go-vendor-tools.toml configuration to explicitly remove the OS X and Windows credential helpers (osxkeychain/ and wincred/) from the vendor archive and licensing checks.Learn more about the Go team.
This week, the Perl group focused heavily on routine package maintenance and version updates. Michal Josef Špaček successfully merged multiple version bumps, updating perl-Test-Inter to 1.13 across PR #9, PR #10, and PR #11, as well as updating perl-HTTP-Date to 6.08 in PR #5, PR #6, and PR #7. In broader Linux community news, Michal Schorm submitted a patch to fix a Failure to Build From Source (FTBFS) in perl-SDL caused by underlying code behavior changes, which was subsequently merged by Hans de Goede. Additionally, contributors looking to engage with RHEL compatibility can review Yaakov Selkowitz's newly opened pull request for perl-HTTP-Daemon to build the package using Module::Build on RHEL.
The group approved and merged the FTBFS fix for perl-SDL. They also officially accepted the version bumps for perl-Test-Inter (1.13) and perl-HTTP-Date (6.08) across their respective repository branches.
Learn more about the Perl team.
llama.cpp backend, testing pi-coding-agent, establishing a Skills Reviewers sub-team, and navigating the governance of GPU hardware access for CI purposes.matrix-synapse on Fedora 44 and older, noting that an ongoing package review is currently blocking progress.ledger package, but the maintainer quickly replied, apologizing for their absence and promising to catch up on their packages.xset and xrdb packages, inviting anyone who still has a use for them to take over maintenance.wavemon package (version 0.9.7) for Fedora 44, offering occasional future builds without committing to long-term maintenance.z3 version 5.0, which will require rebuilding opam and prusa-slicer.nodejs22 stream in F44/Rawhide as the project transitions to a metapackage approach.flint version 3.6.0, which includes a soname bump requiring rebuilds for several dependent packages like Singular and polymake.libupnp to 22.0.3 in Rawhide, confirming that dependent rebuilds will be handled.
A expedição mal tinha começado e eu já recebia um baque inesperado e surpreendente numa pequena volta guiada em Longyearbyen, entre o vôo de chegada e o embarque no navio. O guia citou o Banco Mundial de Sementes de Svalbard como a coisa mais normal do mundo. Como se ter a ideia e executar o plano de criar uma espécie de Arca de Noé da genética vegetal planetária fosse tão banal e desimportante quanto fazer o chá da tarde.
Que iniciativa absolutamente genial, importante, estratégica, vital! E claro que depois devorei referências e informações sobre isso.
Concebido, construído e mantido pela Noruega (outro financiador citado é a Fundação Bill & Melinda Gates), trata-se de um enorme armazém escavado 130 metros dentro da rocha. Svalbard foi escolhido como local por não ter atividade sísmica e por ter permafrost (gelo constante) que ajuda a preservar as sementes a -18℃. Mesmo que os sistemas de refrigeração falharem, o permafrost garante que a temperatura do armazém subirá a 0℃ somente após uns 200 anos.
A Noruega não cobra, é gratuito países depositarem sementes no armazém. O objetivo é preservar a biodiversidade agrícola e de plantas do planeta.
Guerras, conflitos, mudanças climáticas e outros problemas podem causar perda de biodiversidade e indisponibilidade de sementes para replantar uma espécie vital para a humanidade. E de fato, em 2015, a 
Syria precisou recuperar do armazém de Svalbard algumas sementes. Essa foi a primeira vez que tal emergência aconteceu. E esperamos que nunca mais se repita.
Embarcamos numa expedição ao Polo Norte centrada em Svalbard, arquipélago da 
Noruega que fica dentro do Círculo Polar Ártico (latitude 67°). Organizada pela Latitudes Viagens de Conhecimento, voamos de Oslo à pitoresca Longyerbyen e lá embarcamos no navio Sylvia Earle para circundar e atracar em diversos pontos do arquipélago.
Santuário protegido, impressionantes glaciares, pássaros, baleias, morsas, raposas e ursos polares, proporcionaram perspectivas inéditas e emocionantes para vivenciarmos nosso Planeta. Como se não bastasse, nos acompanharam guias que eram historiadoras, geólogos, biólogas, antropólogas e até filósofos que ampliavam o significado de absolutamente tudo o que vimos. Não era só ver glaciar; era ver glaciar com a História geológica do lugar e a profunda transformação que sofreu nas últimas décadas com o aquecimento global, e como isso afeta toda a Terra. Não era só ver urso polar ou baleia; era isso junto com a História da caça às baleias, geopolítica e como elas foram salvas pelo descobrimento do petróleo. Enfim.
Cada saída exploratória tinha uma surpresa ou algo inesperado, ou curiosidade de cair o queixo, ou simplesmente a emoção avassaladora de estar em frente a um glaciar de 200km de borda por 55m de altura (Austfonna).
Daqui para frente farei algumas publicações de fotos que são só ilustrativas para o relato do que aprendi e me impressionou, que segue nos respectivos textos. São informações novas e valiosas para mim, que preciso registrar.