Martin Bauer
331df52f0b
Raspberry Pi OS ships a 64-bit kernel with a 32-bit userland, so uname -m - and
therefore ansible_architecture - reports aarch64 on a box whose /bin/ls is
ELF32 ARM and which has no /lib/ld-linux-aarch64.so.1. The aarch64 uv tarball
unpacked happily and then failed three tasks later with
/usr/local/bin/uv: No such file or directory
which is the dynamic loader missing, not the file, and points at entirely the
wrong thing. Pick the target triple from ansible_userspace_bits instead, which
is the fact that tells the truth, and key the install directory on the triple as
well as the version - otherwise `creates:` would keep a wrong-architecture
binary in place forever. Then run `uv --version` right after installing it, so a
bad download fails where the cause is visible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
46 lines
2.3 KiB
YAML
46 lines
2.3 KiB
YAML
---
|
|
pi_musicmouse_repo: "ssh://git@git.bauer.tech:2222/martin/musicmouse.git"
|
|
# No default on purpose: which branch to run is a per-host decision, set in host_vars.
|
|
# The deploy/<host> branches on the remote are the intended values - move one with
|
|
# `git push -f origin <branch>:deploy/musicdolphin` and re-run this role.
|
|
# musicmouse_version: "deploy/musicdolphin"
|
|
|
|
pi_musicmouse_python_version: "3.13"
|
|
pi_musicmouse_uv_version: "0.12.10"
|
|
|
|
# Which uv build to download. Raspberry Pi OS ships a 64-bit kernel with a 32-bit
|
|
# userland, so `uname -m` (and therefore ansible_architecture) says aarch64 on a box
|
|
# that can only run armhf binaries - the aarch64 build installs fine and then fails to
|
|
# exec with "No such file or directory", which is the dynamic loader missing, not the
|
|
# file. ansible_userspace_bits is the fact that tells the truth.
|
|
pi_musicmouse_uv_target: >-
|
|
{{ 'armv7-unknown-linux-gnueabihf'
|
|
if (ansible_architecture in ['aarch64', 'armv7l', 'armv6l'] and ansible_userspace_bits == '32')
|
|
else _pi_musicmouse_uv_targets[ansible_architecture] }}
|
|
_pi_musicmouse_uv_targets:
|
|
aarch64: aarch64-unknown-linux-gnu
|
|
armv7l: armv7-unknown-linux-gnueabihf
|
|
armv6l: armv7-unknown-linux-gnueabihf
|
|
x86_64: x86_64-unknown-linux-gnu
|
|
|
|
# Where to check out the repo on the *control machine* to build the frontend (npm isn't
|
|
# installed on the Pi - see README). Keyed by version so different hosts on different
|
|
# versions don't clobber each other's build.
|
|
pi_musicmouse_build_cache: "/tmp/musicmouse-build-cache"
|
|
|
|
# Which files/config-*.yml to install as this host's /media/musicmouse/config.yml.
|
|
pi_musicmouse_config_file: "config-{{ inventory_hostname }}.yml"
|
|
|
|
# The app owns config.yml at runtime: parent mode writes the volume keys back to it, and
|
|
# the remote-control page rewrites its `remote:` block. So the config is installed once
|
|
# and then left alone, or every ansible run would silently undo those edits. Push a
|
|
# changed config deliberately:
|
|
#
|
|
# just run mediapis.yml musicdolphin -e pi_musicmouse_force_config=true
|
|
pi_musicmouse_force_config: false
|
|
|
|
# The typing game's lesson plan, installed next to config.yml. A config with a `tippen:`
|
|
# section will not start without it - curriculum_file is validated as must-exist. Set to
|
|
# "" for a host whose config has no tippen section.
|
|
pi_musicmouse_curriculum_file: "tippen-curriculum.yml"
|