Finally migrating the Fedora Cloud SIG from Pagure to Forgejo

2026-05-31T14:00:00-05:00

I finally migrated the Fedora Cloud SIG from pagure.io ([pagure]) to forge.fedoraproject.org ([forge.fp.o]). Neal Gompa (Conan_Kudo to many of you) basically told me that we were pushing up against the deadline and we needed to get it done. So I got it done.

The deadline isn’t soft. The Community Linux Engineering team’s March 24th announcement was explicit: “If you own a project at pagure.io, you must migrate out of it before June 2026.” Final cutover happens at Flock to Fedora 2026 in Prague, June 14–16. After that, pagure.io becomes a read-only archive. By Fedora 46 in 2027, the rest of the Pagure infrastructure, including src.fedoraproject.org, follows. The Cloud SIG’s piece of that (making sure new issues, mentions, and contributors land at forge.fp.o instead of pagure) finished the day before the deadline.

This isn’t a modernization story. The Cloud SIG had been doing its work in pagure for years, including my own attempts to push pagure toward a Software-as-a-Service shape, which I still think is a viable direction. The move to forge.fp.o is about Fedora consolidating its forges, not about pagure being inadequate. With that said, here’s where the SIG works now:

The issue tracker is now cloud/cloud-sig on forge.fp.o.
Meetings moved from IRC (#fedora-meeting-1 on Libera.Chat) to Matrix at #meeting-1:fedoraproject.org.
The cloud@lists.fedoraproject.org mailing list quietly gave way to Fedora Discussion for community conversation, with cloud-wg as the working-group tag for meeting summaries and housekeeping.

None of those moves were dramatic on their own. Each was incremental and well-reasoned. But until the README, the document every new contributor reads first, actually reflected where the SIG works now, the migration was incomplete. Just half-done, in a way that made onboarding harder than either of the possible end-states.

What was broken

The README still read as if the SIG lived on pagure:

The communications-channels list led with the IRC channel as a primary entry.
The meetings section routed people to #fedora-meeting-1 on Libera.Chat.
Every URL pointed at pagure: the issue tracker, the meeting-label query, the link to the meeting-people.txt source file.
All the meetbot commands used the IRC convention (#startmeeting, #topic, #chair, #action, #endmeeting). The Matrix meetbot the Cloud SIG runs takes a ! prefix.
The ping instruction said “Ping the meeting people in #fedora-cloud on Libera.Chat.” Matrix calls those mentions, not pings, and the notification model is per-user rather than channel-wide.

The pattern underneath: the meeting-people.txt file already contained Matrix @user:server handles sitting alongside the older IRC nicknames. The data file had partially modernized; the prose around it had not.

What I changed

A four-commit branch on my fork at davdunc:update-readme-meeting-workflow, ready for upstream review. One commit per kind of drift (URLs, channels, bot syntax, idiom), so the diff stays readable. The deprecated surfaces (the mailing list, IRC) stay listed, just clearly labeled as such, rather than ripped out wholesale.

Still pending

Two items I deliberately left for follow-ups:

The bash meeting-people.txt ping mechanism still embeds an IRC-flavored room name in its echo line. That belongs in its own commit so the README change can land independently.
A workflow visualization for the meeting flow. I drafted one in Graphviz and the layout fought me hard enough that I dropped it for now. I’ll pick it back up at a single-screen overview rather than the multi-phase diagram I tried first.

Why it matters

A README is a contract with new contributors. When it tells them the tracker is on pagure and the meeting is on IRC, they spend their first hour debugging the documentation rather than doing the work. Documentation drift is a silent tax on community contribution.

For the Cloud SIG specifically, and for my goal of growing the contributor base, getting the on-ramp accurate is worth the unglamorous afternoon. The actual work of the SIG hasn’t changed: cloud images, bootable containers, image defaults, release coordination. The infrastructure around it has. The README should reflect what’s actually happening now, not what was happening four years ago.

Thanks to Neal for the nudge.

A simple way to install the Amazon AWSCLI on RHEL 7 on-demand instances

2019-11-05T00:00:00-06:00

A simple way to install the Amazon AWSCLI on RHEL 7 on-demand instances

When working with RHEL 7 instances, you might encounter the message “pip is not supported for system python on RHEL” when trying to install the AWS CLI. Here’s a simple solution.

The Problem

RHEL 7 restricts the use of pip with the system Python installation to prevent conflicts with system packages. This can be frustrating when you need to install tools like the AWS CLI.

The Solution

The easiest approach is to use the AWS CLI installer bundle or install it in a virtual environment:

Method 1: Using the AWS CLI Installer Bundle

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

Method 2: Using a Virtual Environment

python3 -m venv aws-cli-env
source aws-cli-env/bin/activate
pip install awscli

Method 3: Using the EPEL Repository

sudo yum install epel-release
sudo yum install python-pip
pip install --user awscli

Verification

After installation, verify the AWS CLI is working:

aws --version

This approach ensures you have a working AWS CLI installation without conflicting with the system Python packages on RHEL 7.

David Duncan's Personal Blog - platform

Finally migrating the Fedora Cloud SIG from Pagure to Forgejo

What was broken

What I changed

Still pending

Why it matters

A simple way to install the Amazon AWSCLI on RHEL 7 on-demand instances

A simple way to install the Amazon AWSCLI on RHEL 7 on-demand instances

The Problem

The Solution

Method 1: Using the AWS CLI Installer Bundle

Method 2: Using a Virtual Environment

Method 3: Using the EPEL Repository

Verification