05 Aug 2026 12:00pm GMT

Running Large Language Models (LLMs) locally has become increasingly popular for development, privacy, and offline testing. Ollama makes this incredibly straightforward, allowing you to run models like Llama 3 or Mistral directly on your machine.

By leveraging Podman on Fedora Linux, you can isolate Ollama inside a container. This approach keeps your host system clean while making it effortless to spin up, manage, and tear down your AI development environment.

What is Ollama?

Ollama is an open-source framework designed for running, creating, and sharing large language models. It packages model weights, configuration, and data into a unified management system. Running it inside a container means you don't have to deal with complex local dependencies, Python environments, or complex GPU driver configurations on your base OS.

Verify or Install Podman

Podman is available by default in Fedora Workstation. It can be easily install, if missing, using DNF:

$ sudo dnf install podman -y

For Fedora Linux Silverblue users, Podman is natively available in the immutable base system and no extra steps are necessary.

To verify your installation and ensure everything is running smoothly, execute a quick check:

$ podman --version

Step 1: Create a Persistent Volume for Your Models

LLM weights can be huge-often ranging from 4 GB to over 40 GB, depending on the model size. To avoid downloading these models every time you restart your container, create a persistent Podman volume to store them safely on your host disk:

$ podman volume create ollama_storage

Step 2: Run the Ollama Container

Next, spin up the Ollama container. The following command pulls the official image, attaches the volume we just created, and maps the communication port (

) to your host machine.

$ podman run -d \
  -v ollama_storage:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Note on Hardware Acceleration

The command above runs Ollama using your CPU. If you are on Fedora Workstation or Silverblue and want to pass through an Nvidia GPU for fast hardware acceleration, make sure you have the Nvidia Container Toolkit installed and append the GPU flag:

--device nvidia.com/gpu=all

Step 3: Download and Run an AI Model

With the container running in the background, you can interact with it using Podman's execution command. Let's pull and run Llama 3, a highly capable, lightweight model perfect for local development:

$ podman exec -it ollama ollama run llama3

The first time you execute this, Podman will download the model weights into your

volume. Once the download completes, you will be dropped directly into an interactive terminal prompt:

>>> Send a message (/? for help)
>>> Tell me a fun fact about Fedora Linux.
Fedora Linux is named after the iconic felt hat worn by the Red Hat shadowman logo! It started as a community project to provide extra packages for Red Hat Linux.

>>>
To exit the interactive prompt, simply type /exit.

Step 4: Interact with the Local API

Because we mapped port 11434 to our host system, you can also interact with your local Ollama instance via its built-in REST API. Open a standard terminal window and send a curl request:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Why use containers?",
  "stream": false
}'

This returns a structured JSON payload containing your answer, allowing you to easily hook your local model up to web apps, scripts, or IDE extensions.

Checking Container Status

To monitor your running local AI instance, use the classic Podman management commands, perhaps starting with:

$ podman ps

You can also inspect the logs to make sure the API server is listening properly:

$ podman logs ollama

When you are done with your development session and want to free up system memory, stop the container:

$ podman stop ollama

If you ever need to completely remove the container environment, use:

$ podman rm ollama

Note: Your downloaded models are completely safe inside the ollama_storage volume and will instantly reattach the next time you spin up the container.

Conclusion

Using Podman to manage Ollama on Fedora Linux or Fedora Silverblue offers a clean, containerized way to build and test applications with LLMs completely offline. It bypasses host environment pollution, isolates large model storage cleanly into a named volume, and treats your AI stack exactly like any other microservice.

05 Aug 2026 8:00am GMT

05 Aug 2026 4:49am GMT

I have spent the last two years rebuilding GNOME Boxes from the ground up, driven by three main factors. I spoke extensively about this effort in my recent Linux App Summit, GUADEC 2025 and 2026 talks, but today I am excited to share the result for general testing.

First, shifting to a Flatpak-first (and only) model. As a solo developer, maintaining code paths for countless distributions isn't sustainable. Since Boxes acts as a frontend for libvirt/qemu, its functionality relies heavily on the backend configuration. Flatpak lets me bundle the entire virtualization stack, giving me the control I need to fine-tune it for our specific use cases.

Second, migrating Boxes to GTK4 and Libadwaita. Beyond the obvious benefits (a modern UI, better responsiveness, and tighter desktop integration) this makes the codebase significantly easier to maintain. This transition required moving away from the GTK3-based SPICE display widget, which was too tightly coupled to older input and drawing methods. We've replaced it with Libmks, which has proven to be a solid alternative.

Lastly, modernizing the codebase to make it sustainable for new contributors. That meant adopting modern GNOME app design patterns and rethinking our underlying architecture.

I am now ready to share this work with a wider audience. However, please keep in mind that this is a Beta release meant for testing, not for production environments. If you plan to try it out, make sure to back up any important data in your virtual machines first.

If you want to test this new implementation of GNOME Boxes, you can set up the GNOME Nightly Flatpak Repository and install it with:

flatpak install org.gnome.Boxes.Devel

This new version already covers most of what the classic Boxes could do: creating virtual machines from ISO media and disk images (qcow2), configuring VM resources, sharing clipboard content, sending files to the guest, and more.

It can install Windows 11 without any manual workarounds. Boxes configures Secure Boot and a virtual TPM device automatically. Everything required to pass the Windows 11 hardware compatibility checks out of the box. This was the most requested feature for the classic version, so I am particularly glad it is fully functional in this rewrite.

As distributions shift toward image-based OSes, this Flatpak-only approach becomes even more valuable. Most other virtual machine managers rely on host services or privileged daemons that are difficult to configure on immutable systems. While hardware and host combinations vary, bundling the backend stack directly inside the Flatpak gives us a controlled baseline that we can actively support, configure, and refine over time.

Accessing VM contents used to be tricky due to Flatpak sandboxing. This version addresses that by introducing a VSOCK device to the box, allowing guests with systemd v256 or newer to be accessed directly over SSH. It also adds initial support for port forwarding, letting you reach services running inside the VM from your host.

All of this and more is detailed on our new website, nightly.gnomeboxes.org, where you can also learn how to help by testing and reporting issues.

Please keep in mind that I am working on this in my free time alongside maintaining GNOME Settings and my day-job responsibilities at Red Hat. I ask for your patience with issue responses, but I will do my best to address bugs and keep pushing feature development forward as time allows.

I love building GNOME Boxes, and I am constantly motivated by the positive feedback from our community. People appreciate Boxes because it lets them set up a VM quickly and get straight to work without needing deep knowledge of virtualization or operating system internals. That remains the core mission, and that is the user experience I want to continue building for.

A lot of this implementation will still change as I gather feedback and it matures. I have also drafted a series of follow-up blog posts to this one, which will describe and elaborate a bit more on the new features, explaining how to use them and how they have been implemented. Stay tuned!

Comments

03 Aug 2026 11:28am GMT

This one is a bit light. I think that reflects the craziness of the summer and how I have worked through the backlog of my Instapaper. I've also been reading actual books (see below) so maybe you should too :D.

People

• Chasing life goals is a recipe for disaster - so try these tiny experiments instead

  Becoming the kind of parent you didn't have a model for.

  These are amazing words and regardless of our actual lived experience, I think we all feel this way when we have children.

• Communities are not fungible

  Not only are communities not fungible, but JA makes it crystal clear how they differ from person to person inside the community because they are overlapping Dunbar circles. Before I left Twitter, I remember thinking that I must be using a different Twitter from everyone else because my experience was nothing like what I was hearing about. The same is now true for me on Mastodon.

Machines and Politics

• Opinion | The Environmental Case Against Data Centers Is Misguided

  Data centers should be held to the same environmental standards as any other project.

  Why is this even controversial? I also believe we should price consumables at the correct cost reflecting our view on their impact as well as their production. I realize this will increase costs for many, including low-income members of our society, so instead we should surface the subsidy as a real subsidy line item. People should understand what things cost and what they have received as support.

  For bonus points we can make the subsidy refundable to encourage people to conserve.

• Hyperrealist Datacenters And Potemkin McRibs | blarg

  I like it when an article finally acknowledges the power of smaller models for many uses when talking about the LLM Data Center bubble. If you choose to use LLMs start running some experiments with non-frontier models, whether cloud hosted or local, I think you'll be pleasantly surprised.

  While you're reading this article, stay for the bonus McDonalds anecdotes. Per my daughter, as I am sad to admit, it has the best chicken nuggets a pork-market arbitraging real estate company can make.

