fidzu : Fedora

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.5RC1 are available

• as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

RPMs of PHP version 8.4.20RC1 are available

• as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

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

• PHP 8.5.5RC1 available for testing
• PHP 8.4.20RC1 available for testing

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:

• version 8.5.4RC1 is in Fedora rawhide for QA
• EL-10 packages are built using RHEL-10.1 and EPEL-10.1
• EL-9 packages are built using RHEL-9.7 and EPEL-9
• EL-8 packages are built using RHEL-8.10 and EPEL-8
• oci8 extension uses the RPM of the Oracle Instant Client version 23.9 on x86_64 and aarch64
• intl extension uses libicu 74.2
• RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
• versions 8.4.19 and 8.5.4 are planed for March 12th, in 2 weeks.

Software Collections (php84, php85)

Base packages (php)

27 Mar 2026 6:38am GMT

26 Mar 2026 11:00pm GMT

26 Mar 2026 12:42pm GMT

26 Mar 2026 11:50am GMT

25 Mar 2026 10:00pm GMT

25 Mar 2026 2:43pm GMT

25 Mar 2026 11:48am GMT

25 Mar 2026 4:00am GMT

After a full year of preparation, the Community Linux Engineering (CLE) team is excited to announce that Fedora Forge, powered by Forgejo, is ready for use! We are proud of this modern Open Source platform and what it means for the future of Fedora Infrastructure. While pagure.io has been a vital part of our community for many years, the time has come to retire our homegrown forge and transition to this powerful new tool.

The final cutover is planned for Flock to Fedora 2026. We strongly encourage teams to migrate their projects well before the conference to ensure a smooth transition. The pagure.io migration is only the first step in a broader infrastructure modernization effort. By the 2027 Fedora 46 release, we plan to retire all remaining Pagure instances across the project, including the package source repositories on src.fedoraproject.org. Getting familiar with Fedora Forge now will help ensure your team is ready as the rest of the Fedora ecosystem transitions.

pagure.io users, it is time to migrate!

If you own a project at pagure.io, you must migrate out of it before June 2026. We've prepared a Migration Guide. If you're unsure about what's happening, please keep reading

A Focused Scope for Fedora Forge

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 an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.

What belongs on Fedora Forge:

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

What does NOT belong:

• Personal Projects: Personal portfolios, dotfiles, or hobby projects not directly tied to Fedora are prohibited.
• General Upstream Development: If you are developing a general-purpose open-source application, its primary upstream development should be hosted elsewhere (e.g., GitHub, GitLab, Codeberg), even if it is packaged in Fedora. (Note: Foundational ecosystem tools like Koji or FreeIPA may qualify for exceptions via a ticket request ).

Why Migrate Early?

Migrating now avoids the "last-minute bottleneck" and gives your team time to adapt to the new resource limits outlined in the Usage Policy:

• Rewrite Automation: Refactor scripts and webhooks to use the new Forgejo API. Automated tools must respect rate limits and include descriptive user-agent strings.
• Test Your CI/CD: Native Forgejo Actions are available, but runners are a shared community resource. Builds are subject to a maximum timeout of 10 minutes per job.
• Clean Up Repositories: Repositories should ideally remain under 500MB. If your project requires large assets, you must use Git LFS (Large File Storage).

Feature Parity & Transparency

We are aware that Forgejo is not a 1:1 clone of Pagure. Most notably, private issues within public repositories are not currently supported in the same way. The CLE team is actively working with the upstream Forgejo community to bridge these functional gaps.

The Migration Roadmap

• Now - Pre-Flock: Proactive migrations. Please note that the Infrastructure team reserves the right to automatically archive repositories that have seen no activity for 6 months.
• Flock 2026: The final cutover.
• Post-Flock: pagure.io becomes a static, read-only historical archive.

Other Related Work

The Fedora Council currently has a draft usage policy under consideration, aimed at filling in the details of usage of the new forge instances inside the Fedora Project. Please watch for an additional article here on the Fedora Community Blog that starts the formal feedback process ahead of a Council vote on the policy.

Need help? For technical issues, please open a ticket on the Fedora Infrastructure Tracker or ask in the #fedora-admin Matrix channel.

Technical FAQ

How do authentication and team management work?
Authentication is fully integrated with the Fedora Account System (FAS) via OIDC. Team membership is directly mapped to FAS groups; if you are in a group, your permissions will automatically map to the corresponding Organization/Team on the Forge.

