I had to switch from Ubuntu to RHEL so am running Rocky Linux now. Some software just would not work right under Ubuntu - especially components on Lattice Diamond.
But I can’t seem to install KiCad on it…
I’m kind of new to all this DNF and repo business, here’s my best try (I saw Fedora 40 listed) on the download page.
$ sudo dnf copr enable @kicad/kicad-stable fedora-40-x86_64
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/@kicad/kicad-stable? [y/N]: y
Repository successfully enabled.
$
$ sudo dnf install kicad kicad-packages3d kicad-doc
Copr repo for kicad-stable owned by @kicad 420 B/s | 341 B 00:00
Errors during downloading metadata for repository 'copr:copr.fedorainfracloud.org:group_kicad:kicad-stable':
- Status code: 404 for https://download.copr.fedorainfracloud.org/results/@kicad/kicad-stable/fedora-9-x86_64/repodata/repomd.xml (IP: 2600:9000:25f2:9800:4:bbc1:1840:93a1)
Error: Failed to download metadata for repo 'copr:copr.fedorainfracloud.org:group_kicad:kicad-stable': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Ignoring repositories: copr:copr.fedorainfracloud.org:group_kicad:kicad-stable
Last metadata expiration check: 0:37:16 ago on Thu 05 Sep 2024 03:36:44 PM PDT.
No match for argument: kicad
No match for argument: kicad-packages3d
No match for argument: kicad-doc
Error: Unable to find a match: kicad kicad-packages3d kicad-doc
$
I remember there being folders where the rpm’s could be downloaded directly in the past…
By the way, if I just set the owner to @kicad I get:
$ sudo dnf copr enable @kicad/kicad-stable
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/@kicad/kicad-stable? [y/N]: y
Error: It wasn't possible to enable this project.
Repository 'epel-9-x86_64' does not exist in project '@kicad/kicad-stable'.
Available repositories: 'fedora-39-aarch64', 'fedora-rawhide-x86_64', 'fedora-39-x86_64', 'fedora-38-aarch64', 'fedora-41-ppc64le', 'fedora-40-x86_64', 'fedora-40-aarch64', 'fedora-39-ppc64le', 'fedora-41-aarch64', 'fedora-rawhide-ppc64le', 'fedora-38-x86_64', 'fedora-38-ppc64le', 'fedora-40-ppc64le', 'fedora-41-x86_64', 'fedora-rawhide-aarch64'
If you want to enable a non-default repository, use the following command:
'dnf copr enable @kicad/kicad-stable <repository>'
But note that the installed repo file will likely need a manual modification.
Are you running a server? Server distros favour stability and libraries tend to be not up to date. I wonder why you would use Rocky Linux, a CentOS replacement, for desktop applications. Wouldn’t Fedora, which is supported for KiCad, be more suitable?
Ah, no I’m not running a server. It’s a Dell 17" laptop.
I’ve never really used RH before (other than CentOS and Rocky on servers), so am not too familiar with their various products. I’m experimenting to see if this can be made to work, but like you’ve suggested I suspect it’s a dead end… I’ll see if I can get Fedora to work instead.
I DO run Rocky servers, but I’ve never tried to configure it as a desktop.
I’m a Fedora 40 user. I run Redhat Enterprise and AlmaLinux (pretty similar to Rocky Linux) on servers at my day job (not with KiCad!). They are based on older versions of Fedora, but might have their own specific library versions. There’s a tiny possibility to recompile it from src rpm, but if I remember correctly, you might run into trouble anyway due to missing dependencies. Flatpak is your best bet.
I’m newly running the flatpak version of KiCad 8.0.4 on Rocky Linux 8, and it appears to work just fine. I tried it for a while in a Fedora 40 VM, and decided that switching to the VM was a bit of a nuisance. About the only difference is whether the desktop Applications menu lists KiCad under “Electronics” or “Other”.
Back before RH acquired and killed off CentOS it was universally popular as a server system, so for dev work I’d run it locally as a desktop as well. It made it easier to do local test-driven development, although of course at some point stuff needs to be tested in something that resembles a production environment (or a local kube node, or what have you). But at least at that point the only remaining issues can be narrowed down to being due to the deployment environment. I was kind of thinking the same for Rocky. In fact, I suspect there’s a lot of interest in making RL a fully competent desktop for these reasons… I didn’t get to the flatpak but grabbed the kicad 8.0.4 rpm off rpmfinder.net and realized it has a VERY long and like very specific list of dependencies, including something like a recent version of ngspice. It’s not terribly surprising that it works off flatpak since RL is binary compatible with RH… so as long as all the right deps are there it should be good to go, and if there is a RH dist of KiCad, then those should of course exist. Creating a RL KiCad dist might just be a packaging and push job.
I do like Fedora 40 actually, it’s a good workstation setup. It uses LVM for example so if disk runs low just drop in another SSD, add it to the LV group and extend the fs. Poking around I found some other bits well thought out as well, and the dnf hub is very, very complete. So I think I’ll stick with it!
A flatpak runs in a container with all the dependencies requiring only kernel support for namespaces (which has been the case for a long time) so in principle it should work for many distros even with older versions.
You might run into conflicts with versions of DL libraries supplied with the distro. Say you need a more recent version of a utility library. This might break distro applications, endangering stability. It can be solved with choice of installation directories, judicious use of LD_LIBRARY_PATH, static linking of some libraries and other measures but ti takes work.
After that there’s the continuing support issue. Users will expect updates, so you’ll have to keep refreshing the packages.
Flatpak solves the problem for many distros in one go. It has its drawbacks, but that’s another story.
True. There is an impressive list of distributions at Set Up Flathub | Flathub. Even Chrome OS is supported!
Just for fun I tried to install the flatpak version of KiCAD in Fedora in WSL on Windows 11. It works! (The native version in Fedora works there as well).
(It should be noted, though, that WSL is a bit messy and sometimes it’s difficult to make the graphical environment work).
My point was that Rocky is by definition binary compatible with RHEL. If you have all the shared object dependencies for Fedora, then there is no reason to use them in a container, as they can be dynamically loaded directly on the system.
Libraries in the host distro cannot be used by the container anyway. Container means isolation, hence every required dependency has to be in the container, thus duplication, one of the drawbacks of such universal packages.