• Opinion | Is France poorer than America? You don't have to 'walk around' to know.

  This is such an American question. It's like a reverse Tucker Carlson in a Russian grocery store. You know it is hard to toe the line when the best polish you can put on this turd of a proposition is, "[rural france is also] humdrum highways rather than picturesque public transit. The European endowment of beautiful architecture feels much richer than American acreage when you're, well, walking around. That effect is magnified by lower crime and public disorder in Europe." But yeah, let's talk about raw dollars baby.

Recently Finished Books

I've been tracking my book reading on my blog, but it never gets surfaced anywhere. I've decided to start including them here. Head to my reading page to find detailed notes or reactions for each book, similar in style to this post.

And finally

• A pan that won't let me rush dinner - Down the Road

  I'm learning that turning the burner higher doesn't actually make dinner happen appreciably sooner. It just makes it easier to burn dinner. So I'm going to learn to go low and slow.

  I remember reading somewhere that you should almost never set a burner above medium. These days when I cook, I'm using gas :( - but low and slow has paid off. The other day I was cooking a chicken breast in our go-to nonstick IKEA skillet. I'd done basically no prep due to a child who hates flavor and hadn't even tried to make it a similar thickness throughout. I wound up putting my skillet on too small of a burner, setting it to low, and hanging the pan half off the burner. This put the chicken on the off side recreating the indirect heat of a grill. I had juicy AF chicken. Suck it George Foreman!

03 Aug 2026 8:20am GMT

Flock 2026 was my first Fedora conference, and it won't be my last. I came home with new ideas, new friendships, and even a new project to work on for next year.

Appreciation

I want to start by appreciating the Flock organizers and volunteers. Putting together an event like this takes a lot of quiet, unglamorous work, and it showed in how smoothly everything ran. Thanks for that!

I'd also like to thank the event sponsors. Their support makes it possible for contributors from all over the world to come together, learn from one another, and strengthen the Fedora community.

I also want to appreciate my mentor, Jona, for pushing and supporting me until I finally made it. And a big thank you to Fedora for the sponsorship that got me there.

This year I also got to be part of the Mentor Summit organizing team myself and helped put together the very sessions I used to just attend as a newcomer. Full circle moment here

It has always felt rewarding to contribute to something I love, and Fedora has always been one of my favorite communities. Along the way, I've made great friends and met many wonderful people.

Finally, I'd like to thank the Nairobi GNU/Linux Users Group for supporting Fedora's Recognition Program this year by sponsoring the trophies and keychains. It was great to see our local community play a part in recognizing Fedora contributors, and I hope it's the beginning of a lasting tradition.

Our winners this time were; Fabio Valentini, Justin Forbes and Ankur Sinha in that order. Congratulations to you, and keep going You might want to hear from them in our podcast Fedora Contributor Recognition Program 056.

Diversity, Equity and Inclusion

I love how Fedora is so supportive of people from under-represented groups. Being at Flock felt like a reward for the work I've been doing with the community too - I had been organizing and mentoring from home. Being there in person and seeing that my work was appreciated meant a lot.

This is what I love about Fedora: it's welcoming, and it lives by the Four Foundations every day.

I also believe the in-person inclusive checklist I worked on last year helped make this year's event a success. I loved the venue - I guess that's why we went back to the same place as last year.

Honestly, I'd say everything was perfect. So hey, Flock organizers - the venue was perfect.

The talks

There was so much to take in: design, the mentor summit, docs and the docs initiative, lessons from FOSDEM and SCaLE, and so much more.

There was also the fbrnch workshop, Fedora data and analytics, and honestly too many good sessions to list them all here.

If there's one thing I keep learning about this community, it's that nothing happens unless you ask. People, or I would say, I personally don't wait to be picked here, I just find ways to engage, go deep, and just ask, ask, ask. I wanted to help with speaker logistics this year for Fedora Linux 44 release party, so while I was checking open tickets, I found it and asked if I could manage it. And I did it. I know some people might hesitate to just raise their hand like that, but Fedora is always welcoming, and honestly, we can always use the support. Get involved, it feels good to contribute to something you love.

Funny enough, a friend paid me a compliment (I think?) that I know how to navigate open-source communities and always find something to do. I'm still not sure if that's just a "community person" thing, or if it's because I genuinely like understanding people and learning new things. Maybe both.

Candy Swap

The candy swap - I totally loved this! Super awesome idea. Sorry to disappoint that I couldn't find time to bring anything, but I promise I will next time.

Mentor Summit

This was the 5th edition of the Fedora Mentor Summit, and it packed a lot into a few days. Lunch & Learn sessions ran across all three days, the informal, team-themed gatherings where you could step out of your usual circle and sit with people from Docs, Infra, Marketing, Packaging, Design, wherever you wanted to learn something new. No pressure, just conversation over food.

There was also a sticker-matching icebreaker, and everyone got a Fedora mascot sticker at registration, and the game was to go find your match and have a chat with them about anything open source.

Being on the organizing side of this for the first time gave me a whole new appreciation for how much quiet coordination goes into making something feel effortless for the people attending. Read more about how Mentor Summit came together here.

The hallway track

This is where the real magic happens. Daniel gave a brief, informal talk about eBPF, and honestly, that conversation ended up being one of the best parts of the whole trip.

I got to connect and meet team members, make new friends, and it was exciting just to sit and learn from them in a way a formal talk doesn't always allow.

And out of that hallway conversation, I actually found another thing to do within Fedora. I have a project I'm hoping to finish and present at the next Flock - mentored by Daniel on eBPF. (Putting this here for accountability, so you can hold me to it. )

I keep meeting super kind, good Fedora friends who are willing to mentor and give their time. It says a lot about how welcoming this community really is.

Everyone I met was kind, and always down to talk about their experiences and their love for open source - and how they hope more people get to know it, try free software, and enjoy it wherever they are, in their own languages. That last part is thanks to the i18n and translation teams across open source communities, doing work that often goes unnoticed.

Being early in my career, of course I had to ask people how they got in. I won't turn this into a rant, but if I had to summarize the advice: be a problem solver, and contribute to what you believe in - something you enjoy or find genuinely interesting.

*Thanks for reading this far. What's below isn't a big deal - just the city.*

The city

I extended my stay by 3 days to explore Prague. I took so many pictures my phone storage nearly gave up on me - I found almost everything lovely and fantastic. I'll link one of my best shots of the museum and the city below.

Thanks to my friend MatH for being my tour guide!

I totally loved it. It says something that the organizers knew just how magnificent this city is, and believed we'd love it again - and they were right.

I wish I could include every beautiful photo I took, but for now, these few will have to tell the story.

Take away

Every day with Fedora, I get to know more about open source, and I get to give back to my community back home.

I am Fedora

If any of this made you curious, here's where to start: come join us in Fedora Join SIG, or if you're just getting started, the Beginner's Guide is the friendliest place to land.

Your Friend in Open Source, and Open-Source Freedom Fighter.

03 Aug 2026 8:00am GMT

Across the various Fedora teams, a major shared focus is the ongoing infrastructure migration to Fedora Forge (Forgejo) and the formalization of its usage policies, a coordinated effort involving the Council, Infrastructure, Release Engineering, and Security groups. Quality assurance and release readiness for Fedora 45 also dominate the updates, highlighted by approaching testable deadlines, mass branching preparations, and FESCo's system-wide approval of gating all stable release updates using the rmdepcheck dependency checker. Meanwhile, user-facing and quality teams are heavily collaborating to troubleshoot critical system issues-most notably a Fedora 44 Workstation login lockout bug-while language-specific SIGs (Go, Perl, Ruby, Rust) are addressing routine maintenance, unannounced soname bumps, and evolving packaging standards. Finally, community outreach and organization remain highly active, with teams like Mindshare and Ambassadors rallying volunteers for upcoming events like FrOSCon 2026, and multiple working groups actively streamlining their documentation and meeting structures to improve contributor onboarding and combat maintainer burnout.

Announcements

Important deadlines and policy updates are approaching for Fedora contributors. First, the Fedora 45 Changes TESTABLE deadline is set for August 11, 2026, requiring all change owners to verify their tracker bugs are in a testable state. Additionally, maintainers should review the list of long-term FTBFS packages scheduled for retirement from Fedora 45 around August 5. On the infrastructure side, the Fedora Council has opened the proposed Fedora Forge Usage Policy for community feedback until August 13, establishing clear scopes and guidelines for the project's internal Forgejo instance. Finally, the long-running CLE "Community update" is officially retiring and being replaced by this new "This Week in Fedora" report to keep contributors informed.

