KiCad AppImage for Linux

How is the level of interest from the KiCad project to have an official KiCad AppImage of releases, and potentially also of continuous builds? I’d be happy to help the project make official ones, but I need someone who acually knows the ins and outs of the software to see whether things are working as intended.

1 Like

For an official statement by the developers you need to ask over at the kicad mailing list.
This is “only” a user forum. (Only a few developers visit from time to time)

Thanks @Rene_Poschl. I’ve openend an issue on https://github.com/KiCad/kicad-website/issues/257 as instructed at the bottom of the Linux download section of the KiCad homepage.

Side note, it’s always hard to understand why projects build such high barriers to reach developers - I’d have to sign up for a Canonical Launchpad account and join a mailing list, only to send one message or to participate in one conversation. Using GitHub is so much more convenient for occasional contributions and discussions.

I won’t upload any further AppImages, but I am happy to support the KiCad team to do it.

In the meantime, you can generate your own AppImages on a Debian/Ubuntu system using the pkg2appimage tool that converts the debs from the PPA to an AppImage. To do this, run on a Debian/Ubuntu system:

wget https://raw.githubusercontent.com/AppImage/AppImages/master/pkg2appimage
bash pkg2appimage KiCad

This should produce an AppImage. If you are running into issues, please let us know at https://raw.githubusercontent.com/AppImage/issues.

You can also use bash pkg2appimage KiCad-nightly instead. The AppImage for KiCad-201712301944+e062780 is almost 600 MB in size though - I am not sure whether this is correct. How big is the nightly build for macOS and Windows?

Note that if the KiCad team decides to provide official AppImages, these would likely be produced directly as part of the build pipeline rather than by converting from debs in PPAs.

1 Like

Come on, that would take about 5 minutes of your time, hardly a “high barrier”!

In part these barriers are there to discurage trolls and spammers. But the main reason might just be that it has been always that way. (Never change a running system) All developers have their system setup for this and they don’t want to switch to a new system. (Switching would require work by the people who currently develop kicad. And there would be a quite long time where you need to use both the old and new system in parallel.)

And github issues are not really powerful enough to manage a large project. But using pull requests instead of patches could make it easier to contribute code. (But at the cost that it might get harder for the lead developers. Patches are a lot more powerful than pull requests.) More details about this in this stack exchange post


The kicad webside repo is only the right place to ask if your goal is a link from that webside to your download page. If you want an answer from the lead development team there is no way around the fact that you need to use the mailing list. (Making an account there is not that hard. Normally your request to join the mailing list is approved within a day or so.)

1 Like

Without suggesting my opinion as being representative, I find it absolutely a nuisance that an open source project has nightly builds for windows and osx, but not linux distros.
So, from my point of view, I am totally in support of your idea.

Did you even check the download page? https://kicad.org/download/. There are nightly builds for linux distros.

Unfortunately there is no AppImage listed yet.

I absolutely did, multiple times. I even used Google.
Even though, thanks for pointing out that SOME distros do have nightly builds (specifically Ubuntu; I only checked Debian and Gentoo as those are I have around).

Will try and install the PPA debs on my Jessie if I can (have serious doubts though).

I have nothing against having AppImages, on the contrary, I just commented on “an open source project has nightly builds for windows and osx, but not linux distros”. Most major distros (ubuntu, fedora, suse) already have nightly builds of KiCad, so I wondered why “not linux distros”. AppImage would of course work for those distros which don’t benefit from the existing packages.

1 Like

Kicad nightlies are available on the platforms for which somebody creates and maintains them. In most cases one person takes care of a family of distros.

There was an issue to the webside repo where somebody requested an app image. The answer (understandably) was: If somebody is prepared to maintain it, it will be included on the webside.
And the guy got pointed to the develpers mailing list. (This is the place where something like this needs to be discussed. Not on the repo for the webside.)

I am prepared to work with the KiCad project to get automated continuous builds working, like I have done for many other projects including Inkscape.

I had posted there because https://github.com/KiCad/KiCad is just a read-only mirror, and GitHub Issues is disabled. This drives away potential contributors like me (I don’t want to sign up for yet-another platform such as Launchpad or subscribe to yet another mailing list). GitHub and GitLab is the way these things are done “today”. Also, those platforms have CI integration that makes it easy to have continuous builds.

1 Like

