Problem with case-sensitive chroot names in DNF5 copr plugin
Opened this issue · 10 comments
Reported on Matrix today.
Enabling a Copr project via DNF5 didn't work because of the capital F in the Fedora-41-aarch64 chroot.
dnf copr enable ngompa/fedora-asahi-dev
Chroot not found in the given Copr project (Fedora-41-aarch64).
You can choose one of the available chroots explicitly:
...
fedora-41-aarch64
...
I am not sure how the capitalized chroot name came from. A workaround was
dnf copr enable ngompa/fedora-asahi-dev fedora-41-aarch64
I cannot reproduce on x86_64 on F41. May be aarch64 specific.
I tried in fedora-41-aarch64:
<mock-chroot> sh-5.2# python3
Python 3.13.0 (main, Oct 8 2024, 00:00:00) [GCC 14.2.1 20240912 (Red Hat 14.2.1-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import distro
>>> distro.id()
'fedora'
And it is correct too. I probably wouldn't search for the cause of the problem and only .lower() the chroot name
It's probably Asahi related? I'm on Asahi too and noticed the same thing
Thank you very much for the confirmation @PaddiM8. We were suspecting that and wanted to ask some Asahi users that we know, to test this.
Can you please paste the output of these two commands?
python3 -c "import distro; print(distro.id())"
cat /etc/os-release |grep ID |grep -i fedora
python3 -c "import distro; print(distro.id())"
fedora-asahi-remix
cat /etc/os-release |grep ID |grep -i fedora
ID=fedora-asahi-remix
ID_LIKE=fedora
~ ❯ python3 -c "import distro; print(distro.id())"
fedora-asahi-remix
~ ❯ cat /etc/os-release |grep ID |grep -i fedora
~ ❯
Upgraded from 39 to 41 just before noticing this btw
Thank you very much @jannau and @PaddiM8.
I am still confused how this happens. If I understand the DNF5 plugin correctly, it uses the ID variable from /etc/os-release that you showed us to be lowercase. And DNF4 plugin does some guessing magic, having several fallbacks. But in neither of them I can clearly see a problem.
Can you please let us know what DNF version are you using? So we can focus on debugging the right codebase.
dnf --version
In case, it is DNF4, these should hopefully help us locate the problem.
python3 -c "from distro import name, version, codename; print((name(), version(), codename()))"
python3 -c "from platform import linux_distribution; print(linux_distribution())"
cat /etc/os-release |grep -E "^NAME=|^VERSION_ID="
This is indeed an asahi specific issue. fedora-asahi-remix-release-common carries /usr/share/dnf/plugins/copr.vendor.conf with:
[main]
distribution = Fedora
releasever = 41
correcting the distribution to fedora fixes the issue. I'll see to get this fixed and this issue can be closed.