Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It's excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to rebase to Fedora Linux 43 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.

Update your existing system

Prior to actually doing the rebase to Fedora Linux 43, you should apply any pending updates. Enter the following in the terminal:

$ rpm-ostree update

or install updates through GNOME Software and reboot.

Note

rpm-ostree is the underlying atomic technology that all the Fedora Atomic Desktops use. The techniques described here for Silverblue will apply to all of them with proper modifications for the appropriate desktop.

Rebasing using GNOME Software

GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.

First thing to do is download the new image, so select the Download button. This will take some time. When it is done you will see that the update is ready to install.

Select the Restart & Upgrade button. This step will take only a few moments and the computer will restart when the update has completed. After the restart you will end up in a new and shiny release of Fedora Linux 43. Easy, isn't it?

Rebasing using terminal

If you prefer to do everything in a terminal, then this part of the guide is for you.

Rebasing to Fedora Linux 43 using the terminal is easy. First, check if the 43 branch is available:

$ ostree remote refs fedora

You should see the following in the output:

fedora:fedora/43/x86_64/silverblue

If you want to pin the current deployment (meaning that this deployment will stay as an option in GRUB until you remove it), you can do this by running this command:

# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0

To remove the pinned deployment use the following command:

# 2 is entry position in rpm-ostree status 
$ sudo ostree admin pin --unpin 2

Next, rebase your system to the Fedora Linux 43 branch.

$ rpm-ostree rebase fedora:fedora/43/x86_64/silverblue

Finally, the last thing to do is restart your computer and boot to Fedora Linux 43.

How to roll back

