James Coleman
d11a525008
- Releases now include Midi-Harbor-<version>-<x86_64|aarch64>.AppImage, built from the same binary as the packages and listed in checksums.txt, for distributions without a .deb or .rpm. Opened with no arguments it shows the window, and the daemon it registers runs under the systemd user unit like a package install. - service install run from an AppImage registers the .AppImage file instead of the executable inside the runtime's temporary mount, which is gone once the process exits. The file is used only when the running executable is inside APPDIR, so a program started from another AppImage, whose APPIMAGE it inherits, still registers itself. - The AppImage carries only the Avahi client libraries from the Debian 12 sysroot, with their LGPL-2.1 license, found through the binary's RUNPATH rather than LD_LIBRARY_PATH; glibc 2.35 or newer, ALSA, D-Bus and libxkbcommon come from the host, as for the packages. - Its AppRun starts the binary as midi-harbor, so on X11 the window's class matches the desktop entry instead of the AppImage's file name. - Building it needs the cross image's new patchelf, file, appimagetool 1.9.1 and type2 runtime 20251108, pinned by checksum, and a sysroot rebuilt to carry Avahi's license; the script stops and names make build-sysroot when that license is missing.
8 lines
511 B
Bash
Executable file
8 lines
511 B
Bash
Executable file
#!/bin/bash
|
|
# Starts Midi Harbor from inside its AppImage, under the name midi-harbor.
|
|
#
|
|
# The AppImage runtime passes the AppImage's own path as argv[0], and on X11 the window's class
|
|
# is taken from argv[0], so without this the class would be the AppImage's file name and no
|
|
# desktop would pair the window with its entry, whose StartupWMClass is midi-harbor. exec keeps
|
|
# the process, so systemd's main process and the runtime's mount stay as they are.
|
|
exec -a midi-harbor "${0%/*}/usr/bin/midi-harbor" "$@"
|