setup_uv was called with $INSTALL_DIR on the line before INSTALL_DIR
was ever assigned, causing every install to fail with:
bash: line 58: INSTALL_DIR: unbound variable
On the run in which steamcmd replaces itself, the app_update that follows fails
with 'Missing configuration', and the same command succeeds once it runs again.
A login-only run first takes that self-update out of the install and update.
The noavx2 requirements pin numpy 1.23.5 and onnx 1.14.1, neither of which ships
a cp312 wheel, so on 3.12 uv built them from source: numpy fails without
distutils and onnx without cmake. Every noavx2 pin has a 3.11 wheel.
@lobehub/ui 5.50.0 dropped NeuralNetworkLoading, and LobeHub 2.2.18 still imports
it through a ^5.47.0 range with lockfile: false, so every fresh build now fails.
Upstream moved off it on main; the pin only applies while package.json still asks
for a 5.4x range, so it stops on its own with the next stable release.
The repo also publishes web-clipper-v* releases, and whenever upstream marked one
of those as latest the update offered to replace the server with the browser
extension. A v prefix makes core pick the newest stable server release itself
instead of trusting that marking.
2.16.0 ships production.conf only as a template that its s6 prepare step renders,
so installs outside Docker never listened on 81; render it on install, on update
while keeping a custom admin port, and on update for containers already stuck on
2.16.0. Certbot's upgrade died on a dist-info without RECORD, which pip's own
--ignore-installed hint does not clear, so drop such records before upgrading.
RomM 5.3.0 dropped rq-scheduler (rommapp/romm@4e5921727), so
romm-scheduler.service fails with 203/EXEC on a missing
.venv/bin/rqscheduler. The same release moved scans to their own
"scans" queue (rommapp/romm@3593d2398), which the LXC worker never
listened on, so scans queued but never ran.
Match upstream's docker init: the scheduler service runs
`rq cron tasks.cron_config`, both workers run with --with-scheduler
so delayed jobs (watcher rescans) are released, and a new
romm-scan-worker.service consumes the scans queue.
The update script migrates existing units when romm-scheduler.service
still references rqscheduler. It runs before the release check, so
installs already on 5.3.x get repaired too.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Upstream renamed OBSIDIAN_VERSION in its Dockerfile to IGNIS_OBSIDIAN_PIN, so the
grep matched nothing - and under pipefail the assignment itself aborts, which is why
the fallback on the next line never ran. The tag already carries the pairing
(0.8.13+obsidian.1.13.7), so read it there and keep both Dockerfile keys as a
fallback.
* Docker-LXC: remove Portainer installation from install
Removed Portainer installation prompts and related code.
* Remove Portainer installation instructions from docker.sh
Removed instructions for installing Portainer as an addon.
Bo Bartlett