The updates-testing repository, also referred to as Test Updates, contains updates scheduled to be released for Branched pre-releases (after the Bodhi enabling point) and stable releases of Fedora. User testing and feedback provided via Bodhi, on the test mailing list and the relevant Bugzilla is vital to ensure that good updates are released quickly and bad ones kept away from release.
Using the updates-testing repository
Enabling the repository permanently
Using dnf on Fedora 41 or later:
sudo dnf config-manager setopt updates-testing.enabled=true
Use dnf repolist
to verify. To disable the repository again:
sudo dnf config-manager setopt updates-testing.enabled=false
Note that the dnf config-manager
command is available as part of the
package and should be installed by default.
dnf5-plugins
Enabling the repository temporarily
If you'd rather not enable the updates-testing repository permanently but just use them on a case-by-case basis, you can do this with dnf
. On Fedora 41 or later, use the command:
sudo dnf update --enablerepo=updates-testing
will update the entire system using packages from the updates-testing repository, while the command:
sudo dnf install FOO --enablerepo=updates-testing
will install or update only the package named FOO from the updates-testing repository.
Testing updates for EPEL with CentOS or RHEL
CentOS and RHEL (Until version 8) used yum instead of DNF, but the basic procedure for installing a particular test update for EPEL is similar:
sudo yum install FOO --enablerepo=epel-testing
will install or update only the package named FOO from the epel-testing repository.
Using it with Fedora Silverblue (Kinoite, Sericea...)
sudo rpm-ostree rebase fedora/32/x86_64/testing/silverblue
Going back to stable:
sudo rpm-ostree rebase fedora/32/x86_64/silverblue
This affects the core Silverblue image itself. For testing updates to Flatpaks, see below. For other immutable variants, change 'silverblue' to 'kinoite', 'sericea' etc.
Testing updates for Fedora Flatpaks
To enable the testing remote:
flatpak remote-modify --enable fedora-testing
To switch to the build of a specific Flatpak from the fedora-testing remote:
flatpak install fedora-testing <org.foo.Bar> --reinstall
Replace <org.foo.Bar> with the correct name.
Using it with Fedora CoreOS
Fedora CoreOS offers a few update streams, but none of those directly follow the Fedora Bodhi Updates/Updates Testing repository. Please follow the testing
stream in Fedora CoreOS to preview what is coming to the next stable
stream release.
What to test, testing, and reporting results
The Bodhi system is used to track and collate feedback on testing updates. All testing updates will be shown in the Bodhi system. The update feedback guidelines explain what feedback you should leave in what situations, based on your testing of the package.
In the web interface, each Works for me adds 1 to the test update's karma, while each Does not work subtracts 1 from it. Untested leaves the karma unchanged. Other tools present this in different ways, but the +1/-1/0 mechanism is the same.
By default, test updates with karma of 3 are automatically sent out as full official updates, while test updates with karma of -3 are automatically withdrawn from the testing repository. The Updates Policy specifies minimum levels of karma that different types of update must meet at different points in the development cycle. As you can see, your testing and feedback is vital to make sure that good updates are released quickly and bad ones don't get out to the general public.
For pre-releases, karma may be required for important package builds to become a part of the final release. Look out for mails to the test-announce mailing list requesting karma for specific builds.
Using the web interface
You can also give your feedback on a test update by using the Bodhi web interface. There is a Login link in the left-hand sidebar. Log in using your Fedora account. If you don't have a Fedora account, you can create an account here. Once you are logged in, you will be able to leave a comment on the update. To the right of the comment box are three radio button options that effect karma, represented by three icons that depict FAIL, Untested and PASS. The label for these options asks "Is the update generally functional?"
The icon on the left (which looks like an X) represents "FAIL - Does not fix the bug or pass the test case." The middle option (shaped like an open box) indicates "Untested". And the rightmost icon (which looks like a check mark) designates "PASS - Fixes the bug or passes the test case." These options will leave -1, 0, or +1 karma respectively for the update.
Using fedora-easy-karma
There are tools you can use to ease the process of reporting your feedback.
fedora-easy-karma will help you easily identify installed testing updates and allow you to submit feedback from a command line. Usage instructions can be found at Fedora_Easy_Karma.
Updates-testing enabled by default in development (Branched) releases
In Fedora Branched releases - the next release, once it has branched from Rawhide, but before it is released - the updates-testing repository is enabled by default. Package maintainers in Fedora are encouraged to test their updates via this repository first to keep the development branch more robust while providing the latest updates. If you are a tester, it is recommended to leave this repository enabled and provide feedback to help make the general release that follows a robust one. In the development branch, packages that are in the updates-testing repository will move into the relevant base repository when approved, not the relevant updates repository.
Before release, a fedora-release update will automatically disable the updates-testing repository and enable the updates repository. After the general release, the updates repository will start filling up as more updates gets pushed through but until the release time, updates repository will remain empty.