What happens to my API tokens and automation scripts?
Pagure API tokens will not migrate. You must generate new tokens within your account or organization settings on the new Forge and update your scripts to point to the Forgejo API.

Will my local git remote URLs break?
Yes. Once your repository is migrated, pushes to Pagure.io will be rejected. Update your remotes to the new instance:

git remote set-url origin https://forge.fedoraproject.org/<organization>/<your-project>.git

Are Issues and PRs migrating with full fidelity?
Yes. As outlined in the documentation, our tools port Pull Requests, Issues, and Issue Dependencies/Assignments. Pagure-specific tags will be mapped to Forgejo Labels.

Where do I go if my project's migration fails?
The CLE team is monitoring the #fedora-forge Matrix channel. Reach out there for help with permission desyncs, missing refs, or pipeline breakages.

The post The forge is our new home. appeared first on Fedora Community Blog.

24 Mar 2026 4:03pm GMT

I've seen "Warranty Void if Regenerated" going around, particularly among the subset of my friends who believe "LLMs are slop generators". They typically characterize it as overly optimistic - hopeful, if not downright fantasy.

The "slop generator" position is, in my opinion, demonstrably false, as countless successful code generation outcomes contradict such a sweeping generalization. The dogged pursuit of this position clouds the issue of the real concerns with LLMs as built and used today. I believe there are legitimate company ethics, environmental, and license/copyright concerns worthy of consideration in this space. I also believe that we are still in a highly emotional place where those concerns tend to be both understated and overstated depending on who is talking.

The story consists of three vignettes told from the perspective of Tom, a post-transition specification repair person who works with farmers. In this universe, all code is generated from specs and average humans are making custom software constantly. Domain experts are needed to refine, debug, and in some cases wholesale write the specifications.

There is also a great discussion of the human impact of this post-transition existence. I encourage you to read it, but I'm not addressing that below - not because it isn't important, but because I want to preserve focus on the "slop generator" drumbeat that feels so misguided.

All in all, I think the piece is well written and that Scott Werner did a great job. This isn't a critique of the writing or the story itself. I also don't know what Scott's perspective is on LLMs, though their public pages and site lead me to believe they are not anti-generative AI.

I'd been harboring a delusion in the back of my mind about trying to write a story about a "machine whisperer". Scott's piece reminded me that I am likely still not a creative writer, and I'm glad for their work here.

My thesis here is simple: this story reads like a set of specification and contract failures. It does not read like evidence that code generation inherently produces "slop" or that opaque code from code generation is inherently a failed concept. To be clear here, this is not a critique of Scott's view, but instead of the "slop generator" view point.

Margaret

Margaret has generated software that pulls in various data sets from both their farm and external sources to predict the best time to harvest. Their latest harvest was harvested before it should have been, and Tom realizes that the specification failed to include a requirement that it raise an error if a data source's structure or methodology changed. Instead, the system absorbed the data from an updated methodology and didn't change how it used that data.

This is shown to be a specification problem. The spec as written didn't suggest that changes were possible or that they should be monitored for, so the generated system didn't do that.

While this happens with, I suspect, regularity in hand-coded systems, my point isn't that this is normal. When it happens in a hand-coded system, it is wrong too. And, importantly, it is also a specification error.

There may never have been a specification in the first place and the developer was just expected to figure this out. Depending on their experience and other conditions, they either did … or they didn't. A clearer spec or set of standards (a/k/a a system prompt) would have fixed this in both cases.

Pit Crew

Scott introduces pit crews in this anecdote. These are people who monitor ongoing quality and concerns.

Today we often approximate this with monitoring systems that we hope are checking the right things, perhaps even with real end-to-end live tests running on a regular basis. We don't generally dedicate human teams to it.

Whether we ever hit post-transition or not, this begs for a conversation: is QE/QA solely a pre-ship function, or should we be leveraging that knowledge to monitor delivered software in ways that go deeper than what we typically monitor today? What does the SRE practice in this space look like?

Framed that way, the pit crew in the story is less a bandage for sloppy generated code and more the missing extension of our specifications and contracts into how we watch systems evolve over time.

Ethan

Ethan has generated a multitude of tools and they are all communicating with each other. Ethan is a microservice machine.

Ethan, much like Margaret, has a data feed problem. This time one of his own tools made a change in the methodology and calculated a value per-hundredweight instead of per-head. While not stated in the story, this unit for output was chosen at generation because it wasn't in the specification and the specification also didn't have a way (or likely even a requirement) to flag changes. The downstream tool didn't get a read failure but began using this new data value as though it was still per-head. This resulted in poor market price prediction.

