Skip to content
This repository has been archived by the owner on Oct 26, 2021. It is now read-only.

Please provide an AppImage for Linux #257

Closed
probonopd opened this issue Dec 31, 2017 · 22 comments
Closed

Please provide an AppImage for Linux #257

probonopd opened this issue Dec 31, 2017 · 22 comments

Comments

@probonopd
Copy link

Providing an AppImage would have, among others, these advantages:

  • Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
  • One app = one file = super simple for users: just download one AppImage file, make it executable, and run
  • No unpacking or installation necessary
  • No root needed
  • No system libraries changed
  • Works out of the box, no installation of runtimes needed
  • Optional desktop integration with appimaged
  • Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
  • Can optionally GPG2-sign your AppImages (inside the file)
  • Works on Live ISOs
  • Can use the same AppImages when dual-booting multiple distributions
  • Can be listed in the AppImageHub central directory of available AppImages
  • Can double as a self-extracting compressed archive with the --appimage-extract parameter

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

A while back I had made some test AppImages, see the discussion here:
https://forum.kicad.info/t/kicad-appimage-for-linux/4963/7
Note that this was just a quick proof-of-concept. While I do not have the time (nor KiCad knowledge) to maintain an AppImage build myself, I'd be happy to help the KiCad project setting one up.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

@marekr
Copy link
Member

marekr commented Dec 31, 2017

Well it's really up to someone to provide the build server and maintain it. Linux distribution is left up to distros to maintain. Windows and OSX are run by two maintainers with donated access to build machines and their time. If someone wants to do it because they care about AppImage packages...we would probably link to it just like Snappy and Flatpak (yay Linux's NIH syndrome).

A better place to discuss could be the developer mailing list. But I don't see anyone there stepping up to do it for AppImage in particular but who knows.

@probonopd
Copy link
Author

Well it's really up to someone to provide the build server and maintain it.

I'd recommend to use Travis CI.

Would you be open to a pull request that would use Travis CI to do the builds?

@marekr
Copy link
Member

marekr commented Jan 11, 2019

No unforunately. Us website maintainers don't control the main source repo which also resides on launchpad and not github.

It's also a tad bit more work than that. Currently packaging requries quite some configuration of build variables to make a true, non nightly build. Somebody would have to maintain ownership and maintenance of it.

@nickoe
Copy link
Contributor

nickoe commented Jan 11, 2019

I am purely waiting for kicad source to be fixed up such that it will actually build the appimage... Currently it fails on Antonio's image. I don't want to use Travis for this.

@probonopd
Copy link
Author

Would you be open to a pull request that would use Travis CI to do continuous builds on every git push?

@nickoe
Copy link
Contributor

nickoe commented Jan 11, 2019

no.

@probonopd
Copy link
Author

I'm happy to help but I don't know how. Please let me know how I can be helpful.

@MaxGaukler
Copy link

This is sad. We want to use KiCad for a class, where we cannot use the packages for administrative reasons, but a "just download and run" version would be okay. The AppImage does exactly that - it's a single executable file that just works. You don't need any snap/flatpack/whatever support in your distribution.

@nickoe
Copy link
Contributor

nickoe commented Jun 6, 2019

The latest appimage as proposed by antonio still has broken scripting. I won't do anything before it is fixed.

@probonopd
Copy link
Author

The latest appimage as proposed by antonio

Where can it be downloaded for testing? Maybe I can help fix it?

@nickoe
Copy link
Contributor

nickoe commented Jun 6, 2019

@probonopd it is hosted on the kicad-mirror on gitlab.com as far as I remember, but you need to login to any gitlab account to be able to access it.

You have linked to it yourself in an earlier forum post.

@antoniovazquezblanco are you able to help here? I would like to see it work, but I would like to see it work properly and supported by someone if we are to provide it as an official option for users.

@probonopd
Copy link
Author

Where can it be downloaded for testing? Maybe I can help fix it?

https://gitlab.com/kicad-mirror/kicad-source-mirror/pipelines

@probonopd
Copy link
Author

probonopd commented Jun 6, 2019

The latest appimage as proposed by antonio still has broken scripting.

How can I reproduce this @nickoe?

@nickoe
Copy link
Contributor

nickoe commented Jun 6, 2019

Open pcbnew and start the scripting console. Top toolbar, rightmost icon.

@probonopd
Copy link
Author

probonopd commented Jun 6, 2019

me@host:~$ Downloads/KiCad-5.1.0-892-g1010fd3.AppImage

# Open pcbnew

LoadAllLibraries: lib_names:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named wxversion

me@host:~$ find /tmp/.mount_KiCad-*/ | grep wxversion
/tmp/.mount_KiCad-WZ0nnL/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wxversion.py
/tmp/.mount_KiCad-WZ0nnL/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wxversion.pyc

