Description of problem: Currently, the way that the Copr plugin guesses the chroot is to only check for the distro name in /etc/os-release. The plugin will check if the string "Fedora" or "Fedora Linux" is in the OS name and then return the chroot for Fedora, same for Mageia, OpenSUSE, and CentOS Stream. And if all else fails, the Copr plugin will assume EPEL. This causes a small issue for Fedora-based distributions which tracks upstream Fedora (AKA Fedora Remixes) instead of RHEL (Ultramarine Linux, risiOS, and formerly Korora). In which Copr fails to assume the intended chroot. Version-Release number of selected component (if applicable): 4.2.0-1.fc36 How reproducible: Steps to Reproduce: 1. Install a Fedora Remix such as Ultramarine or risiOS 2. Attempt to enable a Copr project Actual results: The Copr plugin properly guesses the chroot right as Fedora. Expected results: Copr assumes the user wants the EPEL chroot. Additional info:
We are having the same issue in tauOS (RPM-OSTree). I think this could be solved with Yum variables, like calling for $fedorarelease or something similar. @cappy could you attempt setting a variable on your dnf-based distro? We previously had variables set for $releaseserver and $taurelease but it either broke when we switched to F36 or never worked.
Additionally, maybe a fedora tag in systemd os-release would solve this.
(In reply to Jaiden Riordan from comment #2) > Additionally, maybe a fedora tag in systemd os-release would solve this. In the case of Ultramarine and risiOS, we have an ID_LIKE variable in os-release. Doesn't really solve it. (In reply to Jaiden Riordan from comment #1) > We are having the same issue in tauOS (RPM-OSTree). I think this could be > solved with Yum variables, like calling for $fedorarelease or something > similar. @cappy could you attempt setting a variable on your > dnf-based distro? We previously had variables set for $releaseserver and > $taurelease but it either broke when we switched to F36 or never worked. I checked out the code from dnf-plugins-core. It seems like they are checking in os-release to get the OS name and using the python3-distro module. Anyway, I tried setting the variable ➜ ~ DNF_VAR_fedorarelease=36 sudo dnf copr enable sukhmeet/mutter-rounded [sudo] password for cappy: 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.pagure.org/copr.copr/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. Do you really want to enable copr.fedorainfracloud.org/sukhmeet/mutter-rounded? [y/N]: y Error: It wasn't possible to enable this project. Repository 'epel-36-x86_64' does not exist in project 'sukhmeet/mutter-rounded'. Available repositories: 'fedora-36-x86_64' If you want to enable a non-default repository, use the following command: 'dnf copr enable sukhmeet/mutter-rounded <repository>' But note that the installed repo file will likely need a manual modification.
Created attachment 1885234 [details] A patch to check ID_LIKE for fedora I have created a patch that may possibly fix this issue, by having it check ID_LIKE in os-release and checking for "fedora". But to not break compatibility with EPEL distros I have it check if "centos" or "rhel" is in the ID_LIKE first (AlmaLinux/Rocky does this) One concern I have about this patch though is that IIRC RHEL actually only has "fedora" in their ID_LIKE. This may possibly break compatibility with RHEL itself, but not other distros.
Patch works on risiOS (and therefore should work on other downstream distros). I am currently installing RHEL's free version in a VM to test if it messes with RHEL.
Created attachment 1885312 [details] Added RHEL check Did not work on RHEL 9 first try, so I added a specific check for RHEL.
(In reply to Cappy Ishihara from comment #3) > (In reply to Jaiden Riordan from comment #2) > > Additionally, maybe a fedora tag in systemd os-release would solve this. > > In the case of Ultramarine and risiOS, we have an ID_LIKE variable in > os-release. Doesn't really solve it. I meant a new variable along the lines of FEDORA_VER. > > (In reply to Jaiden Riordan from comment #1) > > We are having the same issue in tauOS (RPM-OSTree). I think this could be > > solved with Yum variables, like calling for $fedorarelease or something > > similar. @cappy could you attempt setting a variable on your > > dnf-based distro? We previously had variables set for $releaseserver and > > $taurelease but it either broke when we switched to F36 or never worked. > > I checked out the code from dnf-plugins-core. It seems like they are > checking in os-release to get the OS name and using the python3-distro > module. > > Anyway, I tried setting the variable > > ➜ ~ DNF_VAR_fedorarelease=36 sudo dnf copr enable sukhmeet/mutter-rounded > [sudo] password for cappy: > 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.pagure.org/copr.copr/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. > > Do you really want to enable > copr.fedorainfracloud.org/sukhmeet/mutter-rounded? [y/N]: y > Error: It wasn't possible to enable this project. > Repository 'epel-36-x86_64' does not exist in project > 'sukhmeet/mutter-rounded'. > Available repositories: 'fedora-36-x86_64' > > If you want to enable a non-default repository, use the following command: > 'dnf copr enable sukhmeet/mutter-rounded <repository>' > But note that the installed repo file will likely need a manual modification. Maybe the releaseserver variable can remain tied to the Fedora version, but a separate remixversion variable can be added. Thank you for the patches, our appreciation from the OSTree corner of the world.
Would you mind opening a PR against https://github.com/rpm-software-management/dnf-plugins-core ? That would make the patch review (and merge) easier.
(In reply to Pavel Raiskup from comment #8) > Would you mind opening a PR against > https://github.com/rpm-software-management/dnf-plugins-core ? > That would make the patch review (and merge) easier. https://github.com/rpm-software-management/dnf-plugins-core/pull/458
Additionally discovered the resolving PR here: https://github.com/rpm-software-management/dnf-plugins-core/pull/463. Switching into POST.
FEDORA-2023-c9d24d75a2 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c9d24d75a2
FEDORA-2023-c9d24d75a2 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-c9d24d75a2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c9d24d75a2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-c9d24d75a2 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.