If anything bad happens (for instance, if you can't boot to Fedora Linux 43 at all) it's easy to go back. At boot time, pick the entry in the GRUB menu for the version prior to Fedora Linux 43 and your system will start in that previous version rather than Fedora Linux 43. If you don't see the GRUB menu, try to press ESC during boot. To make the change to the previous version permanent, use the following command:

$ rpm-ostree rollback

That's it. Now you know how to rebase Fedora Silverblue to Fedora Linux 43 and roll back. So why not do it today?

Known Issues

• PAM Lastlog change crashing gdm

FAQ

Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.

Question: Can I skip versions during rebase of Fedora? For example from Fedora 40 Silverblue to Fedora 43 Silverblue?

Answer: Although it could sometimes be possible to skip versions during rebase, it is not recommended. You should always update to one version above (40->41->42->43 for example) to avoid unnecessary errors.

Question: I have rpm-fusion layered and I get errors during rebase. How should I do the rebase?

Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:

$ rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release

After doing this you can follow the guide in this blog post.

Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?

Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/43/x86_64/kinoite

28 Oct 2025 1:56pm GMT

I'm excited to announce my very first Fedora Linux release as the new Fedora Project Leader. Fedora Linux 43 is here! 43 releases! Wow that's a lot. I was thinking about proposing special tetracontakaitrigon stickers to celebrate this release, but I'm not sure anyone would notice they weren't circles.

Thank you and congrats to everyone who has contributed to Fedora to this release, and in all the releases leading up to this one. I'm grateful to be back with a chance to take stewardship of the collaboration as the Fedora Project leader. I've been getting my feet under me as much as I can in these first few months. I'm looking forward to writing up some longer missives about where I want to steer this ship, but for right now I just want to highlight some of the changes you should expect to encounter in the latest release of Fedora Linux. Read the highlights below to find out more. Or if you are ready just jump right in!

Upgrade

If you have an existing system, Upgrading Fedora Linux to a New Release is easy. In most cases, it's not very different from just rebooting for regular updates, except you'll have a little more time to grab a coffee.

Fresh Install

If this is your first time running Fedora Linux, or if you just want to start fresh with Fedora, download the install media for our flagship Editions (Workstation, KDE Plasma Desktop, Cloud, Server, CoreOS, IoT), for one of our Atomic Desktops (Silverblue, Kinoite, Cosmic, Budgie, Sway), or for alternate desktop options (like Cinnamon, Xfce, Sway, or others).

What's new?

As usual, with Fedora, there are just too many individual changes and improvements to go over in detail. You'll want to take a look at the release notes for that.

Notable User Visible Changes

There are, however, a few notable user visible changes in this release. For those of you installing fresh Fedora Linux 43 Spins, you may be greeted with the new Anaconda WebUI. This was the default installer interface for Fedora Workstation 42, and now it's the default installer UI for the Spins as well.

If you are a GNOME desktop user, you'll also notice that the GNOME is now Wayland-only in Fedora Linux 43. GNOME upstream has deprecated X11 support, and has disabled it as a compile time default in GNOME 49. Upstream GNOME plans to fully remove X11 support in GNOME 50.

Plumbing Upgrades

Beyond the user-visible changes, there are a couple of significant bits of plumbing that should go unnoticed for most users but are a big deal, nonetheless.

Fedora Linux 43 will be the first release with RPM 6.0. Like I said, this should go unnoticed to end-users, but it is a significant change. RPM 6.0 provides some interesting security enhancements, like multiple key signing of packages. This should help future-proof package signing as we transition to post-quantum-crypto OpenPGP keys in future releases.

We're also moving forward with our bootc enablement story. Fedora CoreOS is now buildable from a Fedora base bootc image using a Containerfile, instead of needing to be composed with a custom tool. That means anyone with podman can build the Fedora CoreOS image, whether manually or via CI/CD automation.

Fedora CoreOS (FCOS) is also changing how it's issuing updates to users in Fedora 43. Instead of using an OSTree repository, FCOS updates will be delivered exclusively as OCI images. FCOS 42 provided both OSTree repository and OCI registry as a transition for users. In FCOS 43, the OSTree updates are disabled entirely.

Save the Date: Fedora Linux 43 Release Party!

To celebrate all this incredible community work, we'll be hosting a virtual Fedora Linux 43 Release Party! Please save the date for Friday, 21 November. We're still finalizing the schedule and speakers, so registration isn't open just yet, but more details will be shared soon. You can keep an eye on the Fedora Linux 43 Release Party Schedule wiki page for the latest updates!

If you hit a snag

If you run into a problem, visit our Ask Fedora user support forum. This forum includes a category where we collect common issues and solutions or work-arounds.

Just drop by and say "hello"

Drop by our "virtual watercooler" on Fedora Discussion and join a conversation, share something interesting, and introduce yourself. We're always glad to see new people!

28 Oct 2025 1:56pm GMT

Below are a few noteworthy changes in the latest release of Fedora Workstation that we think you will love. Upgrade today from the official website, or upgrade your existing install using GNOME Software or through the terminal with dnf system-upgrade.

GNOME 49

Fedora Linux 43 Workstation also ships with the brand-new GNOME 49 release, bringing a host of refinements to your desktop. This update introduces significant enhancements for multiple display setups, an improved and streamlined workflow for taking screenshots and screen recordings, and a new "Focus Mode" to help you minimize distractions. Under the hood, resource-smart background throttling improves performance and battery life, while the Settings app has been polished with a refined UI. These are just the highlights. Check out the official GNOME 49 release notes to find more information about all the new features.

Wayland-only GNOME

One significant change we want to forewarn you about is that Fedora Linux 43 is removing the GNOME X11 packages from the Fedora repositories. All users of the GNOME X11 session will be migrated to the GNOME Wayland session with the upgrade to Fedora Workstation 43.

The transition to the GNOME Wayland session in Fedora Workstation 43 has been in the works for nearly a decade. There have been several prior steps toward this goal, such as the work in Fedora Linux 41 to remove legacy X11 dependencies from core media components.

Wayland has been the default GNOME session on Fedora Workstation for many years, but this release completes the change. The legacy gnome-session-xsession packages have been removed from the Fedora Linux 43 repositories.

This change will unlock a new level of performance and hardware compatibility. You'll immediately notice smoother, cleaner visuals thanks to triple buffering, which dramatically reduces screen tearing. This change also improves support for a range of hardware, including enhanced drivers for Intel Xe graphics and improvements for systems using NVIDIA Optimus and Hybrid Mode.

A new default video player - Showtime

The default video player has been changed from Totem to Showtime. Showtime is built on the newer GTK 4 and Libadwaita libraries.

Use COLR for Noto Color Emoji

The Noto Color Emoji fonts have released some new files with the COLRv1 format. The COLRv1 format is a color scalable font compared with the previous color bitmap fonts. This new scalable font format should have better or similar rendering results compared to the old bitmap font format. See the change notes for more details.

Peas 2.0

If you are an app developer, you might be interested in the upgrade to Peas 2. Peas is a gobject-based plugins engine that is used by several GNOME applications.

Wrap-up

Be sure to check out the Fedora Linux 43 Change Set wiki for even more details about all the features and changes that went into Fedora Linux 43. Use the Fedora Discussion forum or Fedora's Matrix chat server if you want to converse with the Fedora community about this new release!

28 Oct 2025 1:56pm GMT

Fedora Linux 43 has been released! So, let's see what is included in this new release for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).

Changes for all variants

zstd compressed initrds

Alongside the rest of Fedora, we are now compressing our initrds with the Zstandard (zstd) algorithm. This should make the initrd a bit smaller and the boot a bit faster.

See the Fedora Change request and the tracking issue atomic-desktops-sig#34.

2 GB boot partition

Along with the rest of Fedora, systems will install with a 2GB /boot partition. This should make things easier with the growing initrd sizes (mostly due to firmwares). Existing systems will require a backup and re-install to benefit from this change.

See the Fedora Change request.

wireguard-tools added

We are adding the wireguard-tools to all variants. Users will still need to use the graphic interface in their desktop environment to configure WireGuard connections. However, it should now be easier to debug issues using the wg tool. This change was decided too late to be included in the installation ISO but it will come via an update.

See silverblue#390 and kde-sig#381.

plocate removed

We removed plocate from all variants.

See atomic-desktops-sig#81.

What's new in Silverblue

GNOME 49

Fedora Silverblue comes with the latest GNOME 49 release.

For more details about the changes that alongside GNOME 48, see What's new in Fedora Workstation 43 on the Fedora Magazine.

Workaround for Third Party page hang

We temporarily removed the Third Party page shown during the first boot as it was causing issues. Users will be asked if they want to enable Third Party repositories when they open GNOME Software.

This will be re-enabled once we figure out where the bug is.

See silverblue#650 and atomic-desktops-sig#74.

openssl added for GSConnect

We added the openssl command line tool to Silverblue, to make the GSConnect extension work without having to resort to package layering or sysexts.

See silverblue#201.

What's new in Kinoite

KDE Plasma 6.4

Fedora Kinoite ships with Plasma 6.4, Frameworks 6.18 and Gear 25.08.

See also What's New in Fedora KDE Plasma Desktop 43? on the Fedora Magazine.

Weekly automatic updates by default

Updates will now be automatically applied on a weekly basis, for Flatpaks and the system. You can configure the frequency or disable auto-updates in the system settings.

See the Fedora Change request and the tracking issue kde-sig#342.

What's new in Sway Atomic

Fedora Sway Atomic comes with the latest 1.11 Sway release.

What's new in Budgie Atomic

Fedora Budgie Atomic comes with the latest 10.9.3 Budgie release. Budgie 10.9.3 is a bug-fix and GNOME 49 compatibility release.

What's new in COSMIC Atomic

Fedora COSMIC Atomic comes with the latest beta release of the COSMIC desktop.

Changes in unofficial images

XFCE Atomic & LXQt Atomic dropped in Fedora 43

Starting with Fedora 43, we will no longer build XFCE Atomic & LXQt Atomic unofficial images.

Universal Blue, Bluefin, Bazzite and Aurora

Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora 43. Look for upcoming announcements in their Discourse.

As always, I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra media codec, out of tree kernel drivers, etc.).

