* Scripts: close every msg_info block with msg_ok
Past-tense msg_info calls that should have been msg_ok, notices that opened a block before a prompt, and blocks without a closing msg_ok. These already left a stale spinner; with core's block stack they would resume it after every later msg_ok.
* Generate passwords with random_password
openssl rand -base64 | tr -dc | head -c returned fewer characters than asked for, and the unfiltered | cut variants put / and + into passwords that end up in DSNs and sed expressions. Secrets an app decodes as base64 are unchanged. Requires community-scripts/core#61.
* Keep data directories through CLEAN_INSTALL instead of copying them
create_backup copied uploads, storage and similar directories twice per update and needed their size again in free space. CLEAN_INSTALL_KEEP moves them aside instead. Only directories the upstream release does not ship, in scripts that restored right after the fetch. Requires community-scripts/core#61.
* Drop the 300s uv timeout overrides
setup_uv exports UV_HTTP_TIMEOUT=600 now; the scripts' 300 only lowered it. Requires community-scripts/core#61.
* Use the release helpers instead of hand-rolled version checks and downloads
Legacy /opt/*_version.txt files move to ~/.<app> on the next update.
* homeassistant: use get_latest_github_release
The systemd service unit created by install/blocky-install.sh has
After=network.target and no restart policy. On a container where blocky
binds to a static IP and the interface is not yet configured when the
unit starts, blocky exits once with "bind: cannot assign requested
address" and stays dead. This was observed on Debian 13 LXC / PVE 9
after a host reboot: internal DNS was down until a manual restart.
Two fixes:
1. [Unit] After=/Wants=network-online.target: standard ordering,
prevents the start before the network is usable where a wait-online
provider exists.
2. [Service] Restart=on-failure + RestartSec=5: matches the existing
Restart=on-failure in install/traefik-install.sh; the 5s spacing also
overrides systemd's default start-rate limit (5 starts / 10 s) from
ending retries.
Verification:
1. Container reboot → blocky active with no manual intervention
2. SIGKILL → auto-restart within the restart interval
Co-authored-by: Fidel Ramos <contact.gyldd@8shield.net>
* fix(romm): snapshot Redis hourly like the upstream image
Redis' default save policy (3600 1 300 100 60 10000) rewrites the whole dump.rdb every 5 minutes on an idle RomM, because the RQ workers and scheduler change keys constantly. With the Switch TitleDB and PS2 serial caches the dump is ~50 MB, so an idle container writes ~14 GB/day. Upstream fixed this for the Docker image (rommapp/romm#3983, REDIS_SAVE_POLICY default "3600 1"), but that lives in docker/init_scripts/init, which the LXC install never runs. Apply the same policy on install and, for existing containers, on update unless a save policy is already set.
* Update ct/romm.sh
* Update install/romm-install.sh
---------
Co-authored-by: Michel Roegl-Brunner <73236783+michelroegl-brunner@users.noreply.github.com>
Only autocaliweb.service loaded $INSTALL_DIR/.env via EnvironmentFile.
The other three units never did, so any script they invoke falls back
to the Docker-oriented defaults baked into upstream (ACW_CONFIG_DIR=/config,
ACW_USER/ACW_GROUP=abc), none of which exist in this LXC install.
Confirmed via kindle_epub_fixer.py failing on both a missing /config
directory and a missing 'abc' system user during ingest.
linkding stores them in data/favicons and data/previews and upstream maps both
under /static next to the collected assets, with a sandbox CSP. The nginx site
only aliased the collected assets, so every downloaded image answered 404; the
update rewrites that block even without a new release.
Upstream's nginx.conf gained a resolver ${NGINX_RESOLVER} line that its Docker
entrypoint fills from /etc/resolv.conf; the script substitutes a fixed list of
placeholders, so the literal variable reached nginx and the config test failed.
Take the nameservers from resolv.conf the same way.
* fix: bump aurral Node.js requirement from 22 to 26
Upstream aurral now requires Node 26.x (engines: "26.8.x" in v2.10.0),
causing npm ci to fail with EBADENGINE when the install script sets up
Node 22.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: bypass npm engine-strict check for aurral build
aurral's .npmrc sets engine-strict=true and pins an exact node patch
(26.8.x), which NodeSource can never satisfy since it only ships the
latest patch per major (currently 26.10.0). Disable engine-strict for
the build, matching the ignore-engines workaround already used for
yarn-based apps in this repo (dashy, monica, excalidraw,
elementsynapse).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
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.
* scanopy: use prebuilt server binary, relax release profile for generate-fixtures
* scanopy: drop unneeded rust build, use committed UI fixtures
* scanopy: restore generate-fixtures build, ui/src/lib/data is gitignored and incomplete
* scanopy: serve the UI from the binary, drop the source build
Upstream confirmed in scanopy/scanopy#698 that scanopy-server-linux-*
has carried the built UI since v0.17.13, fixtures and service logos
included, served on the same port as the API. The release notes never
said so, which is why we kept building it.
That removes the source tarball, the Rust toolchain and
generate-fixtures, Node with npm ci and npm run build, and
SCANOPY_WEB_EXTERNAL_PATH. With the variable set to a directory that no
longer has an index.html, v0.17.14 and earlier refuse to start, so the
update deletes the line rather than leaving it. build-essential,
libssl-dev and pkg-config go too: the release binary is static-pie with
no INTERP segment, so it has no runtime library dependencies.
/opt/scanopy stays, now only for .env and oidc.toml, and the unit's
WorkingDirectory follows it out of the removed backend directory. Since
nothing wipes that directory any more, the config survives an update on
its own, which is the report upstream passed on of an update coming
back without SCANOPY_WEB_EXTERNAL_PATH and the server starting API-only.
The update keeps the running binary until the new one answers
/api/health and puts it back if it does not, so a bad release leaves a
working server instead of a stopped one.
check_for_gh_release now keys on scanopy-server, matching the version
file the binary deploy writes; the Scanopy key belonged to the tarball
that is gone. Existing containers run one extra update, then agree.
* Refactor scanopy-install.sh for server setup
Updated installation script to configure Scanopy server and removed daemon configuration section.
* Update service names from 'scanopy-server' to 'Scanopy'
* Fix case sensitivity in fetch_and_deploy_gh_release
* scanopy: make the rollback restore the whole old setup
The health check put the previous binary back but nothing else, and the
source tree it needs was already gone by then: the update deleted
/opt/scanopy/ui before starting the new server, and removed
SCANOPY_WEB_EXTERNAL_PATH from the env at the same time. A failed
health check therefore left the old binary running without the UI it
serves from disk, so the rollback produced an API-only server.
Back up the env file and the unit alongside the binary, restore all
three when the check fails, and delete the source tree only once the
new server has answered. Nothing the old version needs is removed
before the new one has proven itself.
* scanopy: name the deployed binary what the unit starts
singlefile mode writes the asset to <target>/<app name>:
local target_file="$app"
[[ "${USE_ORIGINAL_FILENAME:-false}" == "true" ]] && target_file="$filename"
so with the app renamed to Scanopy the binary lands at /usr/bin/Scanopy
while the unit starts /usr/bin/scanopy-server, and the service never
comes up on a fresh install. Rename it after the deploy, the same way
the daemon block already renames "Scanopy Daemon".
Keeping the app name is what matters here: it is also the version file
(~/.scanopy), and changing it would make every existing container
report an update it does not need.
CanbiZ (MickLesk)