@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.
* immich: keep geodata linked and the build deps present on update
The update wipes $APP_DIR before redeploying, which takes the geodata
symlink the install created with it, and never puts it back. The app
then finds no reverse-geocoding data and the web UI does not come up.
The library recompile assumes headers that only reached the install
list later, so a container built before that fails at the first missing
one - LCMS2 in the reported case.
* immich: keep geodata linked and the build deps present on update
The update wipes $APP_DIR before redeploying, which takes the geodata
symlink the install created with it, and never puts it back. The app
then finds no reverse-geocoding data and the web UI does not come up.
The library recompile assumes headers that only reached the install
list later, so a container built before that fails at the first missing
one - LCMS2 in the reported case.