What's next

Roadmap to Bootable Containers

The next major evolution for the Atomic Desktops will be to transition to Bootable Containers. See also the Fedora bootc documentation.

We have established a roadmap (atomic-desktops-sig#26) and we need your help to make this a smooth transition for all of our existing users.

New home for the Fedora sysexts

We have moved the systemd system extensions (sysexts) to a new GitHub organization. The sysexts are now split between those built exclusively from Fedora packages and those built from various community sources. Make sure to update your systemd-sysupdate configs to point to the new URLs.

Moving to Fedora's new Forge based on Forgejo

Now that Fedora's new forge is available, we will start moving our repos there. You can find the new organization at forge.fedoraproject.org/atomic-desktops. We will likely start by moving the documentation and then issue tracker and the sources.

Where to reach us

We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.

• Atomic Desktops SIG: New Fedora Forge organization, Issue tracker (gitlab.com/fedora/ostree/sig), #atomic-desktops:fedoraproject.org
• Silverblue: Workstation Working Group, #silverblue:fedoraproject.org
• Kinoite: KDE SIG, #kinoite:fedoraproject.org
• Sway Atomic: Sway SIG, #sway:fedoraproject.org
• Budgie Atomic: Budgie SIG, #budgie:fedoraproject.org
• COSMIC Atomic: COSMIC SIG, #cosmic:fedoraproject.org

28 Oct 2025 1:55pm GMT

Fedora has released Fedora KDE Plasma Desktop Edition 43 to the public.

The Fedora KDE Plasma Desktop Edition is well suited for many needs. It combines the reliable and trusted Fedora Linux base with the KDE Plasma Desktop environment. It provides a selection of KDE applications that are simple by default, but powerful when needed.

KDE Plasma 6.4

KDE developers continue to release new features, fix bugs and fine-tune the desktop experience to improve on the now well-established foundation of Plasma 6.

Fedora KDE 43 ships with Plasma 6.4.5 featuring:

• More flexible tiling. You are able to choose a different tile layout for each of your virtual desktops.
• New Spectacle. Spectacle, Plasma's screenshot tool, got a complete overhaul.
• Color Management. The Display and Monitor page in System settings comes with a brand new HDR calibration wizard.
• Accessibility. You can now move the pointer using your keyboard's number pad keys, or use a three-finger touchpad pinch gesture to zoom in or out.
• Notifications. When any applications are in full screen mode, Plasma will enter Do Not Disturb mode and only show urgent notifications. When you exit full screen mode, you'll see a summary of any notifications you missed, and they'll be right there in the System Tray for your perusal.
• Apps. The Application Launcher will place a green New! tag next to newly installed apps, so you can easily find where something you just installed lives in the menu.
• Many other bugfixes, improvements and features that can be found in the Plasma 6.4 release announcement.

Fedora KDE 43 specific updates

Beyond the updates to KDE Plasma 6.4, there are some Fedora KDE updates that have happened with Fedora Linux 43.

• The new Anaconda Installer UI is being used in the Fedora KDE Desktop image. This brings a fresh, modern look to the installation process.
• Fedora Kinoite now does automatic updates by default. Users have the option of disabling or tuning the frequency that auto-updates happen.

Fedora Linux 43 general updates

Some of the key updates occurred in the core components of Fedora Linux 43, which directly impact the KDE Plasma Desktop Edition, include:

• New installs now have a 2 GiB /boot partition
• Faster startup with zstd compressed initrds
• Noto Color Emoji now have scalable colorful emoji

Wrap-up

The Fedora KDE SIG hopes that you'll find the Fedora KDE Plasma Desktop 43 to be a wonderful experience. When you're ready to try it, click here for download links and verification instructions. If you'd like to learn more, check out the Fedora KDE Plasma Desktop website.

27 Oct 2025 7:39pm GMT

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 20th - 24th October 2025

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It's responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues

Fedora Infra

• increasing koschei failures due to kojipkgs0X.fedoraproject.org being unavailable
• src.fedoraproject.org is often unavailable
• db01.rdu3.fedoraproject.org timeout (postgresql?) when running git push to my rpms/haruna fork
• Archive openarm_can package
• need to have respins01.fedorainfracloud.org rebooted please
• Requesting merge access to https://pagure.io/fedora-infra/ansible for Jiri Podivin
• Error when attempting to set the bugzilla assignee from src.fp.o pagure
• 502/503 when reaching https://koji.fedoraproject.org/kojihub/
• Please remove file from lookaside cache
• Planned Outage - ibiblio vlan move - 2025-10-13 21:00 UTC
• CentOS Stream crb-source repo has a checksum error
• Opt-in for AWS region to ap-southeast-6 acct:125523088429
• Update standupbot to used Done and Planned
• [Forgejo] Create a Fedora Docs organization on Forgejo
• Create a Fedora Atomic Desktops organization on Forgejo
• Help me move my discourse bots to production?
• Move from iptables to nftables (was firewalld)
• Move ibiblio machines to new vlan

CentOS Infra including CentOS CI

• Validate RDU3 Netapp NFS storage
• CBS permissions for centos-release-ovirt45 in extra's
• Add fedora-messaging TLS client validity check in zabbix
• Stream repositories in CBS seem to be out of date
• Automotive SIG gpg key update?
• Reinstall IBM Power 10 in LPAR mode

Release Engineering

• Block python-atomicwrites in F43
• Freeze Exception: Upgrade Koji builders to image-builder-39-1.fc42
• fedora-scm-requests for rpms/perl-Net-IDN-PP failed: Remote end closed connection without response
• Unretire pysubnettree
• Please remove gnome-sig commit access from krb5-auth-dialog
• "initial_commit": false not respected in fedora-scm-requests
• Some packages retired in dist-git not getting blocked in koji
• Create detached signatures for the ignition 2.24.0 release
• Release Management Support Request - F44
• Create Fedora 43 Final candidates
• Assign systemd package to zbyszek
• Change impact: Python 3.15 (Fedora 45)
• Retired package rust-rstest0.23 not blocked in F43, Rawhide
• F44 System-Wide Change: Switch Fedora Cloud to /boot as a Btrfs subvolume
• Please make el10-openjdk to follow 10.2 or - better- some rolling el10
• Update pungi filters

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

The post Infra and RelEng Update - Week 43 2025 appeared first on Fedora Community Blog.

24 Oct 2025 10:00am GMT

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

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

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ There is no security fix this month, so no update for versions 8.1.33 and 8.2.29.

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

Version announcements:

• PHP 8.4.14 Release Annoucement
• PHP 8.3.27 Release Annoucement

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

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

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

Parallel installation of version 8.4 as Software Collection

yum install php84

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

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

Parallel installation of version 8.3 as Software Collection

yum install php83

And soon in the official updates:

• Fedora Rawhide now has PHP version 8.5.0RC3
• Fedora 43 - PHP 8.4.14
• Fedora 42 - PHP 8.4.14
• Fedora 41 - PHP 8.3.27

⚠️ To be noticed :

• EL-10 RPMs are built using RHEL-10.0
• EL-9 RPMs are built using RHEL-9.6
• 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.8 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

Base packages (php)

Software Collections (php83 / php84)

24 Oct 2025 4:51am GMT

SSCG 4.0.0 Release Announcement

We are excited to announce the release of SSCG 4.0.0! This major release brings significant new features, modernization improvements, and important breaking changes.

Highlights

Post-Quantum Cryptography Support

SSCG now supports ML-DSA (Module-Lattice-Based Digital Signature Algorithm) key generation, bringing post-quantum cryptography capabilities to the tool. This ensures future-readiness against quantum computing threats.

ECDSA Key Support

In addition, SSCG now supports ECDSA (Elliptic Curve Digital Signature Algorithm) key generation, providing modern cryptographic options with smaller key sizes and improved performance.

Enhanced Command-Line Interface

The help output has been completely reorganized into logical groups, making it significantly easier to discover and use the various options available.

New Features

• ML-DSA Key Generation: Generate post-quantum cryptographic keys with OpenSSL 3.5+
  • New command-line arguments for ML-DSA configuration
  • Proper handling of ML-DSA signing semantics (digest-less operation)
• ECDSA Key Generation: Generate elliptic curve keys
  • Support for various EC curves
  • Enhanced CLI arguments for EC-DSA configuration
• Enhanced Security: Minimum RSA key strength for private CA raised to 4096 bits (matches service certificate if set higher)

Internal Improvements

• Refactored Key Creation: Separated key creation logic from certificate creation for better modularity and multi-algorithm support
• Enhanced Testing:
  • Separate validity tests for RSA, ECDSA, and ML-DSA certificates
  • Extended test coverage for CA and certificate creation with new key types
• Improved Code Organization: Logging functionality split into its own header and implementation files
• Better Code Formatting: Updated clang-format configuration for improved consistency

Breaking Changes

DH Parameters Changes

• No longer generates DH parameters file by default (Fixes #91)
  • DH parameters were always generated by default for backwards compatibility, but this was never the desired behavior
  • Use the --dhparams-file argument if you explicitly need DH parameters
• Custom DH parameter generation deprecated (Fixes #88)
  • --dhparams-prime-len argument still works for now but it is hidden from the documentation
  • This option will be removed in SSCG 5.0

Removed Options

• Dropped --package argument: This option was deprecated in SSCG 3.0 and has been completely removed in 4.0 as it has been meaningless for years

Build Requirements

• Minimum OpenSSL version: 3.x: Dropped compatibility with OpenSSL 1.1 and 2.x
• Updated C standard: Now requires C standard support of C17 + GNU extensions (gcc 11+, clang 6+)
• Removed pkgconfig dependency: Unused dependency has been dropped

Bug Fixes

• Fixed NULL pointer dereference issues in tests (Coverity #1648023)
• Fixed formatting issues throughout the codebase
• Various code quality improvements

Infrastructure

• CI now tests on Fedora ELN in addition to other platforms
• CI runs are no longer restricted to the main branch
• Updated GitHub Actions checkout action to v5
• Build and test processes improved for container environments

Requirements

• OpenSSL 3.x or later
• C compiler with C17 + GNU extensions standard support
• Meson build system

Getting SSCG 4.0.0

Source tarballs and additional information are available at:

• GitHub: https://github.com/sgallagher/sscg
• Releases: https://github.com/sgallagher/sscg/releases/tag/sscg-4.0.0

For bug reports and feature requests, please visit our issue tracker.

For information on contributing to SSCG, please see our CONTRIBUTING.md guide.

Full Changelog: sscg-3.0.8…sscg-4.0.0

23 Oct 2025 2:47pm GMT

23 Oct 2025 12:53pm GMT

23 Oct 2025 12:51pm GMT

23 Oct 2025 12:51pm GMT

23 Oct 2025 12:50pm GMT

23 Oct 2025 12:49pm GMT

We in the CLE team and wider Fedora infra space have been talking about the future of Fedora's development infrastructure for a while. Now it is starting to take shape, as Ryan outlined in the soft launch blog post: Both staging and production Forgejo instances are up and running in the RDU3 datacenter. That means the work of moving away from pagure.io is no longer theoretical. It is happening.

If you have a project on Pagure, you can already open a migration ticket, as described in the Forge documentation, and we will help you move it over. But this is not just about swapping one forge for another. Forgejo gives us a chance to modernize some of the core parts of Fedora's packaging workflows, such as how we handle ownership, where we store artifacts, and how we integrate automation.

Let us take a closer look.

Automation, Actions, and CI

One of the first questions we hear is: What about CI/CD?

Forgejo upstream recommends Woodpecker/Raven, which are full CI/CD systems. These are powerful, but they are also heavy and expensive to maintain. Fedora is going to take a different approach.

We are focusing on Forgejo Actions, which are somehow API compatible with GitHub Actions(It is not a 1:1 replacement).

This allows contributors to:

• Automate ticket and pull request workflows
  
• Run small repo-local tasks such as linting, simple checks, or doc generation.
  
• Trigger jobs in external services like COPR or Jenkins
  

For those who want to run heavy workloads, such as large test suites or extensive CI pipelines. You can connect your own self-hosted runners, while the shared Fedora infrastructure will stay lightweight, stable, and dependable. The CLE team won't provide resources within Fedora's Forgejo infrastructure.

Rethinking Dist-Git

There was an engaging discussion about dist-git at this year's Flock, and one message came through clearly: as we move forward, we should take the opportunity to improve the model rather than simply replicate it. The conversation focused on three key areas: package ownership, artifact storage, and Packit integration.

Modernizing Access Control and Contribution Workflows

A central theme of our discussion was how we manage permissions and contributions in a way that is both secure and efficient. The goal is to leverage Forgejo's powerful features to refine our processes.

Key takeaways include:

• A Shift to Merge Requests: There is strong momentum to make Merge Requests (MRs) the default contribution method for everyone. This "review-first" approach ensures that all changes to our packages benefit from peer review, improving code quality and stability.

• Redefining the "Proven Packager" Role: We recognize the immense value and trust placed in our Proven Packagers. Instead of a direct-push model, we are exploring how this role can evolve within a merge-request workflow. A formal policy proposal for this is already being drafted.

• Hardening Our Security: There was a unanimous agreement to enforce "hard rules" against rewriting git history. Force pushes to primary branches will be disabled across the board to protect the integrity of our repositories.

• Granular Permissions: Forgejo will allow us to set fine-grained permissions for different actions. We plan to separate the ability to change package content from the ability to change repository configuration, adding another layer of security.

Right now, all Fedora packages officially belong to the Fedora Project, but the daily reality is a patchwork of individual maintainers and teams. This works, but it leaves gaps.

• Permissions are all or nothing. You either have commit rights or you do not.
  
• It is not always clear who is responsible for a package at any given time.
  
• Onboarding new maintainers or transferring ownership when someone steps back is often manual and slow.
  
• Critical packages such as toolchains affect the whole distribution, but our ownership model does not reflect that impact.
  

Forgejo lets us improve this. With its more flexible permissions, we can introduce roles such as maintainer, co-maintainer, or limited contributor. Groups can own packages as first-class entities.

Artifact storage

Today, the package build process relies on the Lookaside Cache. It is simple, but it is also dated. It struggles with very large artifacts, it separates code and artifacts, and it does not integrate well with modern workflows.

Several options are on the table:

• Using git lfs: An industry-standard solution for storing large files in Git. While it integrates cleanly with Forgejo, it's not compatible with mirroring infrastructure.
• Leveraging Forgejo's Package Registry: We could repurpose Forgejo's built-in registry to store source tarballs. While it sounds wonderful to solve all the problems with one tool. We would be misusing the feature and need to maintain compatibility.
• A Radically Simpler Approach: Some suggested moving away from a separate cache entirely, embracing a "source git" model where we work directly with forks of upstream projects.

This is a complex decision with long-term implications. No decision has been made yet. We are committed to a transparent process and will submit a formal Change Proposal to the Fedora Engineering Steering Committee (FESCo) before any major architectural change is implemented, ensuring the entire community can weigh in.

Packit integration

Packit is essential for connecting upstream projects to Fedora packaging. It automates updates, tests, and workflows that save maintainers huge amounts of time.

On Pagure, Packit integration was always custom. On GitHub and GitLab, it is native. This gap created extra work and sometimes rougher edges for Fedora contributors.

The Packit team already prototyped Forgejo support during Google Summer of Code. The service is called Avant, and it's in our sights as one of the first integration testing areas in staging deployment.

The next steps are:

• Deploy Forgejo in staging and provide Packit with a service account
  
• Collect feedback from maintainers on real workflows.
  
• Reach feature parity with GitHub and GitLab support.

The long-term goal is clear. Packit in Forgejo should feel natural and seamless, not bolted on.

Konflux Integration

Some of Fedora's container builds run through Konflux. Right now, Konflux only supports GitHub and GitLab. To make it work with Forgejo, we built a workaround that mirrors repositories into GitHub. It works, but it is fragile and wasteful.

The better solution is native Forgejo integration. That means upstream changes in Konflux, secure authentication, and removing the mirroring step entirely. Until then, the GitHub workaround will stay in place, but long-term, the focus is on a direct, reliable path.

Building a Compatibility Bridge

A migration like this cannot happen overnight. We need to keep workflows running while the move happens. To do this, we are building a compatibility bridge.

The bridge includes:

• A metaservice that translates Pagure-style API calls into Forgejo's API
  
• New artifact storage, currently in the Lookaside Cache
  
• A phased rollout: first internal scripts, then external tools, and finally contributor-facing workflows
  
• Incremental testing in staging before production cutovers

The goal is continuity. Contributors should be able to keep working while the infrastructure gradually changes behind the scenes.

Tooling Compatibility

Fedora's ecosystem depends on many tools that integrate with dist-git. Each needs some level of adjustment.

• Bodhi will need to adapt to the new repository metadata.
  
• COPR will need changes to fetch SRPMs directly from Forgejo
  
• Packit integration is a priority and is being developed in parallel.
  
• Fedpkg and release engineering scripts will be updated first since they are under Fedora control.
  
• CI systems, Anitya, Toddlers, Notifications, Monitor Gating, and others will need targeted updates to remove assumptions about Pagure.

The approach is simple. During the transition, a compatibility layer keeps these tools running. Once Forgejo support is mature, the tools can be updated to use Forgejo directly.

What is Next

This migration is not just an infrastructure swap. It is a chance to fix long-standing pain points, simplify workflows, and make Fedora's packaging system stronger for the future.

By the end of the Year, I expect us to be able to:

• Have runners and actions in production
• Move about 80% of non-source projects to forge.fp.o

Nice to have:

• Some outcomes from Package ownership and Artifact storage discussions
• Staging deployment of Forgejo, let's temporarily call it "packagers' forge"
• Staging environments for Packit and Actions of the packagers' forge deployment
• Roadmaps for Konflux and the compatibility bridge

Fedora thrives on collaboration. Forgejo is our next step toward a modern, maintainable, and community-driven development platform.

Join us in shaping it together, try the staging environment, file migration ticket, and share your feedback in our matrix channel for ideas and discussion, use the git-forge-future tag.

The post Forging Fedora's Future with Forgejo appeared first on Fedora Community Blog.

21 Oct 2025 10:00am GMT

19 Oct 2025 9:57am GMT

19 Oct 2025 12:00am GMT