fidzu : Fedora

02 Jul 2026 2:23am GMT

Mais um nome de lugar que, em português, falamos errado porque herdamos uma grafia estrangeira.

Kristiania era o nome desta cidade de 1624 a 1925 porque o rei dinamarquês Cristiano IV queria se auto-homenagear quando a reconstruiu após um grande incêndio. 20 anos após a Noruega conquistar sua independência da Suécia, o parlamento decidiu voltar ao seu gracioso, simples, elegante e também imponente nome original medieval.

A forma sonora como os noruegueses chamam sua capital é:

ÚSSLU

Alguns sotaques regionais também falam:

ÚSHLU

Contaram-me também que em certas rodas mais "frescas" se fala também:

ÚSSLO

Então, na mesma forma que achamos estranho quando estrangeiros falam, erradamente, "braçill" ao invés de "brazil", também deveria ser considerado estranho quando falamos "ózlo".

01 Jul 2026 11:29am GMT

30 Jun 2026 8:00am GMT

30 Jun 2026 12:00am GMT

My Halfway Journey as an AI/ML Engineering Outreachy intern at the Fedora Project: building toward a tool for 30 years of RPM Packaging guidelines

From May 18, 2026, to the present, I have been deep-diving into the Fedora Project as an Outreachy and Software Freedom Conservancy intern, working on an AI/ML project that will ultimately help Fedora's RPM packagers navigate the 30-year history of RPM packaging guidelines.

Fedora is now a community that I call family, and every Fedoran I have encountered has been incredibly helpful and supportive in ways I can hardly put into words. From my esteemed mentors, Carol Chen, Dominik Kawka, and Justin Wheeler (one of the Fedora Project maintainers), to the members of the AI/ML Special Interest Group and the Fedora Infrastructure Team, and everyone else I have had the chance to learn from since the beginning of my internship, I have loved every moment of it and intend to be a lifelong contributor to the Fedora Project.

So what have I done and contributed so far?

Even before the internship officially began, I had the chance to interact with and get support from my mentors as part of my preparation. During this time, I continued deepening my knowledge of RamaLama and RamaLama RAG that I had started building during the contribution phase. In doing so, I explored and documented the document-processing and retrieval-pipeline architecture, converting both single PDF files and entire directories of PDF files, and tested custom GPU and graphics accelerators to get everything running.

I also explored running OpenAI's GPT-OSS with RamaLama. In parallel, I got started with RPM packaging by familiarizing myself with the RPM package management system and even simulating my own implementation of RPM-based systems. With my mentors' support, I successfully ran and tested the RamaLama Sandbox-Goose, tinkering with several examples and building and deploying agentic AI systems with it for my own projects. If you would like to learn more about this preparatory work, you can find it here: https://github.com/gtfrans2re/fedora-summer-ml-prep-2026

As for my contributions since the internship began, I really cannot take the credit alone; this work is made possible by mentors who pour a great deal of effort and time into creating and following up on the issues I work on.

Here are the issues I have been working on as part of my contributions so far:

