- Comment out push and pull_request triggers
- Keep workflow_dispatch for manual runs only
- Prevents automatic builds on every push
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Fix CI workflow to reference src/version.py instead of version.py
- Update Python import paths for version extraction in AppImage job
- Fix Dockerfile to use requirements.txt and copy src/ directory
- Remove deprecated --web flag from Docker CMD
- Remove obsolete version: '3.8' from docker-compose.yml
- Add Docker build job to CI workflow with multi-arch support (amd64, arm64)
- Push Docker images to GitHub Container Registry (ghcr.io)
- Add OCI image labels with build metadata to Dockerfile
- Update README with pre-built Docker image instructions
- Update funding information
All changes ensure compatibility with the refactored src/ package structure
and enable automated Docker image publishing via GitHub Actions.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
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.
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.
The reference AppIndicator implementation has been deprecated/abandoned in newer distros.
Co-Authored-By: Guilherme Silva <626206+guihkx@users.noreply.github.com>
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.
This fixes the following error when you launch the app with an emoji
font installed (e.g. Noto Emoji):
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 139 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 277
Current serial number in output stream: 300
This has been fixed[1] in libXft 2.3.5[2], but unfortunately Ubuntu
20.04 (which we currently use in the Linux CI workflow), still has
version 2.3.3, so we have to build it ourselves.
[1] https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/12
[2] https://lists.freedesktop.org/archives/xorg-announce/2022-September/003209.html
