Bug 2091662

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.