• [Gonothi] Identify and scope a RAG mini-project candidate (#145): Together with my mentors, we proposed and scoped a small-scale RAG mini-project using RamaLama to test retrieval workflows before tackling the full Fedora RPM Packaging Guidelines. The outcome was a selected, well-scoped mini-project candidate that let me begin RAG pipeline testing with RamaLama in Sprint 6.
• [Gonothi]: RAG Mini-Project - enhance a model with Fedora Magazine Blog Article Guidelines (#146): This issue involved enhancing a model using RamaLama RAG on the Fedora Magazine and Community Blog writing guidelines and past published articles, to help reviewers evaluate draft submissions. The result is a working RAG prototype that validates the pipeline before tackling the full RPM documentation.
• [Gonothi]: Welcome and onboarding (#148): I completed onboarding tasks and connected with key people across Fedora, which helped me get to know the project and community and strengthened the foundation for my Outreachy work.
• [Gonothi]: RAG Mini-Project - explore deploying on Quay.io (#149): For the OCI images created via the RamaLama RAG pipeline in #146, I made them publicly available on Quay.io (https://quay.io/user/gtfrans2re/) for distribution, ensuring the RAG images are accessible to other users.
• [Gonothi] Familiarize more with AI/ML SIG, and Packaging process (#150): This ongoing issue (due July 6, 2026) is helping me get better acquainted with the teams and processes that will support the main internship project.
• [Gonothi] Identify 3-5 relevant A-level scientific conferences or journals (#151): Under my mentors' guidance, I scouted potential conferences and journals where the final work from this internship could be published or presented. The outcome was a shortlist of suitable venues.
• [Gonothi] Evaluating RAG systems and other tools (#154): This issue had me explore tools that help with RAG evaluation, model selection, CPU/GPU usage profiling, and scaling ML workloads, to understand each tool's value and integrate those that can benefit my project.
• [Gonothi] Request to join the fi-apprentice group (#13393): On my mentors' recommendation, I requested membership in the fi-apprentice group to gain read-only access to Fedora infrastructure machines, so I can learn the setup and find areas to contribute. Joining as an apprentice is an interim step to familiarize myself with the infrastructure (including bastion access) while dedicated GPU/server resources are being provisioned for the project.

Highlights of what I have learned from other interns, my mentors, and my community:

So far, I have connected with several other interns over the Outreachy Zulip chat platform and with some of them on LinkedIn. It is always great to read about their experiences during the monthly Outreachy chats, and over the past two chats, I have been genuinely inspired by their journeys and portfolios.

As for my mentors, from day one, they made me feel as though we had known each other for years. They are kind, open-minded, and incredibly generous in sharing learning resources to help me prepare for the work ahead. I have learned to use Replicate API tokens to run AI models from Google Colab and from Python. Carol Chen even generously shared an API token with me so I could test this out. My mentors also pointed me to resources for exploring and testing open-source LLMs for building and deploying AI and agentic AI systems locally and showed me how to use RamaLama Sandbox-Goose to ship an AI agent locally before deployment. They introduced me to tools like llmfit for fitting models on a local machine with efficient CPU and GPU memory management. And, as they suggested, I worked through several RPM packaging examples to understand the overall process and how AI and ML might help speed it up.

One thing my mentors did that meant a great deal to me was helping me find the resources to join the Linux meetup community in Montréal and Québec, a network of Linux and open-source users in my region, so I could attend meetups and keep learning alongside like-minded people. This also led me to the Red Hatters in Canada group, through which I was invited to Red Hat Tech Day in Montréal on June 11, where I got to learn about and use Red Hat AI and Red Hat OpenShift AI to build and secure AI and agentic AI systems in Red Hat Enterprise Linux cloud environments.

As for the wider community, I have joined and am getting acquainted with the Fedora AI/ML Special Interest Group (SIG), where I interact with group members, as well as the Fedora Infrastructure Team through the fi-apprentice program. I will also be attending Flock to Fedora, Fedora's annual contributor conference, held this year, June 14-16, in Prague, virtually, to meet more Fedorans and learn about the technology we all build on. Beyond that, I have connected with many Fedorans to learn more about what they do, including Aoife Moloney from the Fedora Operations Architect team, Jona Azizaj from the Fedora EDIA team, and Madeline Peck from the Fedora Design Team.

What I am most proud of building so far:

The contribution I am most proud of is the mini-project at the heart of my work so far: an AI-powered editorial assistant for the Fedora Community Blog and Fedora Magazine, built with RamaLama RAG. It is a deliberately smaller, well-scoped problem chosen as the foundation for the larger RPM Packaging Guidelines project to come, a way to prove out the entire RAG pipeline end-to-end on a manageable corpus before tackling 30 years of packaging documentation.

The tool helps new authors and reviewers check whether a draft article meets Fedora's editorial standards before submission. It flags missing required elements, such as a featured image or the "Read More" tag, and checks tone, structure, technical accuracy, and topic scope against the publications' own writing guidelines and past published articles.

Building it taught me how the whole pipeline fits together in practice:

• Preparing the data: I fetch articles from both publications via the WordPress REST API and let RamaLama RAG ingest the HTML directly. A key lesson from my mentors here was that RamaLama already uses Docling internally to convert documents into a structure-aware representation optimized for retrieval, so feeding it the original HTML preserves more meaning than pre-flattening everything to plain text or Markdown.
• Building the vector stores: Using the ramalama rag command, I build OCI images for the Community Blog, the Magazine, and a combined corpus, and publish them on Quay.io so others can pull and run the tool without rebuilding anything from scratch.
• Choosing and testing models: I benchmarked several open-weight models and, with my mentors' input, narrowed the local lineup to the newer, more efficient Gemma 4 and Granite 4, a reminder that on constrained hardware, model generation and efficiency matter as much as raw size.
• Making it usable: I built a Streamlit interface where an author can paste a draft and get instant editorial feedback, and I documented a full local development guide plus a quickstart so anyone can run the tool on their own machine.

What I am proudest of is not any single component but the fact that it works as a complete, reproducible, fully open-source pipeline (Apache 2.0) running entirely on local, open-weight tooling, no proprietary services required. You can find the project here:https://forge.fedoraproject.org/ai-ml/editorial-guide-ramalama

I presented this tool to Michal Konečný from the Community Blog editorial team and pitched it to the Fedora Magazine editors, and the encouraging early feedback has been one of the most rewarding parts of the internship so far.

Adjustments to scope, timeline, and tasks:

The overall arc of the internship remains the same: the mini-project is the proving ground for the main project on the Fedora RPM Packaging Guidelines. A few refinements have happened along the way, all of them improvements rather than changes of direction.

On scope, we expanded the mini-project from the Community Blog alone to include Fedora Magazine, since the pipeline generalized well to both. On the technical side, guided by my mentors, I removed a redundant manual ingestion step once we confirmed that RamaLama already handles document conversion and chunking internally, and I narrowed the model lineup to Gemma 4 and Granite 4 for efficiency on local hardware. The one external constraint has been computed: running the heavier models locally pushes my current machine to its limits, and dedicated GPU/server resources are being provisioned to unblock that, which is also why I am getting acquainted with Fedora's infrastructure through the apprentice program in the meantime.

As I move into the second half of the internship, the focus shifts toward applying everything I have learned from this mini-project to the much larger and more ambitious main project: building a RAG-powered tool for three decades of Fedora RPM packaging guidelines. I could not be more excited for what is ahead.

Regards,
Gonothi

29 Jun 2026 8:08pm GMT

Hello travelers!

Loadouts for Genshin Impact v0.1.17 is OUT NOW with the addition of support for recently released artifacts like Celestial Gift and Disenchantment in Deep Shadow, recently released characters like Nicole, Lohen and Prune and for recently released weapons like Angelos' Heptades and Disaster and Remorse from Genshin Impact Luna VII or v6.6 Phase 2. Take this FREE and OPEN SOURCE application for a spin using the links below to manage the custom equipment of artifacts and weapons for the playable characters.

Resources

• Loadouts for Genshin Impact - GitHub
• Loadouts for Genshin Impact - PyPI
• Loadouts for Genshin Impact v0.1.17
  • Executable for GNU/Linux distributions
  • Executable for Microsoft Windows

Installation

Besides its availability as a repository package on PyPI and as an archived binary on PyInstaller, Loadouts for Genshin Impact is now available as an installable package on Fedora Linux. Travelers using Fedora Linux 42 and above can install the package on their operating system by executing the following command.

$ sudo dnf install gi-loadouts --assumeyes --setopt=install_weak_deps=False

Changelog

• Replace native compilation with integrated building by @gridhead in #544
• Automated dependency updates for GI Loadouts by @renovate[bot] in #545
• Automated dependency updates for GI Loadouts by @renovate[bot] in #547
• Remove unused class variable by @sdglitched in #550
• Fix incorrect type hint for refi_stat by @sdglitched in #551
• Update dependency nuitka to >=2.0.0,<5.0.0 by @renovate[bot] in #552
• Trigger test workflow on pull_request by @sdglitched in #559
• Add the recently added artifact set Celestial Gift to the GI Loadouts roster by @sdglitched in #557
• Add the recently added character Prune to the GI Loadouts roster by @sdglitched in #556
• Automated dependency updates for GI Loadouts by @renovate[bot] in #553
• Introduce the recently added weapon Angelos' Heptades by @gridhead in #560
• Automated dependency updates for GI Loadouts by @renovate[bot] in #563
• Introduce the recently added character Nicole to the roster by @Ank-22 in #565
• Introduce the recently added artifacts Disenchantment in Deep Shadow by @gridhead in #561
• Introduce the recently added character Lohen to the roster by @gridhead in #562
• Introduce the recently added weapon Disaster and Remorse by @Ank-22 in #568
• Update actions/checkout action to v7 by @renovate[bot] in #567
• Stage the release v0.1.17 for Genshin Impact Luna VII (v6.6 Phase 2) by @sdglitched in #574

Artifacts

Two artifacts have debuted in this version release.

Celestial Gift

• Bonus for Two Piece Equipment
  Energy Recharge + 20%.
• Bonus for Four Piece Equipment
  If the equipping character has completed Witch's Homework, after they use an Elemental Skill, they also gain "Light's Guidance" for 20s: All nearby party members gain a 20% Elemental DMG Bonus corresponding to the equipping character's Elemental Type. The equipping character can trigger this effect while off-field. DMG Bonuses provided by Artifact Sets with the same name do not stack.
  When your party has the Hexerei: Secret Rite effect, Light's Guidance is upgraded to "Mortal Hymn": All nearby party members gain a 40% Elemental DMG Bonus corresponding to both the equipping character and the current active party member's Elemental Type instead. If both characters have the same Elemental Type, these bonuses will not stack.

Disenchantment in Deep Shadow

• Bonus for Two Piece Equipment
  ATK +18%.
• Bonus for Four Piece Equipment
  Increases Superconduct Reaction DMG by 80%. When the wielder attacks opponents affected by Superconduct, this attack's CRIT Rate is increased by 16%. An all-new blessing may be obtained as you make your way toward Snezhnaya...

Characters

Three characters have debuted in this version release.

Nicole

Nicole is a catalyst-wielding Pyro character of five-star quality.

Lohen

Lohen is a polearm-wielding Cryo character of five-star quality.

Prune

Prune is a catalyst-wielding Anemo character of five-star quality.

Weapons added

Two weapons have debuted in this version release.

Angelos' Heptades

Crown of the Final Scion - Scales on ATK %.

Disaster and Remorse

Dolorous Stroke - Scales on Crit Rate.

Appeal

While allowing you to experiment with various builds and share them for later, Loadouts for Genshin Impact lets you take calculated risks by showing you the potential of your characters with certain artifacts and weapons equipped that you might not even own. Loadouts for Genshin Impact has been and always will be a free and open source software project, and we are committed to delivering a quality experience with every release we make.

Disclaimer

With an extensive suite of over 1580 diverse functionality tests and impeccable 100% source code coverage, we proudly invite auditors and analysts from MiHoYo and other organizations to review our free and open source codebase. This thorough transparency underscores our unwavering commitment to maintaining the fairness and integrity of the game.

The users of this ecosystem application can have complete confidence that their accounts are safe from warnings, suspensions or terminations when using this project. The ecosystem application ensures complete compliance with the terms of services and the regulations regarding third-party software established by MiHoYo for Genshin Impact.

All rights to Genshin Impact assets used in this project are reserved by miHoYo Ltd. and Cognosphere Pte., Ltd. Other properties belong to their respective owners.

29 Jun 2026 6:30pm GMT

This blog post is a sequel to Your _get_type() function is not G_GNUC_CONST.

GNOME developers have long used G_GNUC_CONST, which expands to __attribute__((const)), to annotate GObject _get_type() functions, despite knowing that it is incorrect to do so. const functions by definition have no side effects, but _get_type() functions actually have a side effect the first time the function is called: they initialize the type. Why apply an incorrect annotation to these functions? Because it makes the code faster.

Although this was long known to be incorrect, it worked fine in practice… until now. Regrettably, Sam James has discovered that GCC 16 may optimize away the type initialization, resulting in crashes. This is our fault for providing the compiler with wrong information about our code, so it's time to audit your use of const attributes to remove them from _get_type() functions. Most GNOME programs use these attributes only for _get_type() functions, but if you use it in more places, then check to make sure those functions are actually const, as defined by the GCC documentation.

Sadly, there is no suitable replacement attribute for _get_type() functions. Two decades ago, Behdad requested a new idempotent attribute for expressing the desired semantics, but nobody has implemented it.

29 Jun 2026 3:32pm GMT

Across the Fedora project, teams are heavily focused on preparing for the upcoming Fedora 45 release, with groups including Quality, Workstation, Server, Cloud, and CoreOS actively coordinating system-wide changes, mass rebuilds, and issuing calls for F45 Test Day proposals. Simultaneously, a massive infrastructure transition is underway as Infrastructure, Release Engineering, Mindshare, and IoT urgently migrate repositories, issue trackers, and automated workflows from the sunsetting Pagure platform to the new Fedora Forge (Forgejo). Security and policy enforcement also dominate current efforts, highlighted by the newly enacted Two-Factor Authentication (2FA) mandate for provenpackager members, ongoing discussions around cryptographic library management, and extensive CVE patching within EPEL. Finally, improving the contributor experience remains a central priority, with the Docs and Design teams actively modernizing onboarding materials, while groups like Mindshare and Ambassadors recruit volunteers to support community engagement and upcoming global events.

Announcements

For Fedora contributors, there are several important infrastructure and policy updates to be aware of this week. FESCo now requires two-factor authentication for all provenpackager members, with a grace period extending to September 24, 2026, before non-compliant accounts are temporarily downgraded. Additionally, history has been rewritten for 71 package git repositories to fix long-standing git fsck issues; contributors with existing checkouts of these specific repos will need to perform fresh clones. A planned one-hour outage occurred on June 25th, temporarily affecting download-ib01, torrent, and fedorapeople services. In ecosystem news, discussions are ongoing regarding the future of Pagure.io and the transition to Forgejo, while Fedora Documentation translations are once again available following their successful migration to the new Fedora Forge. Finally, the F44 Election Results have been announced, officially seating new members for the Council, FESCo, Mindshare, and the EPEL Steering Committee.

In news relevant to the broader Linux community, Fedora has addressed the upcoming expiration of Microsoft's UEFI Secure Boot keys. Existing machines will continue to boot normally without panic, and Fedora Rawhide (f45) already includes a first-stage boot loader signed with multiple keys to ensure maximum compatibility moving forward. On the community front, Fedora was heavily represented at the XV P.I.W.O. Pozna&nacute; Free Software Fest in Poland, which saw record attendance and hosted the historical signing of the SPOIWO declaration-a new coalition advocating for digital sovereignty and open-source software in public institutions.

Council

The Council discussed the Draft Council Proposal for the Fedora Innovation Lifecycle, a framework designed to handle experimental, large-scale projects that are too complex for the standard ChangeProposal process. The proposed lifecycle introduces Sandbox, Curation, and Integration stages to help solve the "innovator's dilemma" by nurturing big ideas within the project boundary. While some participants questioned if existing tools like Copr and the current Changes Process could simply be improved, proponents argued that a dedicated Sandbox is necessary for massive, interlocking changes to prove their viability without being hindered by strict technical policies early on. This structured pathway aims to foster innovation and sustainable contributor engagement for strategic initiatives, such as the ongoing RISC-V architecture bring-up, which currently has to operate outside the project as a remix.

Learn more about the Council team.

FESCo

FESCo welcomed new members following the F44 elections and opened nominations for the Fedora Council Engineering Representative. A major security policy update was announced, requiring all provenpackager group members to enable Two-Factor Authentication (2FA) by September 24, 2026, with discussions underway to potentially expand this requirement to all packagers. Additionally, FESCo approved several system-wide changes for Fedora 45, including updates to RPM 6.1, Golang 1.27, Erlang 27, and the adoption of PURL Metadata. New F45 Change Proposals were also introduced for community feedback, such as a minimal GRUB EFI build for Confidential Computing and offering the Lazarus IDE with multiple widgetsets.

The committee is actively seeking input on managing binary executable content in node_modules and whether to drop the signoff requirement from the defunct Fedora crypto team for new cryptography libraries. Contributors are also invited to discuss the upcoming Forgejo distgit migration and a proposal to allow draft builds for ELN rebuild batches. To streamline issue tracking, FESCo is migrating its public issues to the new forge, archiving private issues, and temporarily opening its mailing list to non-subscribers for sensitive reports.

Decisions

• Two-factor authentication is now required for the provenpackager group, with a 3-month grace period before enforcement.
• FESCo public issues will be migrated to the new forge, while private issues will be archived in a separate repo. The FESCo mailing list will temporarily accept emails from non-subscribers for private reports.
• The Fedora Operations Architect was added as a sponsor for the "fesco" FAS group and as a mailing list admin.
• Approved F45 System-Wide Changes: Adopt PURL Metadata, Erlang 27, RPM 6.1, Golang 1.27, and Versioned libgit2 packages.
• Added containerd, moby-engine, rootlesskit, and docker-distribution to the Update Policy Exception List.

Learn more about the FESCo team.

Packaging Committee

During the Packaging Committee meeting, members addressed several guideline updates and packaging challenges. The committee reviewed FPC#1551 regarding versioned packages and agreed to remove the strict guideline stating they "MUST NOT conflict with all other versions," noting that general conflict guidelines are sufficient and development subpackages often unavoidably conflict. The group also discussed the ongoing issue of NodeJS packages shipping pre-built JavaScript blobs instead of building from source. While no immediate enforcement was enacted, the committee highlighted a strong need for improved NodeJS packaging tooling-presenting an excellent opportunity for contributor engagement-and suggested a potential future flag date to enforce compliance.

Additionally, the committee discussed FPC#1546 concerning the use of non-Fedora distribution conditionals (such as SUSE or Azure Linux macros) in spec files. Rather than strictly banning or allowlisting specific macros, it was agreed that new, comprehensive multi-distro guidance will be drafted. This upcoming proposal will aim to support cross-distribution compatibility for ecosystems sharing Fedora's packaging roots without cluttering spec files or burdening Fedora maintainers.

Learn more about the Packaging Committee team.

Mindshare

During the June 23 CommOps meeting, the team prepared for the impending mid-July sunset of Pagure.io by coordinating the migration of Fedora Magazine and Community Blog repositories to Forgejo. To improve news accessibility for newcomers and the broader Linux community, the team explored alternatives to dense LLM-generated summaries and approved a proof-of-concept for a human-curated "This Week in Fedora" Matrix news bot, inspired by similar tools used by GNOME and Ansible (hebbot).

Planning has officially kicked off for the Virtual F45 Release Party, tentatively scheduled for October 30, 2026. The team is actively seeking volunteers to lead various work streams, including a lead "Wrangler," speaker coordination, and video production. Furthermore, there is a high-profile engagement opportunity open: CommOps is searching for a new representative to serve on the Fedora Mindshare Committee to help guide global outreach and event operations.

Learn more about the Mindshare team.

Ambassadors

The Ambassadors group is beginning preparations for All Things Open 2026 in Raleigh-Durham, North Carolina. A call for participation has been issued for Fedora Ambassadors planning to attend, offering an excellent engagement opportunity to help shape the project's official event presence. Contributors interested in collaborating, representing the project, or helping staff a potential joint Fedora and CentOS nonprofit booth are encouraged to reply to the forum thread as soon as possible so resources can be mobilized. Further coordination regarding the official booth plan is expected to take place after July 5th.

Learn more about the Ambassadors team.

Workstation / GNOME

A new EXT4 mount option called rralloc (round-robin allocator) was proposed and discussed this week. Designed as an optional, mount-time allocation policy that leaves the on-disk format unchanged, it aims to reduce allocator contention and improve tail latencies for high-concurrency workloads on modern SSD and NVMe storage. The developer is currently seeking feedback and identifying potential use cases to gauge community interest and justify its broader adoption.

In preparation for the upcoming release, the Quality team has issued a call for Fedora 45 Test Days. Contributors are encouraged to review the accepted Fedora 45 changes and propose focused testing events for specific features by filing a ticket on Fedora Forge.

Learn more about the Workstation / GNOME team.

KDE

In recent discussions, it was noted that KDE Gear 26.04 was initially blocked on Fedora 43 due to a gpgme dependency update (requiring version 2.0+) that conflicted with Fedora's soname bump policy. Thanks to upstream commits lowering the requirement to version 1.24.2, this hurdle was cleared. KDE Gear 26.04 will now be pushed to Fedora 43 alongside Plasma 6.7.1, and the update is currently available in Bodhi for community testing.

Looking ahead to the next release cycle, the Fedora QA team has announced a Call for Fedora 45 Test Days. Contributors are highly encouraged to review the accepted F45 ChangeSet and propose specific testing events by filing a ticket on Fedora Forge. This is a prime opportunity for community members to help organize and lead focused testing for new features or critical distribution areas.

Learn more about the KDE team.

Server

The Server Working Group discussed several updates to the distribution and its documentation during their weekly meeting (also summarized on the mailing list). To better support users in regions with fragile or slow internet connections, the group agreed to re-include PPP and xDSL connection support packages in the base distribution media. Additionally, a call for Fedora 45 Test Days was announced across the forum and mailing list, inviting contributors to propose and host testing events for upcoming features.

On the documentation front, the team approved plans to create comprehensive OpenSSH guides and assigned action items to clean up existing NFS installation instructions. To improve security practices and consistency, all Server documentation will be updated to align with the Fedora Docs Style Guide, specifically transitioning command-line examples to use sudo [command] rather than root shells. Contributors interested in helping with these documentation updates or ongoing PXE boot and Kickstart configurations are encouraged to engage with the team.

Learn more about the Server team.

Infrastructure

The Infrastructure team managed several significant server moves and reinstalls this week, including relocating 11 OpenQA, Copr, and OpenShift worker nodes to optimize datacenter power usage, and reinstalling the download-ib01 host with RHEL 10. A major topic of discussion across meetings and the forum was the ongoing migration from the sunsetting Pagure platform to Fedora Forge. The team is actively exploring solutions for handling private security tickets on Forgejo, considering alternative workflows like private Discourse categories, while also assisting teams in archiving their old Pagure repositories. Additionally, a recent RabbitMQ certificate refresh surfaced a bug in the fedora-messaging library where it only read the first CA certificate in a combined file, which was promptly fixed and released.

In community-facing services, a forum discussion highlighted a growing need for shared, open LLM inference hosting within Fedora infrastructure to support tools like Log Detective and meeting summarization bots. The team also addressed a backlog of s390x builds by provisioning an additional builder, resolved Rawhide mirror 404 errors, and granted a storage quota increase on fedorapeople.org to host Flock 2026 video recordings. Ongoing operational work for contributors includes a major cleanup of legacy Nagios and collectd monitoring in favor of Zabbix, and migrating OpenShift applications to standardized Ansible roles.

Decisions

• To mitigate staging connection failures, the team decided to temporarily restore the old RabbitMQ server certificates until the patched fedora-messaging library is widely adopted.
• The team decided to provision an additional s390x builder to alleviate a severe backlog of long-running package builds.

Learn more about the Infrastructure team.

Release Engineering

During the Release Engineering meeting, the team prioritized the scm-requests migration ahead of the upcoming Pagure decommission. This involves updating fedpkg to file tickets in Forgejo and determining the safest backend method for processing those requests. The team also prepared for the upcoming mass rebuild cycle, the rollout of F47 keys, and finalizing the Fedora 42 End of Life process. Over on the forum, a community member shared their configuration and a brief guide on building a customized Fedora 44 XFCE live ISO using kiwi-ng.

Ticket activity this week centered heavily on package unretirements (kdevelop-python, rust-git-absorb, wavemon, pcl) and implementing a related fix for Koji owner synchronization to ensure unretired packages are properly assigned. The team also addressed Rawhide gating issues by untagging a problematic haveged build that was breaking FreeIPA upgrade tests, and reviewed upcoming Fedora 45 system-wide changes regarding Stratis storage in Anaconda and disabling DNF5 vendor changes by default.

Decisions

• For the scm-requests migration, the team decided to update the existing toddlers code to process Forgejo tickets rather than switching to Forgejo Actions. This was chosen to avoid the security risks of storing highly privileged distgit admin tokens in Action secrets.
• Patrik will take the lead responsibility for managing the upcoming mass rebuild cycle.

Learn more about the Release Engineering team.

Quality

During their weekly meeting, the Quality team reviewed their recent Flock and DevConf attendance, highlighting productive discussions on openQA failure analysis, Fedora CI improvements, and the ongoing effort to move testing to dist-git PRs. On the technical front, the massive OpenSSL 4 update landed in Rawhide; while it initially broke FreeIPA replication tests and gated all updates, these failures were temporarily bypassed to allow the merge. Additionally, Adam Williamson shared early work on a new system for tracking critical path packages to improve dependency gating, and the team noted that a Kernel 7.1 test week will be scheduled soon.

A Call for Fedora 45 Test Days has been officially issued, inviting the community to review the accepted ChangeSet and propose focused testing events via Fedora Forge. In other community news, volunteers have stepped up to help maintain the Packager Dashboard and Oraculum, though more contributors are always welcome to join the effort. Finally, nightly release validation testing is ongoing, with new composes nominated for Fedora 45 Rawhide and Fedora-IoT 45 RC.

Decisions

• Temporarily bypass FreeIPA replication test failures on Rawhide to allow the OpenSSL 4 update to merge.
• Disable the use of haveged in FreeIPA tests to resolve recent Rawhide update blocking issues.

Learn more about the Quality team.

Design

The Fedora Design team made significant progress on release artwork this week, officially completing and uploading the Fedora 45 Beta wallpaper. While the final wallpaper is expected in early July, the team is currently troubleshooting Inkscape export crashes related to high-resolution gradients. In event design, the Flock 2026 livestream splash screens were completed and closed, and a new ticket was opened to automate the creation of YouTube thumbnails for individual Flock talks.

There are excellent opportunities for contributor engagement, including a fun new request to design an avatar for the Fedora Matrix Moderation bot. Ongoing community projects also saw major updates: the team is finalizing a community onboarding flyer after implementing accessibility and design feedback, and the Contributor Onboarding Video Series is nearing completion after receiving official voiceovers from the Fedora Project podcast and undergoing final visual and audio tweaks.

Decisions

• The Fedora 45 Beta wallpaper will be used to internally test JXL packaging while the final version is completed.
• Based on viewer feedback, future Flock livestream templates will prioritize maximizing the screen size allocated for presented content (slides and workshops) to improve readability.
• The community onboarding flyer will drop the "technical vs. non-technical" grouping requirement to better accommodate the current design layout.

Learn more about the Design team.

Docs

This week, the Docs team focused heavily on modernizing the documentation ecosystem and improving the onboarding experience. Several mentored issues are open for newcomers to help update contribution guides, including shifting the focus to local authoring workflows, updating the Quick Docs contribution guide, and creating a beginner-friendly "Git for Writers" article. Broader restructuring efforts are also underway, such as planning a modern design for the Docs homepage, exploring UI/UX enhancements for knowledgebase-style pages, and piloting a new "Fedora Docs Captain" role to decentralize documentation leadership across various Fedora Working Groups and SIGs. In the forums, a community member shared a detailed guide on creating a custom Fedora 44 XFCE live ISO using KIWI-ng.

Behind the scenes, the team is actively cleaning up legacy infrastructure by deleting outdated docs pages from the Fedora Wiki and unprotecting specific wiki categories to facilitate change proposal management. Ongoing policy discussions include whether to enforce opening PRs exclusively from forks and the potential creation of a formal code style guide to ensure syntax consistency across repositories.

Decisions

• To address security vulnerabilities in the outdated docsbuilder.sh container image, the team decided to request a testing-farm runner on the Fedora Forge staging instance to test building new container images, with a long-term plan to transition to Konflux.

Learn more about the Docs team.

Internationalization

During the Internationalization meeting, the team reviewed the tracker for Fedora 45 changes, noting that the LibreOffice dictionaries change is planned for this week, while the fontconfig change is still in progress. Members were reminded to assist with Fedora 43 bug triaging and were briefed on upcoming proposal submission deadlines for Fedora 45 system-wide and infrastructure changes.

On the mailing list, a new contributor volunteered to assist with Norwegian Bokmål translations for core projects like systemd, Anaconda, and dnf. The team welcomed the contributor, confirmed that their manual review of AI-drafted translations complies with the Fedora AI-Assisted Contributions Policy, and requested a re-upload of recent systemd translations that were lost due to a Weblate merge conflict.

Learn more about the Internationalization team.

COPR

Following the end-of-life of Fedora 42 on May 27, 2026, the COPR team announced the disabling of all Fedora 42 chroots. Consequently, contributors can no longer submit new builds for fedora-42 architectures, including x86_64, i386, ppc64le, aarch64, and s390x.

To avoid disruptive surprises, project owners should note that existing Fedora 42 build results will be preserved for 180 days. After this grace period, they will be automatically removed unless contributors take explicit action to prolong the chroots' lifespan within their specific projects.

Learn more about the COPR team.

EPEL

During the EPEL meeting on 2026-06-24, the steering committee discussed several upcoming package transitions and security updates. Contributors are encouraged to review issue #368 regarding a proposed incompatible update or retirement for syncthing (v1.30 to v2) ahead of next week's vote. Additionally, significant work is underway to address CVEs in EPEL packages. The caddy package will be fast-forwarded in EPEL 10, may require an incompatible update in EPEL 9, and is facing potential retirement in EPEL 8 due to build complexities without go-vendor-tools. Furthermore, the KDE SIG has stepped in to help update qt6-qtwebengine in EPEL 9 to resolve a large number of outstanding CVEs, ensuring the package remains available for its active user base rather than being dropped.

Decisions

• Issue #367: The committee approved proceeding with the incompatible update of p7zip to 7zip for EPEL 9, provided appropriate announcements are made. Approval for EPEL 8 will be handled asynchronously once COPR build tests for EPEL 8-specific dependencies (conky-manager and retrace-server) are completed.

Learn more about the EPEL team.

ELN

During the ELN meeting, the team provided status updates on ELNBuildSync (EBS) and bootc integration. The migration of EBS to Fedora Infrastructure is 95% complete, with the Ansible playbook functioning in staging and the team currently awaiting OIDC secrets from Fedora Infra to finalize the deployment. To improve crash recovery, the team proposed a new approach to run EBS batches as Draft Builds right up until submission to Bodhi. This change is pending approval in FESCo issue #3621, and the corresponding pull request is already prepared.

Additionally, progress on bootc compose images is nearing completion. The work is ready to merge but is temporarily blocked waiting for preceding merge requests to land and for Konflux team members to return from PTO, though the bootc team is actively looking into unblocking the process.

Learn more about the ELN team.

Atomic

This week, discussions continued regarding the proposal to create a systemd-sysexts SIG. This proposed Special Interest Group aims to build and distribute systemd system-extensions based on Fedora content, providing a way to add extensibility to atomic systems for software that does not run well in containers or Flatpaks. The initiative continues to gather interested contributors to help design the distribution, discoverability, and official building processes.

In contributor engagement opportunities, the QA team has issued a call for Fedora 45 Test Days. With the Fedora 45 schedule progressing, community members are encouraged to review the accepted ChangeSet and propose features or distribution areas that would benefit from focused community testing. Contributors can propose and organize a test day by filing a ticket on the Fedora Forge.

Learn more about the Atomic team.

CoreOS

During the CoreOS meeting, the team focused heavily on upcoming Fedora 45 changes ahead of the proposal deadlines. Preparations are underway for the F45 pivot change request, the relocation of RPM repository configs to /usr, and upcoming proposals to introduce an oom-kill service and default zram for CoreOS. In the forums, a community member proposed a new EXT4 mount option called rralloc (round-robin allocator) designed to reduce allocation hotspotting and improve tail latencies for high-concurrency workloads. Additionally, interest continues to grow around the proposal to create a systemd-sysexts SIG.

There are several immediate opportunities for contributor engagement this week. The team is actively seeking code reviews and local testing for a major Ignition pivot PR and an Afterburn configuration logic PR. Furthermore, the QA team has issued a call for Fedora 45 Test Days, inviting community members to propose and organize testing events for upcoming features via Fedora Forge. Finally, the team welcomed apiaseck back to the FCOS release rotation.

Decisions

• The team agreed to file a formal change request for an Ignition RPM update to boost its visibility and promote the feature to potential users, even though a formal request is not strictly required by the release process.

Learn more about the CoreOS team.

IoT

During the Fedora IoT Working Group Meeting, the team reviewed OpenQA test results for current and upcoming releases. For Fedora IoT 44 (Stable), a new test failure surfaced for rpmostree-rebase on x86_64 and aarch64, alongside a known iot_clevis failure. Meanwhile, Fedora IoT 45 (Rawhide) tests improved after a recent x86 failure and are currently looking stable enough for Rawhide.

In broader community news, the migration of Fedora IoT repositories from Pagure to Forge is expected to happen very soon, potentially within the week. The team is currently waiting on the necessary group creation before moving things over, which contributors should keep in mind for upcoming engagement and issue tracking.

Learn more about the IoT team.

Cloud

This week, the Cloud group received a call for Fedora 45 Test Days proposals. Contributors and community members are encouraged to review the accepted Fedora 45 ChangeSet to identify features or areas of the distribution that would benefit from focused testing. Anyone interested in organizing or hosting an online test event can propose one by filing a ticket on Fedora Forge, making this an excellent engagement opportunity to help ensure the quality and stability of the upcoming Fedora 45 release.

Learn more about the Cloud team.

AI & ML

The Fedora AI initiative has relocated the repositories for the AI Developer Desktop Remix. Contributors and interested community members can now find and engage with the project at its new organization home on Codeberg. This migration is an important update for existing developers to ensure their local environments are synced with the new upstream location, and it provides a centralized hub for the broader Linux community to explore the remix.

Learn more about the AI & ML team.

RISC-V

During the June 23 meeting, the RISC-V group confirmed that Fedora 44 is being kept up to date with major package bumps, including GCC. The Fedora 45 rebuild has officially started with an initial focus on language toolchains, and the team is preparing for a Python 3.14 to 3.15 rebuild utilizing bootstrap sidetag strategies discussed in a recent Flock lightning talk. To avoid workflow disruptions, existing contributors should note that the dist-git overlay has been officially migrated from the old fedora.riscv.rocks infrastructure to forge.fedoraproject.org/riscv/.

Hardware capacity for the architecture continues to grow, with two SpacemiT K3 systems recently added to the Fedora Koji builders to maintain build momentum, and two more on the way. Finally, the group shared their Flock presentation slides and highlighted an open planning ticket for contributors interested in joining the discussion on the long-term roadmap for promoting riscv64 to a primary Koji architecture.

Learn more about the RISC-V team.

Security

The Security SIG met to discuss improving meeting structures, predictability, and ticket prioritization to prevent contributor burnout and maximize meeting value. To help contributors better prioritize their time and know when specific issues will be discussed, the team agreed to start publishing meeting agendas in advance rather than relying solely on ticket labels or ad-hoc discussions.

Additionally, Fedora's CRI-O packager put out a call for SELinux experts to help investigate a potential CRI-O, composefs, and SELinux bug affecting Fedora CoreOS. This presents a highly focused opportunity for contributors with SELinux knowledge to engage and assist with a critical container runtime issue that impacts the broader Linux container ecosystem.

Learn more about the Security team.

Gaming

This week, a community member proposed packaging nbsdgames for Fedora. This project is a lightweight collection of 21 terminal-based games that depends solely on ncurses. Because the author is unfamiliar with Fedora's specific packaging guidelines, this serves as an excellent, low-barrier engagement opportunity for an existing or new contributor looking to help expand the Fedora Games repository. To assist potential packagers, the author noted that using make nb or make nbinstall during the build process will easily prevent any naming conflicts with other existing game packages.

Learn more about the Gaming team.

Perl

This week, the Perl group's activity was centered around routine package maintenance. Specifically, Jitka Plesnikova opened and successfully merged a pull request to bump the perl-App-cpm package to version 1.1.2, addressing bug report rhbz#2492221.

Learn more about the Perl team.

Other Discussions

• A guide was shared on how to properly set a Fedora profile picture using Libravatar, including troubleshooting login loops and avatar update delays.
• Meeting notes for the Hummingbird project clarified its relationship with Fedora and defined "Agentic OS" simply as Linux with Kubernetes and standard GitOps workflows, rather than autonomous AI magic.
• A recap of the Fedora Mentor Summit at Flock 2026 highlighted successful Lunch & Learn sessions and community-building activities like sticker matching.
• The 2026 Fedora Contributor Recognition Program Winners were announced, celebrating Ankur Sinha, Fabio Valentini, and Justin Forbes for their outstanding community contributions.
• A thread initially about an AI bot making unauthorized Bugzilla changes evolved into a deep discussion about Two-Factor Authentication (2FA), exploring recovery token strategies and Kerberos ticket renewals via sssd-kcm and GNOME Online Accounts.
• Following FESCo's decision, the 2FA policy for provenpackagers is now active, prompting discussions on using kinit with Yubikey OTPs and obtaining 7-day renewable Kerberos tickets.
• A Change Proposal for a minimal GRUB bootloader tailored for Confidential Computing and Unified Kernel Images (UKIs) sparked debate over whether to include filesystem drivers (like Btrfs) or rely solely on FAT and the EFI System Partition.
• A discussion addressed the policy violation of shipping pre-built WASM and ELF binaries inside node_modules source archives, leading to proposals for new tools like npm2rpm to automatically strip them.
• A request to package AWS s2n-tls and aws-lc raised concerns about the responsiveness of the Fedora Crypto Team and whether the strict gatekeeping process for new cryptographic libraries needs reform.
• A proposal to explicitly permit macros like %rhel, %centos, and %hummingbird in spec files was met with pushback from some developers who consider %rhel an antipattern that causes packaging divergence.
• Other discussions this week included a call for Packager Dashboard maintainers, feedback on Node.js metapackages, help with git authentication for package releases, new helper scripts for upstream releases, an issue with redhat.com emails failing DMARC, handling Sphinx autodoc in RPM builds, optimizing compose disk space, addressing unmerged CMake 4 PRs, GCC plugin version dependencies, ideas to improve the Changes Process, centralizing GNOME SRPM macros, a planned infrastructure outage, the migration of the FESCo ticket tracker, a call for F45 Test Days, the disabling of F42 chroots in Copr, identifying package metadata in side-tag testing, and the resolution of git fsck issues in 71 package repos.

New contributor introductions

• Joshua Thomas introduced himself on the fedora-join list, expressing interest in contributing to QA and leveraging his homelab environment for Rawhide testing.

Orphaning packages

• Non-responsive maintainer checks were initiated for the fastnetmon, pyserial (where the maintainer subsequently replied), and ledger packages.
• The showtime, python-poetry-plugin-export, and libgsasl packages were officially orphaned or announced to be orphaned soon.
• Developers expressed interest in claiming and unorphaning the fx and python-persist-queue packages.

Package updates

• A mass rebuild was coordinated for the fmt and spdlog upgrades, overcoming temporary Koji builder stalls.
• A Change Proposal was announced to update libxml2 to version 2.15.3, requiring a system-wide mass rebuild and deprecating its Python bindings.
• Rebuilds were announced for the libcamel soname bump in evolution-data-server 3.61.1 and the Openbabel-3.2.0 upgrade.
• License changes were noted for the powdertoy and perl-Graphics-Toolkit-Color packages following upstream updates.

28 Jun 2026 11:14pm GMT

Time for a recap of the last week in my #fedora infra space (here in longer form).

Overall this week was a bunch of catch up from being away at flock, along with recovering from Jetlag.

27 Jun 2026 6:22pm GMT

27 Jun 2026 3:44pm GMT

How to migrate Fedora OS from one system to another, across network or (better) a Thunderbolt connection, without cloning the whole disk contents, saving SSD life.

Background

When migrating a Linux installation from a source drive to a target drive of a different size, traditional block-by-block tools like dd don't allow to migrate to a smaller drive, and also waste SSD life by writing unused blocks. This guide describes a simple approach in which different disk sizes can be used, and the process is performed over network (or Thunderbolt), so that it's not necessary to place two physical disks in the same device. The target system is exactly the same as the original, with all partition and filesystem UUIDs staying the same, which means no post-migration OS configuration is necessary. The time and SSD wear is minimized by pre-shrinking partitions and skipping unallocated disk space entirely. The default Fedora Workstation disk layout is supported, including LUKS encryption of the system partition.

This guide expects the following disk layout:

For simplicity, this will not try to skip copying all unused blocks, just most of them. The first two partitions will be cloned in raw mode. The third partition will be shrunk first (thus saving lots of blocks from being copied, and also supporting smaller target drives), and then cloned in raw mode.

Migration steps

Shrink the system partition on the source system

On the source system:

1. Delete all necessary data, prune cash dirs, empty the trash, etc.
2. Boot to a Fedora Workstation Live system from a USB drive.
3. Install necessary tools: sudo dnf install gparted pv
4. Run Gparted. In it, unlock the system partition, if encrypted. Then shrink the partition to a reasonable degree. For example, if the partition has 950 GB (from a 1 TB disk), but only 300 GB is used, you can shrink it e.g. to 350 GB. That still leaves enough free space for regular usage if you had to boot it for any reason, and saves 600 GB from being copied needlessly. This operation might take some time, because any data blocks currently present after the new size limit will need to be moved (therefore don't be too aggressive in setting the limit). If your partition was encrypted, make sure that both the LUKS encryption container and the filesystem inside it correctly show up as resized.
5. Unmount all partitions (if any), lock the encrypted partition (if applicable) and close GParted.

Erase the target system

On the target system:

1. Ensure that this is really the system you want to completely erase (and replace with the OS from the source system).
2. Ensure that the disk size is sufficient to fit all partitions from the source system (now that the system partition on the source system has been shrunk).
3. Boot to a Fedora Workstation Live system from a USB drive.
4. Install necessary tools: sudo dnf install sfdisk sgdisk
5. Unmount all partitions (if any). You can use e.g. GNOME Disks for this.
6. Erase the whole drive (make sure you're using the correct system): sudo wipefs -a /dev/nvme0n1
7. Discard all blocks on your drive (better for your SSD longevity): sudo blkdiscard -v /dev/nvme0n1

Establish an Ethernet/Thunderbolt network link

If you have both systems connected to the network and intend to use it, skip the Thunderbolt setup section below. Instead figure out the IP addresses of both systems (using the ip address command) and go to the Connectivity test.

Thunderbolt setup

If you want something faster than a regular network, have Thunderbolt ports on both systems and a fast USB-C cable ready, you can use that instead. With Thunderbolt, you can transfer data with 10 Gb/s speeds or more, compared to the common 1 Gb/s of a standard Ethernet.

1. On both laptops, after connecting them through a Thunderbolt cable, locate the network interface name: ip link
   Look for an interface like thunderbolt0.
2. Assign static IP addresses to them:

• Source system:
  bash sudo ip addr add 192.168.5.1/24 dev <interface_name>
sudo ip link set <interface_name> up
• Target system:
  bash sudo ip addr add 192.168.5.2/24 dev <interface_name>
sudo ip link set <interface_name> up

Connectivity test

1. Let's use a well-named variable for both numbers, so that we don't mix them up later. On both systems, run:

   export SOURCE_IP=192.168.5.1
   export TARGET_IP=192.168.5.2

2. Test connectivity between your systems.

• From the source system: ping $TARGET_IP
• From the target system: ping $SOURCE_IP
  
  You should see both systems pinging the other system correctly.

Replicate partition table from source to target

This will make an exact copy of the source system partition table (including partition UUIDs) on the target system. Then we will adjust it to the different disk size.

1. On target system, start listening for data and save it:

   nc -l -p 2000 > table.txt

2. On source system, dump the partition table and send it over:

   sudo sfdisk --dump /dev/nvme0n1 | nc $TARGET_IP 2000

3. On target system, apply the partition layout to the disk:

   sudo sfdisk /dev/nvme0n1 < table.txt

And then fix the GPT backup header location (because it's unlikely that you have both disks of exactly the same size):

   sudo sgdisk --move-second-header /dev/nvme0n1

Copy all partitions

Everything should be ready now to transfer all partitions data.

1. Clone the ESP partition (p1):

• On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p1 bs=4M

• On source system, send the data:

   sudo dd if=/dev/nvme0n1p1 bs=4M | pv | nc $TARGET_IP 2000

2. Clone the Boot partition (p2):

• On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p2 bs=4M

• On source system, send the data:

   sudo dd if=/dev/nvme0n1p2 bs=4M | pv | nc $TARGET_IP 2000

3. Clone the System partition (p3):

• On target system, listen and write the data:

   nc -l -p 2000 | sudo dd of=/dev/nvme0n1p3 bs=4M

• On source system, send the data:

   sudo dd if=/dev/nvme0n1p3 bs=4M | pv | nc $TARGET_IP 2000

Expand the System partition on the target system

Now that the target system is a complete clone of the source system, you can expand the System partition to fully utilize the remaining disk space:

1. Install GParted on the target system: sudo dnf install gparted
2. In Gparted, unlock the system partition, if encrypted. Then enlarge it according to your preferences. If your partition was encrypted, make sure that both the LUKS encryption container and the filesystem inside it correctly show up as resized.

Reboot the target system

You can now reboot the target system, and you should see your OS and data exactly the same as on your source system. The process is now complete.

Boot problems

In case the target system has a very different hardware from the source system (e.g. a different brand of a graphics card), the drivers might be missing from the current kernel initramfs and you can see a black screen or kernel errors. In that case, reboot the system again, press F8 repeatedly during boot to get into the GRUB bootloader menu, and boot the rescue Fedora option, instead of the default one. That should hopefully boot using the generic image (which should contain all known drivers), and then you can regenerate all the kernel images using your current hardware setup with: sudo dracut --regenerate-all --force

Mentions of other cloning approaches

1. Using dd
   This works fine when cloning to a larger disk (if you fix the partition table afterwards), but unused blocks are written needlessly (wearing down SSD), and migrating to a smaller drive is problematic.
2. Native Btrfs streams using btrfs send and btrfs receive
   This perfectly copies only used blocks of the main partition, but it only submits a single subvolume. Which means there's some extra work needed to make sure exactly the same subvolumes are replicated from source to target. Also, this works above the LUKS encryption, which also needs to be created manually on the target (while keeping IDs, etc).
3. Using Clonezilla
   Clonezilla will copy LUKS partitions as raw data, because it can't see inside. Furthermore, it doesn't support cloning to a smaller drive by default (there are some tweaks in Expert Mode, but you need to repair the GPT backup table manually anyway).

26 Jun 2026 5:01pm GMT

After about eleven months of using an AArch64 desktop, I decided to end that experiment.

Hardware used

About a year ago, I bought myself an Ampere Altra system. After moving some hardware around and making a few extra orders, the final setup was:

To be fair, I should mention that this is a server motherboard, not a desktop one, and Altra systems were never meant to be desktops (despite companies selling them as such). Naturally, the list of tested/approved devices (Qualified Vendor List (QVL for TLA fans)) is quite short and for Ampere Altra systems, it does not contain AMD Radeon GPU cards. They can be made to work, but this often requires additional effort.

The extra USB 3.2 controller allowed me to have more USB devices than the motherboard alone supported, and gave me some 10Gbps ports for connecting external NVMe drives.

The whole system was running just fine^* under Fedora 42-44.

The first issue

Have you noticed the small "*" at the end of the previous paragraph? The system I used was not quite Fedora - I had to use my own, self-built kernel.

You see, the PCI Express controller in the Ampere Altra has some issues. Let me quote the description of the Ampere Altra erratum 82288 patches:

Per Altra family erratum, PCIE_65 may cause invalid addresses to be generated on PCIe mmio writes, impacting certain device types, notably AMD GPUs, and thus the Altra family is not generally compatible with those device types.

And longer description from patch itself:

PCIe device drivers may map MMIO space as Normal, non-cacheable memory attribute (e.g. Linux kernel drivers mapping MMIO using ioremap_wc). This may be for the purpose of enabling write combining or unaligned accesses. This can result in data corruption on the PCIe interface's outbound MMIO writes due to issues with the write-combining operation.

The workaround modifies software that maps PCIe MMIO space as Normal, non-cacheable memory (e.g. ioremap_wc) to instead Device, non-gathering memory (e.g. ioremap). And all memory operations on PCIe MMIO space must be strictly aligned.

So, to have a working Linux system, I had to rebuild the kernel on every package update. Which usually meant "weekly". Each Monday or Tuesday, I would update the local copy of the Fedora kernel package repository and build it using my own versioning scheme, like "7.0.2-200.fc44.pcie65.6". The "pcie65" part reminded me which patches I had applied, and the "6" was a counter for the patch rebases.

I cloned the repository from GitHub and then rebased patches, adapting them whenever they needed work. The side effect was that I often used a newer kernel than the official Fedora release - there is a "stabilisation" branch in the Fedora kernel package repo where the soon-to-be-pushed version is present. So, when Fedora had 6.19.y kernel, I had 7.0.z one.

So many cores, not enough speed

As I wrote in my previous post, having eighty CPU cores does not mean that the system is a good, fast desktop machine.

AMD GPU started failing

As I mentioned above, to get my AMD Radeon RX6700XT running properly I had to alter kernel with the out-of-tree patches. It worked, I could play some games, watch videos with hardware-assisted video decode acceleration.

Until one day, around the Linux 7.0 release, when it started to fail. Running a game ended with:

kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0

Over and over again. Watching YouTube videos became impossible due to 720 out of 750 frames being dropped, etc.

Normally I would start to bisect the kernel to find out where the problem is. But I was running a tainted kernel due to PCIE65 patches so who knew where the problem actually was…

Let's get Nvidia

I bought an Nvidia RTX 2060 graphics card and put it in place of the AMD Radeon. It turned out that if I wanted to use it with the nouveau kernel driver I still needed PCIE65 patches applied…

So I tried default Fedora kernel with Nvidia binary driver. And it worked fine. Video decoding was accelerated, some games under Wine worked as well.

But then I started FreeCAD. And OrcaSlicer. And in both cases I got crash and exit…

It turned out that there was no org.freedesktop.Platform.GL.nvidia in Flatpak repositories for AArch64. And I used both of those tools quite often.

Powering up the old x86-64…

At that point, I gave up. And booted my x86-64 system, which had been powered off all that time. There were a lot of cables to move, some new ones to arrange, and now I have both "wooster" (Ampere Altra) and "puchatek" (Ryzen 5 3600) systems running under my desk.

Moving from 80 cores to 6 cores (12 threads) was a weird experience. A much smaller number, yet things work fine. I can load all threads and the music still plays. All games from my Steam library are playable. A working FreeCAD allows me to finish designing cases for my home projects and I can 3D print prototypes straight from OrcaSlicer.

The "wooster" system stays powered on, churning through RISC-V package builds. It may be weak in single-thread, but it flies when it comes to multi-core load.

Conclusion

As for the Ampere Altra, I am not planning to repeat this experiment. Another AArch64 desktop attempt would require a completely new hardware platform. And I have no plans to spend over twenty thousand PLN to buy an Nvidia DGX Spark system.

26 Jun 2026 11:18am GMT

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

Week: 22 - 26 June 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It's responsible for services running in Fedora infrastructure.
Ticket tracker

• Lost admin permission on packaging/FedoraReview after migrating from Pagure
• Request for IPA admin access on accounts.stg.fedoraproject.org
• Bodhi: only the rawhide package is visible in updates
• Fedora Rawhide mirror 404s

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It's responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• Attended/interacted with some Folks contributors (remotely attending and chat in matrix rooms)
• Rebuilt quite some dependencies for calligrabot/robosignatory for centos stream 10 infra change (https://redhat.atlassian.net/browse/CS-3402)
• Continue to work on all needed package rebuild phase for stream signing infra change (https://redhat.atlassian.net/browse/CS-3402)
• Rebuilt already 48 rpm pkgs for infra10s for centos stream signing upgrade (https://redhat.atlassian.net/browse/CS-3402) but unfortunately more to come
• Sprint planning meeting
• Claude helped me writing sms (standup-matrix-summarizer) which can be used to retrieve your "Done" section from each daily standup report, combine that into weekly view so that you can just then copy/paste into manager google doc. See https://gitlab.com/CentOS/infra/containers/standup-matrix-summarizer (and https://quay.io/repository/centos-infra/sms?tab=info)
• Rebuilt more pkgs for centos stream infra but also had to find workaround for orphaned pkg (https://redhat.atlassian.net/browse/CS-3402)
• Rotate some api keys for SIGs (https://gitlab.com/CentOS/infra/tracker/-/work_items/1940)
• Started to work on ansible boot-server role to convert for el10 and isc dhcpd replaced by kea (https://gitlab.com/CentOS/infra/tracker/-/work_items/1936) - WIP
• PoC for kea dhcp replacement for isc dhcpd gone from el10 (https://gitlab.com/CentOS/infra/tracker/-/work_items/1936)
• Created other tickets for .stg. stream el10 staging signing service (network ports for fedora-messaging stg rabbitmq hosts and two new service principals) - https://redhat.atlassian.net/browse/CS-3414
• Closed ticket (review) about all dependencies built and available for el10 robosignatory/calligrabot (https://redhat.atlassian.net/browse/CS-3413)
• Prepared staging host for centos-stream signing (https://redhat.atlassian.net/browse/CS-3414) but now blocked with a fedora infra staging issue (rabbitmq) so tried the whole day to debug but need someone from Fedora infra side to solve the issue there
• Riscv64 discussion about a new p550 hardware firmware upgrade
• Tested and validated that RH network team opened needed port for rabbitmq.stg.fedoraproject.org

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

• F45 rebuild started - we're trying to first focus on language toolchains - need to refer to Miro's lightning talk from Flock on how they handled Python bootstrap
• F44 is being kept up2date (there were some big updates, including GCC)
• Kevin did the legwork to move away from old dist-git on fedora.riscv.rocks to forge.fp.o
• Another K3 builder in Fedora Koji - another member added. (This might sound like a tame update, but all compute power is helpful / important to keep the build momentum :-))
• Discussed some details of riscv64 in primary Koji ticket
• Slides for Flock RISC-V update

AI

This is the summary of the work done regarding AI in Fedora.

• The AI Developer Desktop Remix repos have moved to an org on codeberg (https://codeberg.org/project-resistor)

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

• Flock & DevConf attendance, lruzicka gave a talk on openQA test investigation, adamwill gave a lightning talk with cle about Fedora CI improvements, several of us were involved in a workshop/roundtable about the viability/desirability of moving all testing to dist-git PRs, lots of productive side conversations etc., many about AI - trip reports / blog posts coming
• On-demand openQA test of dist-git PRs in progress
• Looks like we maybe found some new maintainers for packager-dashboard
• Lots of work to enable testing of the huge OpenSSL 4 update for Rawhide, investigate a significant bug that showed up, and eventually bypass the test failures for that bug as it's proving not to be possible to resolve in a reasonable time (the update needed to get merged)
• Continued tech debt / enhancement work on blockerbugs, testdays-web and issuebot

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

• PTOs & travel
• On Zabbix staging, now have a working template to monitor the Forgejo runnerhost VM and the runners themselves
• Continued work on Private Issues (private comments refactoring)

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

• Beta Wallpaper ticket closed

List of new releases of apps maintained by I&R Team

• Patch update of Fedora Messaging from 3.9.0 to 3.9.1 on 2026-06-23: https://github.com/fedora-infra/fedora-messaging/releases/tag/v3.9.1

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update - Week 26 2026 appeared first on Fedora Community Blog.

26 Jun 2026 10:00am GMT

Updates to translations of Fedora Documentation are again available. As announced on March 3rd, the unavailability of translation updates was due to the migration of the translation repositories and necessary tools from Pagure to the Fedora Forge. It took longer than expected but we are pleased to report this undertaking came finally to the end.

The post Fedora Documentation translations again available appeared first on Fedora Community Blog.

26 Jun 2026 9:19am GMT

26 Jun 2026 8:45am GMT

25 Jun 2026 10:00pm GMT