Two COPR projects ship lazygit for Fedora 45, and only one of them is current. On the day these steps were run, the other served a copied build 19 minor versions behind upstream, yet dnf copr enable treats both the same: one prompt, one repo file, and whatever the project’s Fedora 45 chroot holds lands on your system.
This guide shows how to use COPR repositories on Fedora with dnf copr, starting with a build check before you enable anything. It then covers trusting a project’s key, fixing “Chroot not found”, spotting the extra repos some projects pull in, switching between two COPRs and removing them cleanly. Everything was built and run on Fedora 45 with dnf5 in October 2026.
Check that dnf copr is available
The copr subcommand comes from the dnf5-plugins package, which Workstation and the Cloud image already carry. If dnf copr answers with an unknown-command error, install dnf5-plugins first; otherwise confirm what you’ve got:
rpm -q dnf5 dnf5-plugins
dnf copr --helpThe help lists five subcommands, and this guide uses four of them. Read the one-line descriptions once, because disable and remove do very different things to the repo file, and picking the wrong one is how a COPR you thought was gone keeps feeding updates:
dnf5-5.4.6.0-3.fc45.x86_64
dnf5-plugins-5.4.6.0-3.fc45.x86_64
Usage:
dnf5 [GLOBAL OPTIONS] copr [OPTIONS] <COMMAND> ...
Description:
Manage Copr repositories (add-ons provided by users/community/third-party)
Commands:
list list Copr repositories
enable download the repository info from a Copr server and install it as a /etc/yum.repos.d/*.repo file
disable disable specified Copr repository (if exists), keep /etc/yum.repos.d/*.repo file - just mark enabled=0
remove remove specified Copr repository from the system (removes the /etc/yum.repos.d/*.repo file)
debug print useful info about the system, useful for debuggingVet a COPR before you enable it
A Fedora 45 chroot in a project tells you nothing about what’s inside it. When Fedora branches a release, COPR copies the latest successful rawhide builds of every project that builds for rawhide and follows Fedora branching into the new chroot, without rebuilding them, so a project nobody has touched in years still looks supported. The COPR API reports the build state and version for every chroot, so check it with curl and jq before you trust a project:
OWNER=atim
PROJECT=lazygit
curl -fsSL "https://copr.fedorainfracloud.org/api_3/monitor?ownername=${OWNER}&projectname=${PROJECT}" | jq -r '.packages[] | .name as $n | .chroots | to_entries[] | select(.key|test("fedora-(rawhide|$(rpm -E %fedora))-x86_64")) | "\($n) \(.key) \(.value.state) \(.value.pkg_version) build \(.value.build_id)"'Every chroot of atim/lazygit holds the same build, and its state is forked, which means it was copied, not built for that release:
lazygit fedora-45-x86_64 forked 0.47.2-1 build 8698411
lazygit fedora-44-x86_64 forked 0.47.2-1 build 8698411
lazygit fedora-43-x86_64 forked 0.47.2-1 build 8698411Run the same query with OWNER=dejan and the picture is different: every chroot succeeded with 0.66.2, the same version as the latest lazygit release on GitHub. That’s the project to use. The check took one command, and it’s the only place the difference shows, because both projects look identical in a search result and both enable without complaint:
lazygit fedora-45-x86_64 succeeded 0.66.2-1 build 11163767
lazygit fedora-44-x86_64 succeeded 0.66.2-1 build 11163767
lazygit fedora-43-x86_64 succeeded 0.66.2-1 build 11163767Before enabling any project, run through the same short checklist. Each item takes seconds and catches a different way a COPR goes wrong:
- Query the monitor API and confirm your release’s chroot exists.
- Check the state:
succeededis a real build,forkedis a copy from an older release. - Compare
pkg_versionwith the upstream release page. - Look up the project’s runtime dependencies on its COPR page, because they become repos on your machine too.
Also check whether Fedora already packages the software, because the official package gets security updates through Fedora’s own review and update process. A COPR package with the same name competes with it on version, unless the owner gave the project a repository priority, in which case dnf writes a priority= line into the repo file and that COPR can win with an older build. Either way a careless owner can replace a Fedora package on your system with a patched one, so grep priority the repo file after you enable a project. dnf repoquery --repo=fedora --repo=updates lazygit printed nothing on Fedora 45, so a COPR is the only RPM option here, and for desktop apps it is worth checking Flathub on Fedora as well.
Enable a COPR repository
Enabling takes the project as owner/project and asks once before writing anything. Read the prompt the first time, because it is the only statement of what you’re accepting:
sudo dnf copr enable atim/lazygitFedora doesn’t review COPR content, and the warning says so plainly:
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.
The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.copr.fedorainfracloud.org/user_documentation.html#what-i-can-build-in-copr>,
and packages are not held to any quality or security level.
Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.
Is this ok [y/N]:Answer y and dnf writes one file per project to /etc/yum.repos.d. Look at it once. Two of its lines decide how failures look later, and you’ll want to recognize them when an upgrade behaves oddly:
cat "/etc/yum.repos.d/_copr:copr.fedorainfracloud.org:atim:lazygit.repo"The baseurl uses $releasever, so the same file follows you to the next Fedora release:
[copr:copr.fedorainfracloud.org:atim:lazygit]
name=Copr repo for lazygit owned by atim
baseurl=https://download.copr.fedorainfracloud.org/results/atim/lazygit/fedora-$releasever-$basearch/
type=rpm-md
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://download.copr.fedorainfracloud.org/results/atim/lazygit/pubkey.gpg
repo_gpgcheck=0
enabled=1
enabled_metadata=1skip_if_unavailable=True means a project that never builds for your next release won’t break dnf upgrade. That sounds friendly, but dnf skips the repo, exits 0 and your COPR packages stop updating, with only a few 404 lines to tell you so. gpgcheck=1 with repo_gpgcheck=0 means packages are signed but the metadata isn’t, which is the normal COPR setup.
To see what a missing chroot looks like, the lab pointed a COPR repo file at fedora-99-x86_64, a chroot no project has, and ran sudo dnf -y upgrade --refresh. The download redirect lands on packages.redhat.com, the 404 repeats four times, and the run still ends cleanly with exit status 0:
Copr repo for lazygit owned by dejan 100% | 18.0 B/s | 56.0 B | 00m03s
>>> Status code: 404 for https://packages.redhat.com/api/pulp-content/public-copr/dejan/lazygit/fedora-99-x86_64/repodata/repomd.xml (IP: 2.17.161.96) - https://packages.redhat.com/api/pulp-content/public-copr/dejan/lazygit/fedora-99-x86_64/repodata/repomd.xml
>>> Status code: 404 for https://packages.redhat.com/api/pulp-content/public-copr/dejan/lazygit/fedora-99-x86_64/repodata/repomd.xml (IP: 2.17.161.96) - https://packages.redhat.com/api/pulp-content/public-copr/dejan/lazygit/fedora-99-x86_64/repodata/repomd.xml
>>> Status code: 404 for https://packages.redhat.com/api/pulp-content/public-copr/dejan/lazygit/fedora-99-x86_64/repodata/repomd.xml (IP: 2.17.161.96) - https://packages.redhat.com/api/pulp-content/public-copr/dejan/lazygit/fedora-99-x86_64/repodata/repomd.xml
>>> Status code: 404 for https://packages.redhat.com/api/pulp-content/public-copr/dejan/lazygit/fedora-99-x86_64/repodata/repomd.xml (IP: 2.17.161.96) - https://packages.redhat.com/api/pulp-content/public-copr/dejan/lazygit/fedora-99-x86_64/repodata/repomd.xml
>>> Usable URL not found
Repositories loaded.
Nothing to do.On a busy upgrade those lines scroll past between dozens of package names, which is why the vetting step matters more than watching the output.
Install a package and accept its key
Every COPR project has its own signing key, generated by COPR and served from the project’s results directory, so the first install from a project asks you to import it. In scripts use -y: there are two prompts, and piping a single y answers only the transaction prompt, which made the key import fail with “Canceled by the user” in the lab:
sudo dnf -y install lazygitThe key’s user ID names the project, not a person. COPR generated it when the project was created, so the fingerprint is unique to atim/lazygit and a second project from the same owner brings its own key:
Importing OpenPGP key 0x1883FFF9:
UserID : "atim_lazygit (None) <atim#[email protected]>"
Fingerprint: 21825C9375500D26420946654845E2711883FFF9
From : https://download.copr.fedorainfracloud.org/results/atim/lazygit/pubkey.gpgThat signature proves the RPM came out of the COPR build system for that project. It doesn’t prove the owner is who you think, or that the spec file is safe, which is why the vetting step above matters more than the key. Check where the installed package came from:
dnf repoquery --installed --qf "%{name}-%{evr} %{from_repo}\n" lazygitNote the fc43 dist tag on a Fedora 45 box, the same stale fork the API showed:
lazygit-0.47.2-1.fc43 copr:copr.fedorainfracloud.org:atim:lazygitSwitch to a better COPR for the same package
You don’t have to uninstall to move to the maintained project. Enable the second COPR, and with no priority set on either project dnf picks the highest version among every repo that provides the package, so a normal upgrade moves you across and imports the new project’s key on the way:
sudo dnf -y copr enable dejan/lazygit
dnf repoquery --qf "%{name}-%{evr} %{repoid}\n" lazygit
sudo dnf -y upgrade lazygitThe capture shows both projects side by side and the upgrade replacing the 0.47.2 fork with 0.66.2:
Remove the old project once you have switched, with sudo dnf copr remove atim/lazygit. While both are enabled, a future build in the old one with a higher version would take over again on the next upgrade, and you would be back on whatever that owner ships. dnf will not warn you about the swap either, because to dnf two repos offering the same package name is normal.
Fix “Chroot not found” in a Copr project
This error means the project has no build target for your release, and the right answer is almost always a different project, not a different chroot. solopasha/hyprland only had a rawhide chroot when these steps were run, and dnf listed the chroots it does have:
sudo dnf -y copr enable solopasha/hyprlandThe plugin refuses and names the only chroot the project has:
Chroot not found in the given Copr project (fedora-45-x86_64).
You can choose one of the available chroots explicitly:
fedora-rawhide-x86_64Passing that chroot as a second argument is allowed, so the lab tried it with a dry-run install that changes nothing:
sudo dnf -y copr enable solopasha/hyprland fedora-rawhide-x86_64
sudo dnf install --assumeno hyprlandThe whole exchange, from the refusal to the failed dependency resolution:
Passing the chroot explicitly writes a repo file pinned to fedora-rawhide-x86_64, and the install then fails on a library soname: the builds were made against libdisplay-info.so.2, while Fedora 45 ships libdisplay-info-0.3.0, which provides libdisplay-info.so.3. Builds from another release’s chroot only install when every library they link against still has the same soname on yours. You can’t know that before you try, and a forced install would break on the next library update anyway. If you enabled the rawhide chroot, remove the pinned repo instead of hunting for --skip-broken workarounds:
sudo dnf copr remove solopasha/hyprlandThe one case where an explicit chroot is reasonable is a project that hasn’t added a new release yet but builds something with no compiled dependencies, such as fonts or scripts. Even then, use the previous release’s chroot, never rawhide, because rawhide builds track libraries that haven’t reached any stable release. Several Fedora desktop guides here hit the same wall, such as the Deepin desktop on Fedora, whose COPRs had nothing for 45, and Pantheon on Fedora, whose COPR installs on 45 but whose window manager fails to start.
Watch for runtime dependency repos
A COPR owner can declare other repositories as runtime dependencies, and enabling the project enables those as well. tofik/sway does this, and the second prompt it shows is easy to miss:
sudo dnf copr enable tofik/swayAfter the usual warning, dnf lists two more repositories owned by two other people and asks again:
Maintainer of the enabled Copr repository decided to make
it dependent on other repositories. Such repositories are
usually necessary for successful installation of RPMs from
the main Copr repository (they provide runtime dependencies).
Be aware that the note about quality and bug-reporting
above applies here too, Fedora Project doesn't control the
content. Please review the list:
1. [coprdep:copr.fedorainfracloud.org:erikreider:SwayNotificationCenter]
baseurl=https://download.copr.fedorainfracloud.org/results/erikreider/SwayNotificationCenter/fedora-$releasever-$basearch/
2. [coprdep:copr.fedorainfracloud.org:mochaa:gtk-session-lock]
baseurl=https://download.copr.fedorainfracloud.org/results/mochaa/gtk-session-lock/fedora-$releasever-$basearch/
These repositories are being enabled together with the main
repository.
Is this ok [y/N]:With -y, both prompts are answered for you, so a one-line enable in a setup script quietly trusts three owners instead of one. Those extra repos can ship any package name, not just the dependencies the main project needs. Answering N at the second prompt doesn’t cancel anything: the main repo is still enabled, and the dependency sections are written with enabled=0. The dependency repos live as extra [coprdep:...] sections in the same repo file, and dnf copr list flags the project with [eternal_deps], which is dnf5’s own spelling of “external deps” in the copr plugin source:
copr.fedorainfracloud.org/dejan/lazygit
copr.fedorainfracloud.org/tofik/sway [eternal_deps]Vet each dependency repo with the monitor query above, the same way you vetted the main project. In this case several packages in tofik/sway itself were also forked builds, one of them carrying an fc40 dist tag in the Fedora 45 chroot.
Disable or remove a COPR
Disable keeps the repo file and sets enabled=0, which is what you want before a Fedora upgrade for a project that has no chroot for the new release, or while you test whether a problem comes from the COPR. It also switches off the dependency repos in the same file:
sudo dnf copr disable tofik/sway
grep -E "^\[|^enabled=" /etc/yum.repos.d/_copr:copr.fedorainfracloud.org:tofik:sway.repoAll three sections flip to disabled, and dnf copr list marks the project (disabled):
[copr:copr.fedorainfracloud.org:tofik:sway]
enabled=0
[coprdep:copr.fedorainfracloud.org:erikreider:SwayNotificationCenter]
enabled=0
[coprdep:copr.fedorainfracloud.org:mochaa:gtk-session-lock]
enabled=0When you’re sure you won’t need a disabled project again, sudo dnf copr remove tofik/sway takes the file and its dependency sections away in one go. Remove deletes the repo file, but it leaves the packages you installed from it and the signing key in place. Those packages never update again, which is fine for a font and risky for anything that talks to the network, so find them right after removing the repo:
sudo dnf copr remove dejan/lazygit
dnf list --extras--extras lists installed packages that no enabled repo provides, and it still shows which COPR each one came from:
Extra packages
lazygit.x86_64 0.66.2-1.fc45 copr:copr.fedorainfracloud.org:dejan:lazygitRemove the package, then delete the project’s key. Fedora 45 ships RPM 6, where rpmkeys --list shows keys by full fingerprint and rpmkeys --delete takes that fingerprint directly:
sudo dnf -y remove lazygit
rpmkeys --list | grep -i coprEach COPR key is named after its project, so it’s easy to match fingerprints to the repos you removed. In the lab both lazygit projects had left one behind:
21825c9375500d26420946654845e2711883fff9 atim_lazygit (None) <atim#[email protected]> public key
6101156f64e43013a0d18fadf0bfefc533e9b75e dejan_lazygit (None) <dejan#[email protected]> public keyDelete every key whose project you no longer use:
sudo rpmkeys --delete 21825c9375500d26420946654845e2711883fff9
sudo rpmkeys --delete 6101156f64e43013a0d18fadf0bfefc533e9b75eLeaving an old project key in the keyring is not dangerous on its own, since nothing points at that repo anymore, but deleting it means a re-enabled project has to ask for your trust again. If the package you removed is one you still want, look for it in the Fedora repos or on Flathub before reaching for another COPR. The DNF5 cheatsheet for Fedora covers the repoquery and history commands for checking what a repo changed.
dnf copr reference card
Every command from this guide in one place, with what each one changes on disk:
| Task | Command | Effect |
|---|---|---|
| Check builds first | curl -fsSL "https://copr.fedorainfracloud.org/api_3/monitor?ownername=OWNER&projectname=PROJECT" | Nothing; read-only API |
| Enable a project | sudo dnf copr enable owner/project | Writes /etc/yum.repos.d/_copr:...repo, plus any coprdep sections |
| Enable a specific chroot | sudo dnf copr enable owner/project fedora-44-x86_64 | Repo file pinned to that chroot instead of $releasever |
| List projects | dnf copr list | Shows (disabled) and [eternal_deps] flags |
| See what a project ships | dnf repoquery --repo="copr:copr.fedorainfracloud.org:owner:project" | Nothing |
| Find a package’s source repo | dnf repoquery --installed --qf "%{name}-%{evr} %{from_repo}\n" pkg | Nothing |
| Turn a project off | sudo dnf copr disable owner/project | Sets enabled=0 on every section, keeps the file |
| Delete a project | sudo dnf copr remove owner/project | Deletes the file; packages and key stay |
| Find orphaned packages | dnf list --extras | Nothing |
| Delete a project key | sudo rpmkeys --delete FINGERPRINT | Removes the key from the RPM keyring |
Before your next Fedora upgrade (the 44 to 45 upgrade guide shows the process), run dnf copr list and the monitor query for each project. Thanks to skip_if_unavailable=True, a project without a chroot for the new release just leaves its packages un-updated, and dnf still exits 0.