In broader community news, a recent article highlights Peter Boy's work with the Docs Team to explain why Fedora needs more than just technical contributors. For those who missed the recent contributor conference in Prague, a new Flock 2026 Afterburn retrospective shares insights and survey results from the successful event. The project's multimedia outreach continues to see steady audience growth across platforms according to the Fedora Podcast 2026-Q2 metrics report. As part of that ongoing output, the team has just released Episode 057 diving into the history and mechanics of EPEL with Red Hat's Carl George, exploring a tool relied upon across the entire enterprise Linux ecosystem.

Council

The Council focused heavily on policy formalization and infrastructure migration this week. During their bi-weekly meeting, they agreed on edits to the Fedora Forge Usage Policy, settling debates on automated repository archiving by favoring manual oversight, and initiated the official community feedback phase. They also debated a draft Conflict of Interest Policy to handle sensitive governance decisions, and officially closed outdated requests to abolish the Fedora Contributor Agreement. Furthermore, discussions opened regarding the transition of the Digital Public Goods Alliance representative role following the FCA transition.

The Council also handled several operational and community requests. They approved an exception for FreeIPA to be hosted on Fedora Forge and decided to migrate the Fedora Budget repository while explicitly purging old private financial issues. Finally, the Council addressed trademark and organizational queries, declining a suspicious SIG creation request, signaling support for a trademark request for community stickers in Slovakia, and clarifying rebranding requirements for Fedora Remixes.

Decisions