The story is similar to Margaret's except it is more like when Team A breaks Team B in your own company.

For me it raises the interesting point that while we tend to believe otherwise, in many cases our APIs and data formats are our only true contracts. They operate only at the level where they exist. The internals of our dependencies, or the work of other teams, are opaque, and you could say that they may "regenerate" their code every day of the week and you just have to hope it still works for your consumption and use. You have to rely on them not breaking the contract and ensure the contract provides the guarantees you need.

Choreographer

A choreographer is a post-transition architect. It is, in my opinion, the thing we should all be if we are going to use LLMs to generate code.

Here a choreographer goes through Ethan's systems and defines their interface contracts and layers. They also notice that some tools are unnecessary, while others have formed a sub-network that has no effect. The output of this person's work is a cleaned up system that functions as a whole and not a set of discrete parts.

This is something we already have to do in large systems, and it's something that people generating code still have to do. I suspect that some concepts like Gastown try to push parts of this work into a different layer of tooling. And it may even work.

LLM generation and reasoning capacity is getting higher, but none of this eliminates the need for this role or for specification correctness. This is something which we've basically never had. Even waterfall failed here.

In this sense, the story reads less like an indictment of generation and more like a warning about what happens when we refuse to name, own, and maintain those contracts across a growing system.

Carol

Carol's farm illustrates the ugly mess of things we give automation and then complain about.

In this specific case there is a new irrigation system that is using all of the sensors it has to maintain a 60% moisture level across the farm. This results in under- and over-irrigation in some places because the moisture level in those places is influenced by external factors. The system is doing exactly what it was asked to do. The problem is that the target it was given is a bad fit for the actual farm not that the generated system is inherently bad.

Note: I am not a farmer, so I am taking this example at face value.

The short version is that drainage is funny in some places, other places are getting more wind, and still others need slightly differing levels based on the actual crop in that spot. None of this data has been provided to the system, and the story makes it clear that most of it is not in any system.

The farmer just understands their land and can look at it and tell you what is going to happen based on 30 years of real history and 30 years of experience. This is also not new. This is the art and practice of both coding and system administration, and we have failed to codify it usefully to date. We shouldn't hold our new system accountable for that, but we also shouldn't pretend that "just write a better spec" is an easy button when so much of the domain is still tacitly known and not shared beyond tribal means.