Just to let you know that running, on a deb-based system,

wget https://raw.githubusercontent.com/AppImage/AppImages/master/pkg2appimage
bash pkg2appimage KiCad-nightly

produces a nicely working KiCad-201904142302+ef3f773.glibc2.15-x86_64.AppImage as of today.

So there has been absolutely no maintenance needed in the AppImage generation since a long time. Had the project set up those builds as part of their pipeline, there would have been nightly AppImages available all along.

2 Likes

It does not make sense for the development team to move shop just because one guy thinks they can not work with launchpad. The whole bugtracker is over there, the mailing list is over there, … Simply put the devs have their system setup to run on that platform.

But you might be in luck in the long term. Wayne mentioned (on multiple occasions) that kicad development might get moved to a private gitlab (or similar) server hosted at cern. This will however take time. A lot of planing must happen for this move. So for now head over to the mailing list and ask how you can help. Either with packaging or possibly also with the move to a different platform.

1 Like

Well, that’s one way of looking at things. I am pretty sure that there are many “random guys” out there who would contribute a small part (e.g., quickly fix a typo or something like that) but currently the barrier of entry seems too high. Sign up here, sign up there, learn new tools, and get the mail account “spammed”. When all you want to do is, e.g., do a one-line edit.

Cool. Looking forward to it. Hopefully one can log in using GitHub credentials, so that one doesn’t have to sign up for yet another private instance of GitLab.

Back to the original topic, it seems like continuous builds of KiCad AppImages are built in a GitLab pipeline here: https://gitlab.com/kicad-mirror/kicad-source-mirror/pipelines

I have used linux for more than ten years. Until now I never heard of an “image file” that must be made executable to appear on the viewport with input focus. How peculiar!

appear on the viewport with input focus

What?

Hi @probono
I have updated the scripts to work with ubuntu focal and they seem fine
here my fork repo:
github.com/easyw/kicad-appimage/tree/AppImage+standaloneApps
and my AppImage builds…
KiCad-5.1.12.glibc2.29-x86_64.AppImage

KiCad-6.0.0.glibc2.29-x86_64.AppImage

Then I tried to use the built AppImages in centos8 and I get these errors:

[user@localhost ~]$ '/home/user/Downloads/KiCad-5.1.12.glibc2.29-x86_64.AppImage' 
running kicad AppImage
./bin/kicad: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./bin/kicad)
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_KiCad-f3uBjl/usr/lib/x86_64-linux-gnu/libpng16.so.16)
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_KiCad-f3uBjl/usr/lib/x86_64-linux-gnu/libtiff.so.5)
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_KiCad-f3uBjl/usr/lib/x86_64-linux-gnu/libpixman-1.so.0)
./bin/kicad: /lib64/libc.so.6: version `GLIBC_2.30' not found (required by /tmp/.mount_KiCad-f3uBjl/lib/x86_64-linux-gnu/libselinux.so.1)
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_KiCad-f3uBjl/usr/lib/x86_64-linux-gnu/libsqlite3.so.0)

[user@localhost ~]$ '/home/user/Downloads/KiCad-6.0.0.glibc2.29-x86_64.AppImage' 
running kicad AppImage
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by ./bin/kicad)
./bin/kicad: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./bin/kicad)
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_KiCad-QYaT4k/usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0)
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_KiCad-QYaT4k/usr/lib/x86_64-linux-gnu/libpng16.so.16)
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_KiCad-QYaT4k/usr/lib/x86_64-linux-gnu/libtiff.so.5)
./bin/kicad: /lib64/libc.so.6: version `GLIBC_2.30' not found (required by /tmp/.mount_KiCad-QYaT4k/lib/x86_64-linux-gnu/libselinux.so.1)
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_KiCad-QYaT4k/usr/lib/x86_64-linux-gnu/libpixman-1.so.0)
./bin/kicad: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_KiCad-QYaT4k/usr/lib/x86_64-linux-gnu/libsqlite3.so.0)

In which way could I change my recipes to add those libs?

I got this error when using your AppImage on Manjaro

[minh@ngoc-ms7b89 Downloads]$ ./KiCad-6.0.0.glibc2.29-x86_64.AppImage
running kicad AppImage
./bin/kicad: symbol lookup error: /usr/lib/libgio-2.0.so.0: undefined symbol: g_module_open_full