Use CLEAN_INSTALL with create_backup/restore_backup so stale v0.19.x source files no longer break go build after the integrations migration. Also set up the plugins directory and install official WASM bundles.
Add optional tag prefix filtering to GitHub/GitLab release helpers and use web-v2 for Storyteller install/update so latest non-web tags no longer break deployment.
* Update tools.func
- Add _TOOLS_FUNC_LOADED guard to prevent double-sourcing
- Remove duplicate is_alpine() (core.func version is more robust)
- Fix end_timer: now actually outputs duration (was silent)
- Fix SQL injection in setup_mariadb_db: escape single quotes in identifiers
- Fix SQL injection in setup_postgresql_db: escape single quotes in identifiers
- Fix sed injection in edit_yaml_config: escape | and & in value
- Fix command injection in curl_with_retry: use array instead of string eval
- Fix command injection in curl_api_with_retry: use array instead of string eval
* Update misc/tools.func
Co-authored-by: Sam Heinz <sam@samheinz.com>
---------
Co-authored-by: Sam Heinz <sam@samheinz.com>
* fix(hyperion): keep service running after container reboot
The packaged hyperion@.service declares "Requisite=network.target" but is
not ordered After=network.target. Inside an LXC the unit's start job can be
evaluated before network.target is active, and because Requisite= is stricter
than Requires= (it does not pull the unit in or wait for it) the job fails
with "Dependency failed", so Hyperion does not start after a reboot.
Add a systemd drop-in that clears Requisite=; ordering is still provided by
the base unit's Wants=/After=network-online.target.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix Hyperion service startup issue in LXC
Remove Requisite from Hyperion service to ensure it starts correctly in LXC environments.
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: CanbiZ (MickLesk) <47820557+MickLesk@users.noreply.github.com>
* fix(fileflows): install .NET 10 ASP.NET Core Runtime to match current release
FileFlows now ships its server/node binaries targeting .NET 10
(Microsoft.NETCore.App 10.0.0), but the install script still installs the
ASP.NET Core Runtime 8.0. On a fresh install the app therefore cannot start:
You must install or update .NET to run this application.
Framework: 'Microsoft.NETCore.App', version '10.0.0' (x64)
The following frameworks were found:
8.0.28 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
so "dotnet FileFlows.Server.dll --systemd install" fails with exit code 150
(service failed to start) and the container aborts (issue #15686).
Bump the runtime to 10.0 on both branches: aspnetcore-runtime-10.0 from
packages.microsoft.com on amd64 (the same repo and package already used by
igotify, rdtclient and technitiumdns) and dotnet-install --channel 10.0 on
arm64.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(fileflows): ensure current .NET runtime on update too
An existing install set up under an older .NET (e.g. aspnetcore-runtime-8.0)
would download a newer FileFlows on update but keep the old runtime, failing to
start with the same framework-not-found error. Mirror the runtime handling used
by technitiumdns/rdtclient in update_script.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
AdventureLog's frontend install runs a bare `pnpm i`. On pnpm v10+, build
scripts of dependencies (esbuild, es5-ext, svelte-preprocess) are ignored by
default and pnpm aborts with ERR_PNPM_IGNORED_BUILDS (exit 1), so the install
never reaches `pnpm build`. The shipped frontend/pnpm-workspace.yaml already
pins esbuild, so those builds are expected to run.
Enable the builds for this app only by appending `dangerouslyAllowAllBuilds:
true` to the frontend's pnpm-workspace.yaml before `pnpm i`, in both the install
and update paths. The change is guarded so it is not duplicated on re-run, and
it is scoped to AdventureLog (which ships no onlyBuiltDependencies) to avoid the
global config conflict that a repo-wide setting would cause.
Fixes#15670
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Michel Roegl-Brunner