This is perhaps the one vignette that gives me pause. Even if we can find code generation (it doesn't have to be LLMs) that writes to a specification, we may still be unsuccessful when our measurements, abstractions, and language can't yet capture the thing we actually care about.

Right now we make surgical tweaks to the code to encode these lessons as we learn them. Specifying them in human language is often difficult, and maybe that is the core problem. The boundary here isn't really "hand-written vs generated code", it is between where, as technologists, we have experience stating precisely enough and where we don't have a history of doing that well.

But we work in a precise space. In the case of Carol's farm, Carol and Tom are able to describe the core problems pretty quickly, and I suspect, given time, could come up with data feeds, additional sensors, or equations that describe the issues sufficiently to fix the irrigation system.

It would be hyper-customized to Carol's farm, but in many ways that is what she wants and needs - and it's something we fail to deliver, in general, today. Even here, though, calling the outcome "slop" feels like a category error: the system is faithfully pursuing the narrow, naive target we gave it, not spewing random garbage.

The Real Conversation

I wrote this piece in part because the anti-LLM rhetoric of "they are slop generators" gets under my skin. There are a lot of valid reasons to be anti-LLM today. This is not one.

Reading the story reinforced that for me: what fails in these vignettes are specs, contracts, and incentives, not some inherent "slop" property of generated code. The story isn't an indictment of generated code, it's a parable about the timeless need for human wisdom, clear communication, and rigorous oversight, no matter how the code comes to be.

I'd like to see our LLM conversations stick closer to the concrete and demonstrably true. Let's focus on what these systems do, where they fail, and how our specs and contracts are part of that story, instead of getting pulled into slogans like "slop generator" that, by being false, derail the conversation. This creates space for us to have the real conversations that matter around ethics, the environment, and training data usage.

23 Mar 2026 10:50am GMT

23 Mar 2026 8:33am GMT

21 Mar 2026 7:38pm GMT

Things are just flying by and it seems to be saturday again, so here's another weekly recap.

21 Mar 2026 5:25pm GMT

The Fedora CoreOS and QA teams are gearing up for Fedora 44, and we need your help! We are organizing a Test Week running from March 23 to March 27, 2026.

This event is a nice opportunity for the community to test Fedora CoreOS (FCOS) based on Fedora 44 content before it officially reaches the testing and stable streams. By participating, you help us ensure a smooth and reliable experience for all users.

How does a Test Week work?

A Test Week is an event where anyone can help verify that the upcoming release works as expected. If you've been looking for a way to get started with Fedora contribution, this is the perfect entry point.

To participate, you simply need to:

• Download the FCOS test images.
• Follow the step-by-step test cases provided.
• Report whether the tests passed or failed on your hardware or VM.

The Wiki Page is your primary source of information for this event. Once you have completed your tests, please log your results here! Your contribution, big or small, makes a huge difference. Let's work together to make this release a great one. Happy testing!

Join the Live Sync Session

Want to chat with the team? We are hosting a virtual in-person session on Tuesday, March 24, from 3:00 PM - 4:30 PM UTC. Drop in to ask questions and get help with testing!

Video Meeting: meet.google.com/ufp-bwsb-zwh

21 Mar 2026 8:00am 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: 16 - 20 March 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

• Migrated postfix role to use lmdb instead of bdb
• Some trouble with AI scrapers
• Most of the nagios checks are now in Zabbix
• Migrating bugzilla2fedmsg to RH's Kafka instances

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 Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• CentOS Stream signing queue blocked
• Setup external repo for CentOS Stream 11
• Have c10s-aie-nv-pending packages signed and tagged
• Setup a CS pungi VM with a pungi new enough to use ImageBuilder
• Azerbaijan mirror
• OKD Tags request 5.0 and 5.1
• Change Zabbix to use OIDC login
• New mirror Server IP allow Request
• New Mirror Submission

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It's responsible for releases, retirement process of packages and package builds.
Ticket tracker

• Fedora 44 Final Freeze will begin on March 31st.
• Otherwise business as usual.

RISC-V

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

• Executive summary: Continued chipping away at closing the gap between primary and RISC-V Koji. Resumed stalled work to debug LLVM test-suite failures on Fedora; wrote a draft patch for LLVM to deal with some RISC-V specific failures. Real F44 rebuild work starts this week - finally, the F43 Koji task queue is empty (making way for F44 mass-rebuild). Discussed a rough plan for the rebuild in Fedora RISC-V SIG meeting. We plan to replace board-specific kernels for F44 and use the omni kernel. RISC-V EU Summit Program Committee work.
• F43 images can be obtained from here
• RISC-V omni kernels (formerly "unified") are now available here
• Shared Fedora notes for rebuilding OpenJDK to the fine folks doing the CentOS part.

AI

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

• [awilliam] Reviewed an MR to fix ai-code-review with Forgejo private repos, it threw up some interesting points
• [psklenar] Used Gemini to create a fuzz test for running all binaries on a system with random arguments, found some crashes

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.

• General release validation and bug reporting work throughout the whole week, in preparation for F44 Final.
• The i18n test days were run and finished.
• A VPN test case was created and added to release validation matrices.
• An alleged GPL violation in fedora-easy-karma caused by recent code refactoring should now hopefully be resolved in this commit. Red Hat Legal is informed, more changes might be needed, depending on their future feedback.
• A Universal Mesa Graphics Smoke Test was added to Fedora release validation and Fedora CI with the cooperation RHEL Desktop QA team.
• Ongoing work on automating basic networking tests, enabling CI for testdays-web, and porting blockerbugs to Forgejo

Forgejo

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

• Pagure.io sunset messages now live on website and CLI on git push.
• Demo of Pagure static pages backup at ryanlerch.fedorapeople.org. Net steps to get a full demo of this so we can share with people.
• New org requests ramping up as more Fedora repos get moved to forge.
• Private Issues: Make issue query helpers understand public and private issues

EPEL

This team is working on keeping Epel running and helping package things.

• Held RPM Packaging Workshop at SCALE
• Helped staff Fedora+CentOS booth at SCALE, with lots of EPEL discussion with conference attendees

UX

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

• Greetings from Fedora postcard ticket
• Initial Flock branding sketches posted ticket
• New repo on Design team Forgejo to store Gemini meeting notes so they're more accessible.

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 12 2026 appeared first on Fedora Community Blog.

20 Mar 2026 12:00pm GMT

20 Mar 2026 4:21am GMT