Confirmed live: a plain-user curl against /var/run/wolf/wolf.sock failed
with "Immediate connect fail ... Permission denied". The socket is
srwxr-xr-x root:root - Docker auto-creates the host-side /var/run/wolf
bind-mount source as root, and Wolf itself runs as root in its
container, so group/other never had write permission on the socket file
(required to connect() to a unix socket, not just read/traverse it -
`ls -la` on the containing dir working fine was a red herring).
Fix: sudo on both curl calls, matching how every other root-owned Wolf
state file ($WOLF_CFG) is already touched elsewhere in this script via
`sudo python3 -`. Documents the sudo prompt in the README too.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Spells out what the three controllers_override values actually create
(Xbox One, PS5 DualSense, Switch Pro Controller - confirmed against
inputtino's own source, not just the enum names) instead of leaving the
reader to guess from bare AUTO/XBOX/PS/NINTENDO tokens, plus a note that
forcing a non-matching type only affects on-screen button-prompt
artwork, not functionality.
Adds a 4-controller section: Cemu's own Input Settings goes up to 8
slots and Wolf's wire protocol has no hardcoded 4-controller cap
(confirmed against control/input_handler.cpp), so the ceiling in
practice is the Moonlight client's own limit. With only 3 concrete
forced types available, a 4th controller can't get a guaranteed-unique
GUID - documents the one-at-a-time Cemu binding workaround for that
case, flagged as reasoned but not confirmed live.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Root cause (confirmed against inputtino's own uinput device-creation
source, and against Wolf's real virtual-pad architecture): every
virtual gamepad Wolf creates of the same type gets an identical SDL
GUID, since a GUID identifies a controller model, not a physical
instance - the same behavior two real identical controllers would have.
This isn't a Cemu bug specifically; it's why any app whose own
controller picker keys off GUID (Cemu confirmed live) can't reliably
tell two same-type Wolf pads apart, driving every player from
controller 1.
Wolf's own per-client `controllers_override` setting sidesteps this at
the root by forcing each controller slot to a genuinely different pad
type (e.g. slot 1 = Xbox, slot 2 = PlayStation), so their vendor/product
IDs - and SDL GUIDs - actually differ. `./manage.sh controllers` drives
this via Wolf's real REST API (confirmed against its OpenAPI schema,
not its docs page's own stale example command) rather than hand-editing
config.toml: lists paired clients, prompts for a pad type per slot, and
POSTs the update. Needs Wolf's API socket exposed to the host
(WOLF_SOCKET_PATH + a /var/run/wolf bind mount, matching Wolf's own
documented pattern), added to the wolf service's docker-compose.yml.
Full flow verified with a standalone test harness (mocked curl against
real API response shapes, a real AF_UNIX socket file) covering: single-
vs multi-client selection, invalid selection, invalid slot count,
lowercase/unrecognized type input, and the missing-socket path.
Also documents live user feedback that AntiMicroX (added last session)
is confirmed not working for TI-99/4A - flagged in the README rather
than left silently unverified, with this fix noted as the actively
maintained path for the multi-controller problem instead.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
The PCEE2 libretro core (a separate, actively-developed PCSX2 port,
WizzardSK/pcee2-libretro) is only in ES-DE's own bundled es_systems.xml
as of 3.5.0, which hasn't been released yet - confirmed against ES-DE's
own CHANGELOG.md and by diffing the v3.4.1 tag's real ps2 system block
against git master's (identical except for this one missing <command>
line). ghcr.io/games-on-whales/es-de:edge always installs the latest
*released* AppImage (confirmed against gow's own Dockerfile, which
queries GitLab's releases API), so the container this repo runs
genuinely has no PCEE2 entry at all yet - not a missing core download,
a missing menu entry.
Backfills it via the same esde-custom-systems/es_systems.xml mechanism
already used for the TI-99/4A and Wii U customizations, replicating the
real v3.4.1 ps2 block verbatim plus the one new command (as the default,
matching upstream's own placement). The core file itself needs no extra
handling - confirmed live against the libretro buildbot that
pcee2_libretro.so.zip is already covered by the normal RetroArch cores
pre-download.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
AntiMicroX maps gamepad buttons to synthetic keyboard/mouse events -
useful here because ti99sim-sdl's own joystick handling only ever emits
digit keys 1-9 for a raw button (confirmed against its source), with no
path to 0/Enter/Q/Esc, and because it's a plausible angle on Cemu not
reliably telling apart two Wolf virtual pads that share an SDL GUID.
Scoped to just these two ES-DE systems via a second, separately-labeled
"(AntiMicroX)" <command> alongside each one's existing default - ES-DE's
own multi-command "alternative emulators" mechanism - rather than
touching every system. Each launches through a small wrapper script
that starts AntiMicroX hidden (--no-tray --hidden --eventgen uinput,
flags confirmed against AntiMicroX's own commandlineutility.cpp source)
against a profile the user builds themselves via AntiMicroX's own GUI in
the Desktop/XFCE app, execs the real emulator, and kills AntiMicroX on
exit.
AntiMicroX needs /dev/uinput to inject events under ES-DE's Sway/Wayland
session (its XTest backend needs Xwayland, not present here), so the
esde catalog entry now requests it via both GOW_REQUIRED_DEVICES and a
real device grant - and make_app_block/the reinstall-update path both
learn to read/refresh a per-app 'devices' field instead of always
emitting an empty array, so this actually reaches an existing install on
a rerun, not just a fresh one (verified live against a synthetic
pre-uinput-era config.toml).
Also fixes a latent whitespace-eating bug in every custom_systems
strip-and-reappend regex in this file (trailing \s*\n? reached into the
next sibling block's leading indentation once two custom systems
coexist in the same file) - cosmetic only, but it would have made every
rerun churn indentation between the ti994a and wiiu blocks. Caught and
verified via a standalone test harness exercising all four
strip-and-reappend blocks together across repeated passes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Joystick buttons beyond the first only reach digit keys 1-9 in
ti99sim-sdl's own source (src/sdl/ti994a-sdl.cpp) - there's no path to
0, Enter, Q, or Esc from a gamepad. Documents the real Esc-to-exit
behavior and full FCTN key row (Alt+1 through Alt+9, Alt+=), both
confirmed against the emulator's own bundled doc/README.html.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
ti99sim-sdl supports --fullscreen directly (confirmed via its own
--help output) — add it to the launch command so TI-99/4A games open
fullscreen the same way every other standalone emulator here does,
instead of a small windowed default.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
The README's "Return to launcher: Ctrl+Alt+Shift+W or START+UP+RB" was
wrong on both counts — confirmed live the controller combo did nothing.
The real, standard Moonlight client shortcuts (confirmed against
Moonlight's own documented shortcuts, not Wolf-specific) are
Ctrl+Alt+Shift+Q on a keyboard and Back/Select+Start+LB+RB pressed
together on a controller. Fixed in all three places this text appeared.
Also documented the actual working procedure for configuring a Cemu
controller and TV audio device, worked out live this session: both need
to be done from the Desktop (XFCE) app rather than ES-DE, since Cemu's
own Settings dialogs don't render correctly in ES-DE's Sway kiosk
session but do in a real XFCE window manager. Desktop shares the same
~/.config/Cemu as ES-DE, so the config carries over. Also notes the
real fix for Cemu's TV-audio-device hang (a full Wolf restart, not just
reconnecting) that worked in testing, and that /ROMs is now mounted in
Desktop too (previous commit) so Cemu can load games directly from
there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
The 'desktop' catalog entry only ever mounted emulators/ and the
persistent home — /ROMs didn't exist in that container at all.
Confirmed live: with the controller fix requiring a real XFCE session
to reach Cemu's own working dialogs, there was no way to actually load
a ROM once there (Cemu's own File/Load menu had nothing to browse to).
Add the same /ROMs and saves mounts es-de/retroarch already use, so a
standalone emulator run from Desktop can load games directly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
install_wolf()'s own copy of the app-injection step used $APP_KEYS instead
of its actual variable $_APP_KEYS (the underscore-prefixed name is
install_wolf()'s own; APP_KEYS is manage.sh's separate copy's variable).
Confirmed live: under 'set -u' without 'set -e' this was a non-fatal
"APP_KEYS: unbound variable" error printed mid-install right after "Wolf
restarted with updated config" — the script kept going, but the
Steam-storage-location success message never printed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
ghcr.io/games-on-whales/xfce has no libfuse2/libfuse3 at all (checked
against its own Dockerfile) and, unlike es-de's Dockerfile (which sets
this exact env var), no fallback either. Confirmed live: launching Cemu's
AppImage from a terminal inside the Desktop session failed outright with
the standard "AppImages require FUSE to run" error, even though the same
AppImage runs fine when ES-DE launches it — es-de's container already
carries this env var, xfce's doesn't. Adding it makes every AppImage
self-extract into a temp dir and run from there instead of trying to
FUSE-mount itself, matching how ES-DE already handles them.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
update_field() only ever got called for 'mounts' and 'env' when an app was
already present in config.toml, so the games-on-whales/desktop -> xfce
image-name fix from the previous commit would NOT have reached anyone who
already has a (broken) Desktop entry — re-running the installer or
./manage.sh apps would keep refreshing mounts/env but silently leave the
old, 404ing image reference in place forever.
update_field's own array-reformatting logic (scan forward for a closing
']') isn't safe to reuse for a single-line scalar field like image or
icon_png_path — there's no ']' on that line, so the scan would run into
an unrelated array further down the same block (e.g. 'ports = []') and
corrupt it. Added a separate update_scalar_field() that only ever
replaces the exact matched line, and wired it in for both 'image' and
'icon_png_path' in both copies of this app-injector script (install-time
and manage.sh's own 'apps' command) — verified locally against a
synthetic config.toml block that it replaces only the targeted app's own
fields and leaves a neighboring app's identically-named fields untouched.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
ghcr.io/games-on-whales/desktop never existed. Confirmed live: Wolf logged
"[DOCKER] error 404 - No such image: ghcr.io/games-on-whales/desktop:edge"
and silently returned to the Moonlight app list with no other visible
error, making the Desktop tile look like it just didn't launch. The
games-on-whales/gow repo's apps/ directory names this app "xfce", and
ghcr.io/games-on-whales/xfce:edge is the real, currently published image
(confirmed against GHCR's own tag list for that package) — the icon path
uses the same "xfce" naming.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
The 'desktop' Wolf app (ghcr.io/games-on-whales/desktop:edge, full XFCE
session) had mounts=[] — no access to emulators/ or the persistent
.config/.local/share home ES-DE/RetroArch use. That meant there was no way
to run a standalone emulator like Cemu outside ES-DE's single-app Sway
kiosk session, which matters because a second top-level window from an
app (e.g. Cemu's own Settings/Input dialogs) can fail to ever get mapped
or focused there — confirmed live: clicking Cemu's General Settings
highlighted the menu entry but no dialog ever appeared, with no way to
recover control short of killing ES-DE.
Give Desktop the same emulators -> ~/Applications and retro-home(-data)
-> .config/.local/share mounts esde/retroarch already use, so Cemu (or
any other standalone emulator) can be launched directly from a real
multi-window XFCE session instead, using the exact same settings.xml the
next ES-DE-launched session will read.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
ES-DE's findEmulator() decides found-vs-not-found from the <command>
string's emulator token, and every real %INJECT%=...esprefix example in
ES-DE's own shipped es_systems.xml (Dolphin/PrimeHack/Triforce/Supermodel)
pairs it with an %EMULATOR_X%/%CORE_X% placeholder, never a literal path.
The previous ti994a <command> used a literal "/bin/bash -c ..." after
%INJECT%=%BASENAME%.esprefix, which ES-DE reported as "emulator not found"
even though /bin/bash obviously exists on the container.
Fix: give ti99sim-sdl a real custom_systems/es_find_rules.xml entry
(TI99SIM, staticpath ~/Applications/ti99sim-sdl) and reference it via
%EMULATOR_TI99SIM%, matching the pattern every built-in standalone
emulator uses. %STARTDIR%=%EMUDIR% replaces the old shell "cd && ..."
prefix to keep ti99sim-sdl's working directory at its own install dir,
where it looks up the console ROM via a plain relative path.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Confirmed live: the command-line fix from an earlier commit (cd into
emulators/ before launching ti99sim-sdl) never reached the user's actual
es_systems.xml, because the write step's guard was "skip entirely if a
ti994a entry already exists" — which it did, with the old pre-fix
command line still in it. The check only asked whether an entry existed,
never whether its content matched the current template.
Now always strips any existing ti994a <system> block and re-adds the
current one fresh on every run, via a small python3 rewrite (regex block
removal + re-append) instead of a blind append-once guard. Tested against
a stand-in file matching the real stale content, and for idempotency
(second run doesn't duplicate the block), before pushing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Confirmed live: RetroArch's system_directory on this Wolf setup is
"~/bioses" (GoW's own shipped default, confirmed by reading a real
retroarch.cfg directly — wolf.sh never sets this itself), not RetroArch's
usual default of ~/.config/retroarch/system. The Dolphin Sys-folder
automation added earlier this session assumed the usual default and wrote
to retroarch/system/dolphin-emu/Sys on the host — a path RetroArch's own
config never actually reads, so it would have sat there doing nothing.
Now reads the real configured system_directory value out of
retroarch.cfg instead of assuming, and self-heals by moving a Sys folder
that's already sitting in the old wrong location (from before this fix)
into the correct one. Also corrects the same wrong assumption in the
MAME samples-directory documentation, which pointed at the same
retroarch/system/ default.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
The build succeeded, but the follow-up message pointed at "ti99sim-sdl's
own README" for where the console ROM goes — useless, since that source
tree lived inside the throwaway build container and was already gone by
the time anyone could read it.
Got the real answer from RetroPie's own configure_ti99sim(): it symlinks
the console ROM into the emulator's own install directory, then cd's
there before launching (pushd "$md_inst" && ./ti99sim-sdl "$@") — so
ti99sim-sdl finds it via a plain relative lookup, not any search path.
Caught a real bug this exposed: our own ES-DE <command> line launched
ti99sim-sdl by full path with no cd, so even a correctly-placed file
would never have been found. Fixed to cd into emulators/ first, matching
RetroPie's own pattern exactly.
Also, instead of just printing the required path (emulators/TI-994A.ctg)
and leaving it at that, now prompts for it directly with a tab-completing
path picker (read -e -i, defaulting into the game storage dir) — if you
already have the file somewhere, it copies it into place immediately
instead of making you do it by hand afterward.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
You were right to push back on this earlier — the original ask was SDL2,
same as RetroPie, and I substituted a different thing (SDL1-compat) without
checking what RetroPie actually does first.
Checked RetroPie's own ti99sim.sh scriptmodule directly: it doesn't build
from billzajac/ti99sim (the GitHub fork the last two attempts used) at
all. It fetches upstream v0.16.0 straight from the original author's own
site (mrousseau.org), applies exactly one trivial patch (a missing
#include <cstring> for modern g++), and builds against libsdl2-dev +
libssl-dev directly — no SDL1 compatibility layer, because that source
genuinely supports SDL2 natively. The GitHub fork used previously was
just a stale, pre-SDL2-port copy under a different account.
Verified the download URL actually serves the real tarball (fetched real
binary content, confirmed the 7zXZ header) and the patch's exact content
before using either — same real-source-first standard as the wolf.sh
fixes earlier this session. Tested the sed insertion that replaces
applying the .diff against a stand-in file matching the patch's real
context before trusting it.
Also documents the exact BIOS-equivalent filename RetroPie's own docs
give for this emulator: TI-994A.ctg (case-sensitive) — a real, useful
detail that was missing before.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Confirmed live: the previous sdl-config shim got past the tooling
problem, but hit a much deeper one — ti99sim's SDL frontend
(src/sdl/main.cpp) is written against the actual SDL 1.2 API and uses
symbols SDL2 genuinely removed (SDL_keysym, SDL_WM_SetCaption,
SDL_EnableUNICODE, SDL_JoystickOpened, the old integer-index
SDL_JoystickName). No shim can paper over missing symbols — this needed
the real thing.
Swapped libsdl2-dev + the hand-rolled sdl-config shim for
libsdl1.2-compat-dev — the SDL project's own official compatibility
package (libsdl-org/sdl12-compat, packaged in Ubuntu's universe repo):
genuine SDL 1.2 headers and its own real sdl-config, implemented on top
of actual SDL2 underneath. The code compiles against the API it was
actually written for, while still running on modern SDL2 at runtime.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Confirmed live: the containerized ti99sim-sdl build (previous commit)
failed with "SDL.h: No such file or directory" — not a real
compatibility problem, ti99sim's own Makefile.linux calls the old SDL 1.x
sdl-config tool, which doesn't exist in modern libsdl2-dev packaging at
all (only pkg-config .pc files). Every sdl-config invocation was silently
returning nothing, so the compile got no -I/-L flags whatsoever.
Adds a small shim mapping the handful of flags this build actually uses
(--cflags/--libs/--version, tested standalone against a fake pkg-config
before pushing) onto `pkg-config sdl2`, rather than patching the
project's own Makefiles.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Fixes a cop-out from the previous commit — rather than just warning about
a possible glibc/SDL2 mismatch and handing the user a manual build guide,
build ti99sim-sdl inside a throwaway container running the exact same
image ES-DE itself runs (ghcr.io/games-on-whales/es-de:edge), which
actually eliminates the mismatch risk instead of just noting it. Runs
during install_wolf() when the TI-99/4A prompt is accepted, skips itself
if the binary's already present, and drops the result straight into
emulators/ti99sim-sdl ready to use.
Caught a real bug before pushing, not after: `make` alone leaves the
binary under ti99sim's own src/ directory, not the repo root (confirmed
against its README), so a naive `cp ti99sim-sdl` would have failed
outright. Uses `make install` instead — the project's own reliable way to
collect the binary (copies to /opt/ti99sim/bin, symlinks into
/usr/local/bin) — rather than guessing the exact build subpath.
The one piece that's still genuinely a manual step, and stays that way:
supplying your own TI-99/4A console ROM + GROM dump, real copyrighted
console firmware no installer can legally source for you.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Cemu: no libretro core exists (a third-party attempt was never merged and
there are no plans to per RetroArch's own issue tracker) — added as a
fourth standalone AppImage download, same pattern as Azahar/PCSX2/Dolphin.
Its official release asset is already named Cemu-<version>-x86_64.AppImage,
matching ES-DE's own find-rule directly, so no Dolphin-style rename/symlink
is needed. Flags a real supply-chain compromise of Cemu's own Linux release
assets around v2.6 (2026-05, since restored, per Datadog Security Labs)
and that most retail games need a user-supplied Wii U common key.
TI-99/4A: added as a genuine ES-DE system (not this repo's existing
js99er service, which is browser-based and can't be launched as an ES-DE
system) via a custom_systems/es_systems.xml, per ES-DE's own documented
mechanism for extending its built-in system list. Needed a new mount
(esde-custom-systems -> ~/ES-DE/custom_systems) since that path wasn't
covered by any existing .config/.local/share mount. The emulator itself
(ti99sim-sdl) is deliberately NOT auto-built — it ships no AppImage, and
compiling it on the host risks a glibc/SDL2 mismatch against the ES-DE
container's own runtime that isn't safe to guess at blind — so this
writes the system definition (cheap, correct, always useful) and gives
manual build+placement instructions instead of a build automation I can't
verify actually runs.
Also expands the BIOS callout to mention PS2 (configured inside PCSX2's
own settings, not auto-detected from bios/) and TI-99/4A (needs a real
console ROM+GROM dump, same legal situation as any other BIOS), and
documents the MAME sample-pack-vs-ROM confusion (identical .zip naming
convention makes them indistinguishable by filename alone; samples belong
in retroarch/system/<mame-core>/samples/, not roms/mame/).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Confirmed live: RetroArch's file browser and directory-scan importer both
failed to recognize SNES ROMs (.sfc) even though the ROM files and the
snes9x core .so were both genuinely present and correctly mounted — the
core's own .info file (which declares supported_extensions) was never
actually installed, because the "already present, skip" check for the
info.zip pack was "is $CORES_DIR non-empty", and $CORES_DIR is always
non-empty by the time that check runs (the core .so files fill it first,
earlier in the same `cores all` run). So the info-pack fetch silently
no-op'd on every single install, fresh or not — not specific to this
laptop.
Give "info" its own real check: does $CORES_DIR actually contain any
*.info files, not just anything at all.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Adds Option B (a personal GitHub App installed with "All repositories"
access) alongside the existing per-repo webhook instructions, and
clarifies that Homepage URL and Webhook URL are separate fields on the
App creation form -- a real point of confusion when setting one up.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016oxpDzv7qfV7RDvKHp1sPD
Confirmed live on a laptop with only its internal drive (no second/
unmounted disk at all): the game-storage-directory picker's `local -a
_UNMT_DEV _UNMT_LABEL _UNMT_UUID` declares the arrays but, when the lsblk
scan finds zero qualifying unmounted block devices, never actually assigns
an element to any of them. Under setup.sh's `set -u`, that's enough for a
later read (`${#_UNMT_DEV[@]}`) to throw "unbound variable" even though
the arrays were properly `local -a` declared — a known bash nounset quirk
this repo has already hit and documented once before (see
vendor/ai-stack/configure-searxng-safesearch.sh). Explicit `=()`
initializers side-step it. The sibling `_CAND_*` arrays a few lines above
don't need the same fix — they always get at least one element (the home
directory option is unconditional), so they can't hit this path.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
Extends `./manage.sh cores all` (and install_wolf()'s own cores prompt,
which calls it) to also pull the rest of what RetroArch's own Online
Updater offers — Slang shaders, overlays/bezels, cheat files, the RDB
game database, and controller autoconfig profiles — directly from the
same libretro buildbot the cores themselves come from
(buildbot.libretro.com/assets/frontend/). Confirmed live against the
real directory listing and each zip's actual internal structure (flat,
no wrapping folder) before writing the extraction paths, rather than
guessing: ~290 MB total, landing in retroarch/{shaders,overlays,cheats,
database,autoconfig}/ using RetroArch's own default paths for the three
config keys (cheat_database_path, content_database_path,
joypad_autoconfig_dir) this install leaves unset.
Thumbnails are deliberately excluded — they're hosted separately, are
per-system, and can run into many GB, so blindly grabbing "all systems"
would be a bad default; documented as a manual per-system pull via
RetroArch's own Thumbnails Updater instead.
Idempotent like the existing cores loop: skips a pack whose destination
directory already has content, unless `force` is passed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLX1yYKJExGSXmgUhxKQG6
add_authelia_user() and the per-user "Reset password" action always
auto-generated a random password with no way to set a specific one.
Adds _authelia_prompt_password(), a shared masked-input prompt (same
"[Enter = auto-generate]" convention already used by backup.sh/
borg-backup.sh/koha.sh) that both call sites now use, so an admin can
type their own password or fall back to auto-generation as before.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016oxpDzv7qfV7RDvKHp1sPD
Outis