• Approved an edit to the Fedora Forge Usage Policy regarding repository archiving, removing the automated 6-month rule, and initiated the official policy change process.
• Closed tickets #410 and #460 (Abolish Fedora Contributor Agreement / Re-license fedora-logos) as deferred/wont-fix due to a lack of capacity and legal constraints.
• Agreed to migrate the Fedora Budget repository to the Council space on Fedora Forge and delete all of its old private issues containing personal data.
• Approved an exception request (Ticket #575) allowing the FreeIPA organization to be hosted on Fedora Forge.
• Denied a suspicious Forge organization request for a new "Software Engineering SIG" (Ticket #573) because it did not follow the documented process.

Learn more about the Council team.

FESCo

This week, FESCo approved several significant system-wide changes, most notably retargeting the Enable Shadow Stack by Default on x86_64 change to Fedora 46 to ensure ample time to fix PyPI and Nvidia driver compatibility. Other major approvals include ODBC Stack Modernization, Native Butane Config Support in Ignition, and the libxml2 2.15 update which officially deprecates Python bindings and requires a mass rebuild. FESCo also fast-tracked and approved a proposal to gate all stable release updates on rmdepcheck to enhance update stability.

In contributor and project news, FESCo granted Proven Packager status to mschorm, merged an adjusted mid-term election policy, and sent final reminders for the upcoming 2FA requirement for all provenpackagers. Ongoing discussions are exploring the Forgejo distgit migration, a Bugzilla replacement tracker, and handling prohibited pre-built binary executables in node_modules. Furthermore, proposals to enable systemd-oomd and zram swap for CoreOS and use Sequoia's OpenPGP implementation are currently under active vote.

Decisions

• Approved the 'Enable Shadow Stack by Default on x86_64' Change, retargeting it for Fedora 46.
• Approved the 'libxml215' Change for Fedora 45.
• Approved the FastTrack proposal to gate all stable release updates on rmdepcheck.
• Approved the 'Native Butane Config Support in Ignition' Change.
• Approved the 'ODBC Stack Modernization' Change.
• Approved the 'LibreOffice Dictionaries' Change.
• Approved the 'LibreOffice html help' Change.
• Approved allowing the ELNBuildSync (EBS) service to use draft builds in Koji sidetags inherited from eln-build.
• Approved an adjustment to the election policy regarding seats filled after a member steps down mid-term.
• Approved a one-off slightly incompatible update request for rust-routinator.
• Approved the Request to become Proven Packager for mschorm.

Learn more about the FESCo team.

Mindshare

This week, Mindshare welcomed a new contributor who expressed interest in joining the CommOps team, pointing them to the Matrix chat and Forgejo issue tracker for immediate engagement opportunities. Additionally, preparations are actively underway for FrOSCon 2026, a free FOSS conference happening August 15-16 near Bonn, Germany. The team has secured a booth and is calling on community members to volunteer, create A4 project teasers to spark conversations, and join the pre-event hike to Drachenfels castle.

Decisions

• Confirmed that a Fedora project booth will be hosted at FrOSCon 2026.

Learn more about the Mindshare team.

Ambassadors

The Ambassadors group is calling for all hands on deck to prepare for FrOSCon 2026, scheduled for August 15-16 near Bonn, Germany. A Fedora booth is confirmed, and contributors are highly encouraged to engage by joining the Matrix room, adding their names to the event Wiki, or creating A4 teaser pages to spark conversations about their Fedora projects at the booth. Additional community-building activities include a planned Friday evening hike to Drachenfels castle, while work on the official event badge is currently pending.

Decisions

• Confirmed Fedora's booth presence and participation at FrOSCon 2026.

Learn more about the Ambassadors team.

Diversity & Inclusion

Justin Wheeler proposed putting DEI Team meetings on hiatus to protect the mental health of the chairs and prevent burnout. The team agreed that regular meetings had become stagnant and decided to shift their focus toward ad-hoc, event-specific teams with concrete goals and timelines, such as the Fedora Mentor Summit or Fedora Week of Diversity. General discussions will continue in the team chat room as needed.

Decisions

• Put regular DEI Team meetings on hiatus and transition to an ad-hoc, event-specific meeting model.
• Delete the regular DEI Team meeting entries from both the Fedora and Google Calendars.
• Open a volunteer call for Fedora Week of Diversity to evaluate if there is enough interest to execute the event later this year.

Learn more about the Diversity & Inclusion team.

Workstation / GNOME

This week, the Workstation/GNOME team discussed a login bug in the Fedora 44 Workstation ISO where users are occasionally locked out after setting their credentials. Contributors are working to gather logs and pinpoint the exact cause within gnome-initial-setup. Additionally, a new implementation restoring Google Drive integration in GNOME is currently under review by upstream maintainers, presenting a great opportunity for community testers to provide feedback.

In networking discussions, the team explored IPv6 prefix delegation issues involving routers that fail to invalidate old prefixes after rebooting, which leads to dropped connectivity. It was noted that router manufacturers like Mikrotik are currently working on firmware updates to align with RIPE recommendations, circumventing the need for immediate workarounds in Fedora's default network behavior.

Decisions

• Determined that the Fedora 44 Workstation login bug is related to user creation during first boot (gnome-initial-setup or shadow-utils) rather than Anaconda, which does not handle user creation on the Workstation Live image.

Learn more about the Workstation / GNOME team.

KDE

A user reported experiencing system freezes under Plasma (Wayland) after upgrading to Fedora 44, specifically noting that the nvidia-modeset/kthread_q process was consuming 100% CPU. The issue occurred on a hybrid graphics setup utilizing an AMD CPU and a discrete NVIDIA GPU running the proprietary NVIDIA drivers (610.43.03).

In the ensuing discussion, a community member advised checking the system and user journals via SSH before performing a forced reboot to isolate the root cause. The user was also directed to seek further assistance on the Fedora Discussion forum, which hosts a larger pool of contributors experienced with NVIDIA troubleshooting.

Learn more about the KDE team.

Server

During this week, the Server Working Group held a meeting to coordinate Fedora 45 release testing, Ansible support, and the Home Server spin-off. Contributors are encouraged to help test Brett's newly finalized Kiwi development environment for the Home Server project. On the automation front, the group is exploring the "AnsibleByExample" standard project layout and GitLab workflows for their upcoming Ansible roles, and an initial post-install role PR is being merged for member testing. For F45 testing, Emmanuel Seyman will review the upstream release changes for potential Server Edition impacts, and interested contributors were directed to the QA SIG to assist with openQA test automation.

Outside of the meeting, a forum discussion regarding IPv6 preferred_lft address routing issues with non-persistent prefixes concluded. A user shared a temporary workaround using Unique Local Unicast (ULA) and NAT while awaiting an upcoming patch from router manufacturer Mikrotik.

Decisions

• Emmanuel Seyman will review the Fedora 45 change list to identify potential issues for the Server Edition.
• The group will evaluate the 'AnsibleByExample' playbook structure and GitLab workflows to standardize their Ansible support repositories.
• John Himpel will merge Emmanuel Seyman's draft post-install Ansible PR to enable wider testing among members.
• The working group will begin testing and providing feedback on Brett's newly established virtualized Kiwi development environment for the Home Server spin-off.

Learn more about the Server team.

Infrastructure

This week, the Infrastructure team focused heavily on resolving post-migration issues following the upgrade of the IPA cluster to RHEL 10. Efforts were directed at stabilizing authentication services, addressing sporadic login errors on accounts.fedoraproject.org, fixing Ipsilon auth failures caused by browser tracking protection, and correcting LDAP schema replication errors. In the forums, a proposal was introduced to place an HAProxy load balancer in front of the IPA cluster to bypass ongoing DNS TTL caching problems. Work also continued on restoring the Koji staging database and migrating miscellaneous infrastructure hosts to RHEL 10.

Other notable discussions included optimizing Zabbix monitoring by implementing service-level layers, re-notifying on critical alerts, and exploring read-only guest access. The team also reviewed a proposal for a "test assets server" designed to drastically reduce network traffic by caching update repositories for Fedora CI and openQA. In parallel, Forgejo integration saw substantial updates, with new monitoring templates and continued progress on the highly requested private issues feature.

Decisions

• Set ipsilon02 as a backup server in HAProxy to mitigate authentication transaction failures caused by browser tracking protection.
• Completely disable (ensure absent) the mod_mime_magic Apache module on proxies and package servers to fix dist-git lookaside cache HTTP header issues.
• Add DNA range variables directly to the IPA Ansible playbook to automatically set them per host.
• Implement a 🔥 keyword highlight in Matrix clients to help administrators quickly spot Disaster-level Zabbix alerts.
• Patrikp will act as the chair for the August 13th Infrastructure meeting.

Learn more about the Infrastructure team.

Release Engineering

The Release Engineering team focused heavily on the final steps for migrating fedora-scm-requests from Pagure to Forgejo. To minimize disruption for contributors, the team agreed to coordinate the fedpkg tooling updates with a firm "flag day", ensuring developers receive appropriate upgrade warnings before the legacy Pagure API is fully disabled. Meanwhile, preparations are underway for the upcoming mass branching tentatively scheduled for August 11th, which includes updates to related Ansible tooling.

On the operations side, the group processed a dozen tickets, yielding several updates relevant to the broader Linux community. The F47 Release Signing Keys have been generated, a new eln-bootc repository was created on Quay to host bootc images for ELN composes, and the f45-perl side tag was successfully merged into Rawhide. Contributors are also reminded that package unretirements (for packages retired less than 8 weeks ago) can now be handled directly via the fedpkg request-unretirement command without needing to open a manual releng ticket.

Decisions

• Coordinate the fedora-scm-requests Forgejo migration using a synchronized 'flag day' to safely transition users to the updated fedpkg CLI, rather than attempting to maintain dual APIs.
• Provide access to staging compose hosts for Pungi PR testing by adding the requesting users to the sysadmin-releng staging group.
• Merge the f45-perl side tag into Rawhide following successful openQA testing.
• Direct package maintainers to use the fedpkg request-unretirement CLI command for recent unretirements rather than processing manual infrastructure tickets.

Learn more about the Release Engineering team.

Quality

This week, the Quality team saw a major workflow change as FESCo approved gating all stable release updates on the rmdepcheck tool, a rule that has already taken effect for in-flight updates. In the forums, contributors highlighted a critical login lockout bug on the Fedora 44 Workstation ISO and issued an important call for testers to evaluate a new Google Drive integration implementation for GNOME.

Additionally, quality engineering efforts successfully pushed a large Python rebuild update through testing and identified issues with Fedora 45 backgrounds via openQA. The team is actively preparing for upcoming Test Days and making numerous infrastructure updates to tools like Issuebot, Testdays-web, and Fedora Easy Karma ahead of the upcoming Fedora branches.

Decisions

• FESCo approved gating all stable release updates on the rmdepcheck reverse dependency static checker. This rule was implemented in production immediately and applies retrospectively to in-flight updates.

Learn more about the Quality team.

Websites and Apps

This week, the Websites and Apps group discussed a proposal to add a warning banner to the Fedora 44 download page regarding a login-blocking bug that reportedly prevents users from logging in after a fresh Workstation install. While the initial request suggested pointing users to a Respins SIG image with a patched Anaconda, QA representatives clarified that user creation is handled during first boot (gnome-initial-setup or plasma-setup), not by Anaconda. Consequently, the discussion pivoted to accurately reproducing the issue, presenting an opportunity for contributors to help collect diagnostic logs for first-boot login failures before any website changes are considered.

Decisions

• No changes or warning banners will be added to the download page until the reported login issue is properly reproduced and the root cause is correctly identified.

Learn more about the Websites and Apps team.

Design

The Design team saw a community member propose a custom wallpaper set for future Fedora releases, though it was noted it may not fit the current Fedora 46 theme. In ticket discussions, progress continued on the Contributor Onboarding Video Series, with the team agreeing on specific public-domain music tracks and moving forward with generating video previews.

Additionally, new UX/UI design requests were opened for a Fedora website credits page and a Project Resistor site redesign, prompting the team to propose a discovery call for the latter. Finally, the team discussed modernizing the outdated "What can I do for Fedora" site, ultimately closing the ticket with the decision to contact the upstream infrastructure maintainers before committing to new mockups, while also dropping the broken link from a new contributor poster.

Decisions

• Proceed with the chosen public-domain music tracks ("Jupiter" and "Never Speak of the Devil") for the Contributor Onboarding Video Series.
• Schedule a discovery call with the Project Resistor team to clarify whether they need mockups or full web development.
• Close the "What can I do for Fedora" redesign ticket to first check with the upstream repository maintainers before doing any design work.
• Remove the outdated "What can I do for Fedora" link from the new contributor poster.

Learn more about the Design team.

Docs

During the July 28 meeting, the Docs team discussed information architecture updates for the site's frontpage. Visual redesigns are delayed for 2-3 months while the Design team is busy, but a new staging landing page (docs.stg.fedoraproject.org) is currently live to test structural changes. The team also evaluated technical challenges regarding Antora repository module splits, noting that future structural updates might require significant URL redirects to maintain links. In broader community news, attendees were informed that a Flock 2026 recap and session videos will soon be available on Fedora Magazine and YouTube.

To improve contributor engagement, the staging site now features a dedicated section for new contributors, and the team is actively seeking collaboration with the Join SIG to refine it. There are also immediate, bite-sized opportunities for community members to get involved: volunteers are highly encouraged to help clean up obsolete Wiki pages in the Docs_Project category by applying a simple redirect macro, and anyone with CSS experience is welcome to help style the new frontpage.

Decisions

• Postpone major visual and CSS updates to the frontpage until the Design team has availability in 2-3 months, focusing entirely on content and information architecture in the meantime.
• Restrict the ongoing wiki deprecation and cleanup efforts strictly to the Docs_Project category to prevent scope creep.

Learn more about the Docs team.

Legal

This week, the Legal team addressed questions regarding firmware distribution and open-source license text anomalies. In a discussion about the foo2zjs printer driver, contributors asked if Fedora could package scripts that download necessary HP printer firmware. Legal clarified that scripts downloading from unofficial third-party mirrors (getweb) are not permitted, but a script fetching from the official OpenPrinting website (getweb-hpplugin) could be acceptable, pending a formal license review of the firmware to ensure it meets Fedora's technical criteria.

Additionally, in a thread concerning "All rights reserved" clauses appearing alongside FOSS licenses like BSD-3-Clause, the team concluded that this phrase is largely a redundant "cargo-cult" addition. Contributors are advised not to worry about it, as it can be safely ignored provided it is associated with a clear, acceptable open-source license grant.

Decisions

• Scripts downloading firmware from unofficial, third-party mirrors are not permitted in Fedora.
• Scripts downloading firmware from official sources (like OpenPrinting) may be acceptable, but the specific firmware license must first undergo a formal legal review against Fedora's technical firmware requirements.
• The phrase "All rights reserved" found alongside upstream FOSS licenses is considered redundant and can be safely ignored as long as it is paired with an acceptable open-source license grant.

Learn more about the Legal team.

EPEL

This week, the EPEL team focused heavily on the EPEL 11 and EPEL 10 directory naming scheme proposal to address feedback from enterprise rebuild communities (such as AlmaLinux and Rocky Linux) regarding private mirrors and repository redirection. During their weekly meeting, the team laid out a timeline to evaluate and implement these changes before the RHEL 10.3 branching to avoid disrupting early adopters. Additionally, on the mailing list, it was announced that FESCo has approved gating all Fedora stable release updates using the rmdepcheck reverse dependency static checker, a policy that will soon be evaluated for EPEL as well.

In broader contributor and community news, routine package maintenance and quality assurance continued, including the introduction of new EPEL 10 packages and efforts to resolve failing-to-install (FTI) and policy-breaking packages in EPEL 9. Community engagement was also highlighted, with an upcoming Fedora Podcast interview featuring Carl George to discuss the EPEL 11 proposal and raise broader Linux community awareness.

Decisions

• The team agreed to schedule a vote on the EPEL 11 portion of the naming scheme proposal for August 5th, and a vote on the EPEL 10 portion for August 12th.

Learn more about the EPEL team.

ELN

During the July 28 ELN meeting, the team announced that ELN bootc images are now building regularly on Konflux. Contributors are currently resolving minor early-testing issues and working to establish an automated pipeline to the production registry (quay.io/fedora/eln-bootc). Additionally, qcow2 and ec2 images are now being successfully built using image-builder and have been validated on AWS, with pull requests open to integrate Azure and GCE support.

Looking ahead to RHEL 11, the group also debated whether to drop hardware firmware (such as linux-firmware) from cloud images. Acknowledging that hardware passthrough is still utilized on some hyperscalers, the group opted to move this conversation to a dedicated issue to carefully evaluate how closely ELN should mirror future RHEL decisions without disrupting existing use cases.

Decisions

• Tasked Simon de Vlieger with investigating how to properly upload and publish Konflux bootc builds to the quay.io/fedora/eln-bootc registry.
• Decided to move the discussion regarding the removal of hardware firmware from ELN cloud images to a separate issue tracker.

Learn more about the ELN team.

Atomic

In the weekly meeting, the team highlighted continued progress on ELN and Konflux integration, specifically regarding plans to migrate base images from GitLab. A blocker regarding a Konflux service account is currently being addressed by the infrastructure team, which is expected to unblock development shortly. Leadership also noted pending action items to formalize the SIG's setup process and establish a dedicated Fedocal calendar for contributors.

Meanwhile, an ongoing forum discussion regarding the proposed systemd-sysexts SIG focused on the administrative steps for launching the group. To navigate confusing documentation rules, contributors agreed to initially outline the new SIG's scope on a standard Fedora Wiki page before requesting a dedicated Forge organization and Matrix channel.

Learn more about the Atomic team.

CoreOS

This week, the CoreOS group focused on upcoming release testing, tentatively scheduling the Fedora CoreOS 45 Test Day and live video meeting for September 21st. Technical discussions highlighted the Ignition Native Butane Support proposal, which will remove the need for an external conversion step during provisioning; the team plans to gather feedback on this from the Flatcar community. Additionally, contributors addressed issues with the CodeRabbit PR bot leaving unprofessional comments in the Afterburn repository, planning to establish a dedicated repository to manage global configuration defaults.

In the forums, progress continued on establishing the systemd-sysexts SIG. Contributors discussed the optimal way to host the SIG's initial documentation, ultimately recommending starting with a Fedora Wiki page before requesting a dedicated Forge organization to bypass current procedural documentation challenges.

Decisions

• Tentatively schedule the Fedora CoreOS 45 Test Day and live video meeting for 2026-09-21, pending the final Beta Release schedule.
• Address inappropriate CodeRabbit PR bot comments by disabling them in affected repositories and creating a central coreos/coderabbit repository for global default configurations.

Learn more about the CoreOS team.

AI & ML

This week, the AI & ML group announced that GPU CI testing is now operational and available for contributors in the AI/ML SIG. Furthermore, the AI Developer Desktop has achieved its initial integration with OpenShell, marking an exciting step forward for the project.

In administrative updates, a contributor requested to be removed from the SIG due to time constraints and burnout. The group processed this request, removing the member from the SIG-related GitLab groups and the pytorch-sig membership to ensure an accurate representation of active contributors.

Learn more about the AI & ML team.

Security

During their weekly meeting, the Security SIG focused on formalizing internal vulnerability management processes and establishing documentation standards. A primary initiative is preparing for Fedora's representation on the private linux-distros mailing list to safely handle embargoed pre-disclosure vulnerabilities. To support this, the team is defining clear policies, establishing a secure Bugzilla workflow, and setting up dedicated access groups. In news relevant to the broader Linux ecosystem, the group is defining and documenting Fedora's role as a CVE Numbering Authority (CNA) and auditing existing documentation to align with the EU Cyber Resilience Act (CRA) requirements.

To improve contributor engagement opportunities, the team successfully migrated the Defensive Coding Guide from Pagure to Forgejo, opening the door for new community contributions. Discussions are also underway on the forum to review Fedora-maintained hardening guidelines and on the tracker to explore creating a vulnerability reporting badge as a non-monetary bug bounty alternative.

Decisions

• Draft comprehensive documentation detailing Fedora's scope and guidelines as a CVE Numbering Authority (CNA).
• Create a new FAS group named sec-bugzappers to manage access for Fedora representatives handling the linux-distros pre-disclosure mailing list.
• Establish a dedicated, private Bugzilla component (proposed as distribution-private or fedora-security) to track embargoed vulnerability reports.
• Draft a platform-neutral policy for handling pre-disclosure vulnerabilities and submit it as a PR to the Security team's documentation.
• Grant all Security SIG members the privilege to create new repositories within the Forge group to remove documentation bottlenecks.
• Close the Pagure repository and officially migrate the Defensive Coding Guide to the Security SIG's Forge namespace.

Learn more about the Security team.

Go

During the Go SIG meeting, the team discussed standardizing CGO_CFLAGS and related compiler flags across Fedora by introducing a new %go_set_cgo_flags macro, which will undergo mass prebuild testing to avoid disrupting existing packages. The group also approved a new SIG membership policy that will be appended to the project README, clarifying the justification required for elevated package privileges. For contributors looking to get involved, assistance is needed to patch downstream packages broken by recent Go 1.27 updates, specifically those affected by changes to json v2, compress/flate, and grpc.

In broader Linux ecosystem news, the unmaintained license-scanning tool askalono has been forked into a newly maintained project named scallion. Fedora's Go packaging stack will pivot to use scallion as its default license detector. Additionally, efforts are underway to provide a minimal go-vendor-tools package for RHEL 11 by stripping optional build-time dependencies, an initiative that presents immediate opportunities for contributors to write tmt-based integration tests.

Decisions

• Approved the new Go SIG membership policy, which will be formalized via a PR to the project repository.
• Agreed to introduce scallion as the replacement for the unmaintained askalono license scanner, with upcoming changes planned for both go-vendor-tools and go2rpm.
• Decided to release go2rpm v2 with the default configuration set to the vendor profile.
• Agreed to support go-vendor-tools in RHEL 11 by isolating the RHEL-specific changes in a separate GitLab branch and developing new tmt-based integration tests.

Learn more about the Go team.

Perl

This week, the Perl group focused heavily on package maintenance, compatibility updates, and version bumps. Several pull requests were merged, including conditionalizing dependencies for perl-Module-Build-Tiny, disabling optional dependencies for perl-Compress-Raw-Lzma in RHEL, and addressing Wx 3.2.9 compatibility in perl-Wx. A patch for OpenSSL 4 ASN.1 strings was integrated into perl-Crypt-SMIME. Additionally, routine version bumps were applied to perl-LWP-Protocol-https (6.17), perl-HTTP-Message (7.04), and perl-ExtUtils-XSpp (0.19).

Other ongoing discussions involved resolving an expected installability failure during the bootstrap of perl-SQL-Abstract and addressing MySQL 9.7 rebuilds for perl-DBD-MySQL, though the latter's PR was closed as the fix was committed directly to the rawhide branch.

Decisions

• Merge pull request to conditionalize CPAN::Requirements::Dynamic dependency in perl-Module-Build-Tiny.
• Merge pull request to disable optional dependencies for perl-Compress-Raw-Lzma in RHEL.
• Merge pull request applying a compatibility patch for Wx 3.2.9 in perl-Wx.
• Merge pull request containing an OpenSSL 4 ASN.1 string patch for perl-Crypt-SMIME.
• Close the perl-DBD-MySQL PR for the MySQL 9.7 rebuild without merging, as it was fixed directly in the rawhide branch.
• Merge version bump pull requests for perl-LWP-Protocol-https (6.17), perl-HTTP-Message (7.04), and perl-ExtUtils-XSpp (0.19).

Learn more about the Perl team.

Python

A contributor raised a packaging question regarding the dupeguru package (Bugzilla 2497737), which is currently waiting for review. The upstream code uses generic top-level modules (core, hscommon, qt), which could cause namespace conflicts with other applications. The main subject of inquiry was whether reorganizing the source tree to place these folders under a specific dupeguru namespace is the recommended approach for Fedora packaging.

Learn more about the Python team.

Ruby

Vít Ondruch announced that the upgrade to Ruby on Rails 8.1 (specifically version 8.1.2) has officially landed in Fedora. An update to the recently released version 8.1.3.1 is planned for the near future, as it was temporarily delayed to meet the change deadline. From a packaging perspective, there were no major structural changes, with the notable exception of Trix being extracted into a separate new package. Contributors and users are highly encouraged to test the new release and report any issues.

Decisions

• Upgrade the Ruby on Rails package to version 8.1.2.
• Extract Trix into a new, separate package.
• Delay the update to Rails 8.1.3.1 temporarily to ensure the 8.1.2 update meets the change deadline.

Learn more about the Ruby team.

Rust

Frank Dana proposed a new packaging method for Rust and Python that would replace feature-specific subpackages with a conditional Requires: ... for syntax in RPM. He argued that the current glut of subpackages creates excessive metadata, bloats dnf search results, and clutters local systems.

During the discussion, Fabio Valentini pointed out that Rust packaging tooling must maintain backward compatibility with RHEL 9, making this unfeasible to implement in the near future, and suggested using fedpkg mockbuild instead of local builds to avoid cluttering personal environments. Carl George noted that since some Python extra subpackages contain actual files (like CLI commands or man pages), the proposed mechanism could not fully replace subpackages, though both systems could potentially coexist.

Learn more about the Rust team.

Other Discussions

• Jakub Kadlčík proposed a reimagined Fedora Package Review Process using a temporary Forge repository, PRs with CI, and testing multiple packages in one go. After feedback regarding SRPM support and vendor archives, he planned to leverage Packit and Copr's custom build scripts instead of Forgejo Actions.
• A Hummingbird Community Meeting took place to discuss the intersection of Linux distributions and AI. Demos included Project Bluefin's autonomous agentic OS factory using Hive and Red Hat Hardened Images acting as a downstream for Fedora Hummingbird Linux.
• A user reported a privacy issue with Firefox RPMs because geoclue2 was installed as a dependency via xdg-desktop-portal. Community members shared configuration workarounds to disable the service's tracking capabilities.
• Simon de Vlieger published a blog post detailing how the Fedora 45 release is produced, explaining the pipeline from raw packages to final artifacts like ISOs and disk images.
• Tomáš Hrčka announced an update postponing the pagure.io sunset. The delay allows the team to finish migrating critical SCM repositories like fedora-scm-requests and to finalize ForgeFiler, a tool handling private issues temporarily missing from Forgejo.
• After a lengthy thread about too much automated email on the devel list, Kevin Fenzi disabled the Rawhide and ELN compose reports. Users who still want these notifications must now subscribe to the test-reports mailing list.
• A Change Proposal to enable Shadow Stack by default on x86_64 in Fedora 45 sparked discussion around compatibility. Discussions are ongoing regarding PyPI wheels built via manylinux, NVIDIA drivers, and Rust binaries (which have already been updated in Rawhide to build with SHSTK enabled).
• Adam Williamson's proposal to gate all stable release updates on rmdepcheck was approved by FESCo. The static reverse dependency checker is now active in production, successfully catching several genuine dependency breakages and minor infrastructure blips.
• A proposal to disable Vendor Change by default in DNF5 raised concerns that system upgrades might break for packages transitioning from third-party repos (like RPM Fusion) to official Fedora repos. It was suggested that specific vendor transition configurations could mitigate these issues automatically.
• A Change Proposal seeking to restrict Change discussions exclusively to the devel mailing list while leaving Discourse posts as read-only received mixed feedback. Some members proposed batch-posting announcements or finding a middle ground to minimize the split-brain effect that leads to maintainer burnout.
• Other discussions this week covered issues rendering the f45-backgrounds in KDE, a tech preview for Web Based Remote Installation for Atomic Desktops, a review request for the dupeguru duplicate file finder, the migration of the packager-sponsors tracker to Fedora Forge, community thoughts in regards to Change Proposals, and a reminder about the approaching F45 Changes TESTABLE deadline.

Orphaning packages

• Miro Hrončok posted a list of long term FTBFS packages to be retired in August that have failed to build since Fedora 42.
• Nicolas Chauvet issued a schroedinger retirement notice, retiring the package because it has been unmaintained upstream for 10 years and replaced by ffmpeg.
• Jan Stanek announced that nodejs20 is retired in rawhide following its upstream End of Life, advising users to migrate to nodejs22 or 24.
• Phoebe Harris announced an intention to take ownership of and unretire rust-qrcode and rust-wildmatch to support the clifton application.
• Scott Theisen submitted patches to build the orphaned packages python-markups and retext, though he has not formally adopted them.
• Sergio Pascual started an orphaning blitz by retiring the obsolete C++ array library blitz.
• The automated report of orphaned packages looking for new maintainers detailed numerous unmaintained packages at risk of retirement within six weeks.
• Richard Shaw asked if anyone wants to save python-pivy before it breaks completely due to missing dependencies.

Package updates

• An unannounced soname bump for nettle caused several FTBFS issues; a nettle3.10-devel compat package was shipped to unblock builds while maintainers port to Nettle 4.
• An unannounced soname bump for openssl-pkcs11 broke dependencies for nextcloud-client, requiring provenpackagers to merge PRs and rebuild the client in a side-tag.
• Iker Pedrosa announced a shadow rebase and libsubid SONAME bump being prepared in a side-tag, asking container tool maintainers to rebuild their packages.
• Michel Lind issued an RFC on an incompatible update for routinator due to a major security fix removing a vulnerable feature, which has now been pushed to stable.
• Ben Beasley gave a heads-up about an ABI-incompatible update for rapidyaml 0.16.0 coming to Rawhide.
• Pavel Valena requested testing for an upgrade to dracut 111 in Rawhide.
• Milan Crha announced a short-notice libedataserver soname version bump in Rawhide, providing a side-tag for dependent package rebuilds.
• Fabio Valentini warned of an unannounced soname bump for libgnome-desktop-3 affecting dozens of GNOME-related packages.

New contributor introductions

• Phoebe Harris: An embedded software developer aiming to package the SSH connection manager clifton and Typst.
• Dawid Wrobel: A KMyMoney developer returning to Linux who wants to adopt outdated GNOME extensions and package Betterbird.
• Myriade: A young Rust developer intending to adopt and maintain the orphaned supercollider package.
• Nikolay: A software engineer developing qTox who is interested in deep neural networks and machine learning.
• Vivek Denny: A backend/cloud developer with an interest in low-level systems and networks wanting to give back to open source.

03 Aug 2026 6:41am GMT

02 Aug 2026 12:40am GMT

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

1. Installation

Packages are available in the redis:remi-8.8 module stream.

1.1. Using dnf4 on Enterprise Linux

# dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %rhel).rpm
# dnf module switch-to redis:remi-8.10/common

1.2. Using dnf5 on Fedora

# dnf install https://rpms.remirepo.net/fedora/remi-release-$(rpm -E %fedora).rpm
# dnf module reset  redis
# dnf module enable redis:remi-8.10
# dnf install redis --allowerasing

You may have to remove the valkey-compat-redis compatibility package.

2. Modules

Some optional modules are also available:

• RedisBloom as redis-bloom
• RedisJSON as redis-json
• RedisTimeSeries as redis-timeseries

These packages are weak dependencies of Redis, so they are installed by default (if install_weak_deps is not disabled in the dnf configuration).

The modules are automatically loaded after installation and service (re)start.

The modules are not available for Enterprise Linux 8.

3. Statistics

redis

redis-bloom

redis-json

redis-timeseries

31 Jul 2026 7:27am GMT

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

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

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

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

ℹ️ These versions are also available as Software Collections in the remi-safe repository.

ℹ️ The packages are available for x86_64 and aarch64.

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

🛡️ These Versions fix 3 security bugs (CVE-2026-7260, CVE-2026-17543, CVE-2026-17544), so the update is strongly recommended.

Version announcements:

• PHP 8.5.8 Release Annoucement
• PHP 8.4.23 Release Annoucement
• PHP 8.3.32 Release Annoucement
• PHP 8.2.32 Release Annoucement

ℹ️ Installation: Use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.5 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.5/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.5
dnf update

Parallel installation of version 8.5 as Software Collection

yum install php85

Replacement of default PHP by version 8.4 installation (simplest):

On Enterprise Linux (dnf 4)

dnf module switch-to php:remi-8.4/common

On Fedora (dnf 5)

dnf module reset php
dnf module enable php:remi-8.4
dnf update

Parallel installation of version 8.4 as Software Collection

yum install php84

And soon in the official updates:

• Fedora Rawhide now has PHP version 8.5.9
• Fedora 44 - PHP 8.5.9
• Fedora 43 - PHP 8.4.24

⚠️ To be noticed :

• EL-10 RPMs are built using RHEL-10.2
• EL-9 RPMs are built using RHEL-9.8
• EL-8 RPMs are built using RHEL-8.10
• intl extension now uses libicu74 (version 74.2)
• mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
• oci8 extension now uses the RPM of Oracle Instant Client version 23.26 on x86_64 and aarch64
• A lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ️ Information:

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

Base packages (php)

Software Collections (php83 / php84 / php85)

31 Jul 2026 5:05am GMT

31 Jul 2026 12:28am GMT

30 Jul 2026 10:00pm GMT

After extensive review and discussion on the ticket request and in recent council meetings (see meetbot for 29 July and 15 July 2026), the Fedora Council would like to initiate the policy change policy process for ratifying the Fedora Forge Usage policy. This document is open to public feedback (if any) for a minimum of two weeks. If there are no significant changes to be made to the policy based on community feedback after Thursday, 13 August 2026, this policy will go to a formal ticket vote for Council to approve or reject.
If there are significant changes to be made to the document, Council will review the policy and, if necessary, extend the feedback period before calling for an official vote. Please provide feedback on the discussion post.

The policy can be found on the Council wiki page in Fedora Forge, posted on discourse, and pasted below here for convenience.

Thank you everyone for your contributions to this policy so far, and on behalf of the Council, we look forward to working with you all to ratify this policy soon.

Fedora Forge Usage Policy

Welcome to the Fedora Forge. This Forgejo instance is provided by the Fedora Infrastructure team to support the daily operations, development, and collaboration of the Fedora Project.

To ensure this service remains reliable, secure, and useful for everyone in the Fedora community, all users must adhere to the following usage policy.

1. Scope, Criteria, and Exceptions

The Fedora Forge is a dedicated workspace for the Fedora Project. Historically, the Fedora Project utilized pagure.io, which operated as a general-use public forge where Fedora repositories coexisted alongside personal projects, unrelated upstream software, and individual portfolios.

The Fedora Forge (powered by Forgejo) intentionally adopts a narrower scope. It is not a public, general-use Git hosting provider. It is an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.

Criteria for "Fedora Project Related"

To qualify for hosting on the Fedora Forge, a repository must meet at least one of the following criteria:

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

Exceptions and Special Cases (Ecosystem Upstreams)

While general upstream development should happen on public forges (like GitHub, GitLab, or Codeberg), the Fedora Project recognizes that certain large-scale upstream projects are so deeply intertwined with Fedora's infrastructure and history that they qualify as exceptions.

Recognized Exceptions:

• Foundational infrastructure tools heavily maintained by Fedora and Red Hat ecosystem contributors (e.g., Koji, FreeIPA).
• Core system components where the primary development team is historically rooted in the Fedora community and relies on Fedora Infrastructure for their workflow.

Note: Being packaged in the Fedora repository does not automatically grant a project exception status to use the Fedora Forge as its upstream host.

Decision Process for Edge Cases

If a community member is unsure whether their project fits the scope or qualifies as an ecosystem exception, the following process applies:

1. Request Submission: The requester must open a ticket on the Fedora Infrastructure tracker, detailing the project's purpose, its connection to Fedora, and why it should be hosted on the Fedora Forge rather than a public alternative.
2. Infrastructure Review: The Fedora Infrastructure team will conduct an initial review against the established criteria to assess technical feasibility and resource impact.
3. Steering Committee Consultation: If the request falls into a gray area, the Infrastructure team will escalate the ticket to the Fedora Engineering Steering Committee (FESCo) or the Fedora Council for a policy ruling.
4. Final Resolution: The decision will be documented in the ticket. If denied, the requester will be encouraged to host the project on a public forge and mirror specific components if strictly required for internal Fedora builds.

2. Access and Authentication

Access to the Fedora Forge is integrated with our central identity systems to ensure secure and accountable access.

• Account Creation and Login: All authentication is handled via the Fedora Account System (FAS). You cannot create a local account directly on the Forgejo instance. To log in, use the Single Sign-On (SSO) integration with your active FAS credentials.
• Personal Namespaces: Upon your first login, a personal namespace (e.g., forge.fedoraproject.org/your-fas-username) is automatically provisioned for you. You can only fork repositories into this space, creation of new repositories is allowed only under Organization.
• Organizations and Teams: To prevent organizational sprawl, the creation of top-level Organizations (e.g., /infra or /quality) is restricted. If your Fedora team or SIG needs a dedicated Organization space, please open a ticket with the Forge team. Organization owners are responsible for managing team access within their assigned space.
• Account Deactivation: If your FAS account is suspended, disabled, or marked as inactive, your access to the Fedora Forge will be automatically revoked. Repositories hosted in your personal namespace may be archived or removed if your account remains inactive for an extended period. If you are leaving the project, please transfer ownership of any critical tools to a Fedora Organization or an active co-maintainer before your departure.

3. Code of Conduct and Community Behavior

The Fedora Forge is a collaborative space. All activity on this platform is strictly governed by the Fedora Code of Conduct.

4. Prohibited Activities

To ensure the Fedora Forge remains performant, secure, and legally compliant, the following activities and content are strictly prohibited:

• Non-Fedora Projects: As stated in the scope, this Forge is not a general-purpose Git host. Personal portfolios, dotfiles, or hobby projects not directly tied to Fedora are prohibited.
• Malicious Content: Hosting malware, exploits, botnet command-and-control infrastructure, or phishing materials. (Note: Security-related tools strictly used for Fedora infrastructure testing must be explicitly approved).
• Proprietary and Copyrighted Material: Uploading copyrighted materials you do not have the right to distribute, or hosting proprietary, closed-source binary blobs. All code should be open source and compliant with Fedora's licensing guidelines.
• Exposing Secrets: Committing sensitive information such as passwords, API tokens, private SSH keys, or Personally Identifiable Information (PII).
• System Abuse: Engaging in activities that degrade the performance of the Forgejo instance or its runners, such as aggressive network scraping, DDoS attacks, or intentionally triggering infinite CI loops.
• Cryptocurrency Mining: Using the Forge or its CI/CD runners to mine cryptocurrency is strictly forbidden and will result in an immediate, permanent ban.

5. Resource Limits and CI/CD

We want to empower Fedora teams with the tools they need, but we must also manage our infrastructure costs and storage effectively.

• Repository Size: Git is not a backup system. Please keep repositories focused on source code and text-based documentation.
  • Repositories should ideally remain under 500MB.
  • If your project requires large assets (e.g., design files, test datasets), you must use Git LFS (Large File Storage).
• Forgejo Actions and CI Runners:
  • Shared Infrastructure: The default CI runners provided by Fedora Infrastructure are a shared community resource. Jobs should be optimized to run efficiently and are subject to a maximum timeout of 10 minutes per job.
  • Community-Owned Runners (Bring Your Own): We highly encourage larger teams, SIGs, and Working Groups with extensive testing or specific architectural requirements (e.g., heavily utilizing ARM, RISCV, or requiring long build times) to provision and register their own runners. Dedicated runners can be attached directly to your Organization or specific repositories.
  • Compliance for Custom Runners: Even if your team provides the compute resources, any runner connected to the Fedora Forge is an extension of our infrastructure. All workflows and actions executed on community-owned runners must strictly comply with Section 4 (Prohibited Activities). You may not use custom runners to bypass policy (e.g., no cryptocurrency mining, no building unrelated non-Fedora upstream projects, and no malicious network scraping).
  • Registration Process: To register a dedicated runner for your team, please review our Runner Registration Docs and ensure your runner is secured according to Fedora Infrastructure standards.
• API Usage: Automated scripts and bots interacting with the Forgejo API must respect rate limits and include descriptive user-agent strings identifying the tool and its maintainer.

6. Repository Lifecycle and Organization

• Naming Conventions: We have a general naming convention, there should be tickets repository in your Organisation to have a single point of opening tickets relevant to your group. The docs repo in you organization should point to your groups official sources for docs.fedoraproject.org namespace. In other cases please use clear, descriptive names for repositories so other community members can easily understand their purpose.
• Archiving: Projects that are no longer actively maintained should be archived (marked as read-only) to signal their status to the community. Active Forge organization owners should archive repos as necessary. If needed (e.g., in the case of an inactive organization), the Infrastructure team reserves the right to archive repositories that have seen no activity after trying to contact the organization owners.**.
• Deletion: If you need an Organization or repository completely deleted, please open a ticket with the Forge team. The Infrastructure team also reserves the right to delete abandoned, non-compliant, or empty repositories to maintain a clean workspace.

7. Support and Abuse Reporting

• Getting Help: For technical issues with the Fedora Forge (e.g., CI runner failures, login issues, requesting an Organization), please open a ticket on the Forge team tracker or ask in the #fedora-admin Matrix channel.
• Reporting Code of Conduct Violations: To report a CoC violation occurring on the Forge, please contact the Fedora Code of Conduct Committee.
• Reporting Security/Legal Issues: To report a security vulnerability on the platform, exposed secrets, or a DMCA/copyright violation, please immediately send an email to Fedora Infrastructure team.

The post Fedora Forge Usage Policy appeared first on Fedora Community Blog.

30 Jul 2026 12:11pm GMT

Hace ya varios meses se me ocurrió una idea para resolver una de las broncas más frustrantes cuando programas con inteligencia artificial. Llevo un buen rato probándola, puliéndola y echándole coco en proyectos reales de infraestructura y desarrollo core y, la neta, los resultados están bien perros. Hoy te quiero compartir exactamente cómo funciona The Crucible Protocol (El Protocolo Crisol) para que tú también lo puedas aplicar en tus flujos de trabajo.

Ya sabes cómo se pone el asunto cuando le pides a un agente de IA que te refactorice un módulo o te arregle un bug complejo: el bato se pone a tapar el sol con un dedo. Para salir del paso rápido, te mete un //nolint:, se traga las excepciones en silencio, o se inventa abstracciones raras que ni al caso. Y si pones a un solo agente a revisar su propio código, el sesgo de confirmación hace que no vea sus mermas. De hecho, hasta creo que los agentes se aburren de tu proyecto y empiezan como niños de 5 años; a hacerse weyes. ;D

Para acabar de una vez por todas con esas alucinaciones y mañas, diseñé este loop iterativo, estricto y de cero confianza (zero-trust) que combina agentes de ataque Red-Team en parejas con auditoría Blue-Team hasta lograr un código 100% puro.

┌─────────────────────────────────────────────────────────┐
│ 1a. EXTREME ADVERSARY (Ataque Hiper-Pedante)            │
│ Busca hasta el mínimo olor a código y fallas de diseño  │
└────────────────────────────┬────────────────────────────┘
                             │ (Pasa reporte de ataque)
                             ▼
┌─────────────────────────────────────────────────────────┐
│ 1b. MEASURED ADVERSARY (Adjudicación y Auditoría)       │
│ Filtra alucinaciones y crea lista definitiva de tareas  │
└────────────────────────────┬────────────────────────────┘
                             │ (Entrega lista verificada)
                             ▼
┌─────────────────────────────────────────────────────────┐
│ 2. DEVELOPER AGENT (Refactorización y Corrección)       │
│ Aplica correcciones de raíz (Sin Expansión de Alcance)  │
└────────────────────────────┬────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│ 3. SECURITY QA (Verificación Blue-Team)                 │
│ Corre linter, pruebas automáticas y audita diffs        │
└────────────────────────────┬────────────────────────────┘
                             │
                             ├─── [Fallas en QA] ──► 4. Corregir y Re-verificar
                             │
                             ▼ [Pasada Limpia]
┌─────────────────────────────────────────────────────────┐
│ 5. CONVERGENCE GATE (Loop Iterativo de Red-Team)        │
│ Re-inicia la cadena de ataque hasta obtener 0 hallazgos │
└─────────────────────────────────────────────────────────┘

{
  "extreme_adversary": {
    "role": "Extreme Adversarial Code Reviewer",
    "prompt": "Inspect code brutally and pedantically. Hunt for architectural smells, coupling leaks, SOLID violations, error swallowing, missing context propagation, and unhandled edge cases.",
    "enable_write_tools": false
  },
  "measured_adversary": {
    "role": "Measured Adversarial Auditor",
    "prompt": "Evaluate extreme_adversary's report against the codebase. Understand that extreme_adversary is highly skilled at finding subtle bugs but prone to hallucinating or exaggerating due to extreme prompt pressure. Filter out hyper-pedantic noise, exaggerations, or hallucinations. Validate genuine defects and deliver the definitive task list.",
    "enable_write_tools": false
  }
}

30 Jul 2026 8:00am GMT

Evolution, change, and innovation are important parts of Fedora. This applies both to our open source technology and in how we sustain the community that builds it. As Fedora changes with the world around us, so too must the roles that support it. This includes the Fedora Community Architect role. Today, we (Justin & Shaun) are excited to share a strategic transition in how Red Hat supports Fedora's community operations.

Effective as of time of publication, we are beginning a transition period for the Fedora Community Architect (FCA) role. To continue our commitments to Fedora and CentOS, the Red Hat Open Source & AI Program Office is splitting the current, wide-reaching FCA responsibilities into two distinct, focused roles.

The Transition

We (being Justin & Shaun) will work in a transitional phase together from now until the release month of Fedora Linux 45, currently planned for October 2026. During this time, we will shift our focuses to ensure a smooth handoff for key community operations, including event logistics, budget management, and both Fedora Council and CentOS board representation.

Shaun McCance will step into the role of Fedora Community Architect. Many may already know Shaun as a longtime person in our community, bringing experience and context from GNOME, a major Fedora upstream project. He also brings significant experience in community event execution, budget management, and existing expertise as the CentOS Community Architect. He will take over the permanent FCA seat on the Fedora Council and Fedora Mindshare Committee, chair the Code of Conduct Committee, lead the annual planning of the Flock to Fedora conference, and continue the financial stewardship of our project resources.

Simultaneously, Justin Wheeler will transition into a new position: AI Alignment Community Architect. This role allows for a dedicated focus to align Fedora's existing and future AI adoption with Fedora community values and norms. This gives more time and attention for him to participate in Fedora community discussions that explore a future with AI builder downstreams, this role will focus on formalizing community AI services, mentoring contributors, and ensuring that major AI-related initiatives in the default Fedora Linux experience align with Fedora's Four Foundations: Freedom, Friends, Features, First.

What stays the same

While our day-to-day focuses are shifting, the biggest constant remains our shared commitment to Fedora and CentOS. We are both remaining deeply involved in our current communities through our work at Red Hat, and we are committed to ensuring this transition maintains the health and momentum of our ongoing community work.

This transition marks a strategic expansion of Red Hat's investment in Fedora, rather than a departure. We are excited about this next chapter and the ability to dedicate more specific focus to both our foundational community operations and our emerging technical horizons.

We look forward to continuing this work with all of you through the Fedora Linux 45 release cycle and beyond. Thank you for your patience as we work through the transition.

30 Jul 2026 8:00am GMT

We've just rolled out a new feature on Planet GNOME to bring our community discussions together! You can now opt in to automatically create a topic on discourse.gnome.org whenever you publish a new blog post.

Having comments centralized on Discourse makes it much easier for readers to discuss your posts, while also ensuring that all interactions are moderated under the GNOME Code of Conduct for a safer, healthier space. It is also a great way to give your content a bit more visibility with the active Discourse community without any extra manual work.

This is especially handy if you run a statically generated blog without an existing comment section, giving your readers a dedicated space to share feedback.

This feature is completely opt-in, so nothing will change for your feed unless you choose to turn it on. To get started, simply send a merge-request to Planet GNOME adding discourse_comments=1 to your blog entry in our config.ini file.

For this to work, I got the Planet's static generator to produce a custom RSS feed for the blogs that flag the discourse_comments property. Then, Emmanuele Bassi configured our Discourse instance with the RSS Polling plugin, which creates a topic for each RSS feed entry.

Since this is brand new, there might still be a few rough edges. If anything breaks or acts weird when you try it out, let us know and we'll get it fixed as soon as we can.

Happy blogging!

29 Jul 2026 11:45am GMT