Now the target CPU architecture should be set by the 'ARCH' environment
variable before invoking appimage-builder.
This makes it easier to build the AppImage for other CPU architectures.
This environment variable was necessary back then to work around a bug
in the libgtk3 version we include in the AppImage.
However, since commit 3897a8bccf
("ci/linux: build AppImage on Ubuntu 22.04 (Python 3.10)"), that's not
needed anymore, because Ubuntu 22.04 has a newer version of libgtk3,
which fixes the problem.
I made sure to verify the app runs as expected on Wayland sessions of
two major desktop environments:
- GNOME: 42.9 (Ubuntu 22.04.05) and 48.3 (Arch Linux)
- KDE Plasma: 5.27.5 (Debian 12) and 6.4.3 (Arch Linux)
An up to date version of libXft is still needed because Ubuntu 22.04
still has 2.3.4, which can cause the app not to launch if an emoji font
is installed on the host.
Unfortunately, sourcing the Python venv Bash script to activate the
virtual environment doesn't work while we're building the AppImage, so
this just manually invokes Pip from within the venv to install updated
versions of meson and ninja (for building PyGObject next), and then we
prepend the venv's "bin" directory to the 'PATH' environment variable
to make meson and ninja discoverable on the next "pip install" step.
This also removes "certifi" from being manually installed, because
"truststore" has been usable since commit
3897a8bccf ("ci/linux: build AppImage on
Ubuntu 22.04 (Python 3.10)").
appimage-builder is a tool that is not officially part of the AppImage
ecosystem, and lately its maintainer hasn't been able to keep up with
the latest AppImage ideas, most notably:
- The move to a new statically-linked runtime: Before this, all AppImages
using the old runtime, would depend on libfuse2 to be installed on the
host system just to be able to run out of the box. This wasn't much of
a problem back then, because libfuse2 was ubiquitous. However, nowadays,
some have distros don't even have it in their official repositories.
- The removal of the xz compression algorithm (used by default), and the
addition of Zstd.
Luckily, the problems above have been fixed in the git version of
appimage-builder, but a stable release is yet to be made, so we'll have
to use the git version, because other AppImage-making tools are not as
nice and convenient as appimage-builder.
This manually downloads the old AppImage runtime (now marked as
obsolete), to prevent appimage-builder v1.1.0 from failing to make the
AppImage.
The download URL appimage-builder v1.1.0 uses for the AppImage runtime
is hardcoded into the tool, and unfortunately it's been recently
removed, so this is merely a workaround, until hopefully a future
appimage-builder release fixes this.
See: https://redirect.github.com/AppImageCrafters/appimage-builder/issues/375
The reference AppIndicator implementation has been deprecated/abandoned in newer distros.
Co-Authored-By: Guilherme Silva <626206+guihkx@users.noreply.github.com>
Some systems (e.g. Ubuntu 22.04, which we use to make the AppImage),
have ancient versions of meson and ninja, which is not good when we
have dependencies like PyGObject 3.47+ (and more recently, one of its
transitive dependencies, pycairo 1.27+) requiring a fairly recent
version of meson to be able to be built.
So, instead of relying on whatever meson/ninja version the current
system provides us with to make the AppImage, this change will simply
install up-to-date, official wheels of meson/ninja directly from PyPI.
This also allows us to finally unpin PyGObject's version.
Ubuntu 20.04 only has Python 3.8, and because the 'truststore'
dependency requires at least Python 3.10, the AppImage package would
need to bundle CA certificates from 'certifi' to make HTTPS requests
work at all, which is quite an ugly workaround.
Unfortunately, as a side effect, building on Ubuntu 22.04 increases the
minimum required version of glibc from 2.31 to 2.35.
AppImage is a more flexible packaging solution for Linux than what
PyInstaller currently offers.
Some of the benefits are:
- Ability to ship the app with predefined environment variables
(solving issues like #321)
- Improved integration with the desktop environment (if you're using
go-appimage[1] or libappimage[2])
- Much lighter in size (~27 MB difference)
To actually make the AppImage, I'm using appimage-builder[3], which
makes the process a bit easier.
For more details about the AppImage technology, check out their
website[4].
[1] https://github.com/probonopd/go-appimage
[2] https://github.com/AppImageCommunity/libappimage
[3] https://appimage-builder.readthedocs.io/en/latest/index.html
[4] https://appimage.org/