me@host:~$ cat /tmp/.mount_KiCad-WZ0nnL/usr/lib/wx/python/wx3.0.pth
wx-3.0-gtk2
me@host:~$ find /tmp/.mount_KiCad-WZ0nnL/usr/lib/python2.7/ -name '*.so' -exec ldd {} \; | grep "not found" | sort | uniq
	libcrypto.so.1.0.0 => not found
	libGLEW.so.1.13 => not found
	libkicad_3dsg.so.2.0.0 => not found
	libpython2.7.so.1.0 => not found
	libwx_baseu-3.0.so.0 => not found
	libwx_baseu_net-3.0.so.0 => not found
	libwx_baseu_xml-3.0.so.0 => not found
	libwx_gtk2u_adv-3.0.so.0 => not found
	libwx_gtk2u_aui-3.0.so.0 => not found
	libwx_gtk2u_core-3.0.so.0 => not found
	libwx_gtk2u_gl-3.0.so.0 => not found
	libwx_gtk2u_html-3.0.so.0 => not found
	libwx_gtk2u_propgrid-3.0.so.0 => not found
	libwx_gtk2u_richtext-3.0.so.0 => not found
	libwx_gtk2u_stc-3.0.so.0 => not found
	libwx_gtk2u_xrc-3.0.so.0 => not found

Those need to be properly deployed.

@nickoe
Copy link
Contributor

nickoe commented Jun 6, 2019

Don't forget this issue and the stuff in it #370

@probonopd
Copy link
Author

https://gitlab.com/inkscape/inkscape/blob/master/packaging/appimage/generate.sh shows one way to do the Python bundling. Does @antoniovazquezblanco read here?

@antoniovazquezblanco
Copy link

Yes, I do read here. I have little to no time to work on this unfortunatelly.

Yesterday I read about this and decided to push this again and was able to fix repository mirroring and getting the build to work again. I will try to finish packaging all those libs soon.

@probonopd, I see what you are doing for Inkscape but I don't really like how they are packing the dependency list. I will probably get this to work soon but I don't want to maintain a list of dynamic libs that should be packed due to the work. I would love to have a better way to pack those deps. does the conda appimage solve this? Thanks!

@antoniovazquezblanco
Copy link

	libGLEW.so.1.13 => not found
	libkicad_3dsg.so.2.0.0 => not found
	libpython2.7.so.1.0 => not found
	libwx_baseu-3.0.so.0 => not found
	libwx_baseu_net-3.0.so.0 => not found
	libwx_baseu_xml-3.0.so.0 => not found
	libwx_gtk2u_adv-3.0.so.0 => not found
	libwx_gtk2u_aui-3.0.so.0 => not found
	libwx_gtk2u_core-3.0.so.0 => not found
	libwx_gtk2u_gl-3.0.so.0 => not found
	libwx_gtk2u_html-3.0.so.0 => not found
	libwx_gtk2u_propgrid-3.0.so.0 => not found
	libwx_gtk2u_richtext-3.0.so.0 => not found
	libwx_gtk2u_stc-3.0.so.0 => not found
	libwx_gtk2u_xrc-3.0.so.0 => not found

@probonopd Those appear to be packed by appimage tool. Please, have a look at the latest build log at: https://gitlab.com/kicad-mirror/kicad-source-mirror/-/jobs/226461088

What am I doing wrong? How should those be packed then?

Thanks!

@probonopd
Copy link
Author

Looks like the libwx_gtk2u_... stuff is working now.

The rest is getting the modules onto the $PYTHONPATH, e.g,

Downloads/KiCad-5.1.0-892-g1010fd3.AppImage --appimage-extract
cd squashfs-root/usr/bin/
ln -s ../share/kicad/scripting/* .
ln -s ../lib/python2.7/dist-packages/wx-3.0-gtk2/wx* .
../../AppRun 

pcbnew -> Tools -> Scripting Console starts to work now, but then encounters a dependency that needs to be bundled:

File "/home/me/squashfs-root/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/py/dispatcher.py", line 9, in <module>
    import weakref
  File "/usr/lib/python2.7/weakref.py", line 14, in <module>
    from _weakref import (
ImportError: cannot import name _remove_dead_weakref

This module is missing in the AppImage entirely.

@antoniovazquezblanco
Copy link

That is helpful to me. I can now continue with this. Thank you very much!

@MaxGaukler
Copy link

@antoniovazquezblanco I tried your most recent AppImage on Ubuntu 18.04. With some fixing, the scripting console shows up correctly:

./KiCad-5.1.0-892-g1010fd3.AppImage --appimage-extract
cp /usr/lib/x86_64-linux-gnu/libpython2.7.so.1 squashfs-root/usr/lib/libpython2.7.so.1.0
cat > squashfs-root/AppRun << \EOF
#!/bin/sh
HERE="$(dirname "$(readlink -f "${0}")")/../../"
export PYTHONPATH="${HERE}"/usr/lib/python2.7:"${HERE}"/usr/lib/python2.7/dist-packages/wx-3.0-gtk2:${PYTHONPATH}
export LD_LIBRARY_PATH="${HERE}"/usr/lib/:${LD_LIBRARY_PATH}
exec "${HERE}/usr/bin/kicad_bin" "$@"
EOF
./squashfs-root/AppRun

At first sight, it seems that everything works, the only thing I found missing are the symbols libraries, translations and docs.

My "fix", copying over libpython, is actually a super ugly hack and not really a solution. I guess the problem is that the system weakref.py is incompatible with the bundled libpython. What we'd actually need is bundling the python standard library including weakref.py (probably the whole /usr/lib/python2.7 folder from the build environment).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants