* Pin NextCloudPi installer to last known-good stable release
The floating "master" branch of nextcloud/nextcloudpi's install.sh
started rejecting our default Debian 12 base with "distro not
supported" (#15944) after a regression landed upstream; the script
is third-party code we don't audit or control. Pin to v1.57.1, the
latest stable (non-prerelease) release, which explicitly targets
Debian bookworm and predates the regression.
* Actually pin the branch nextcloudpi's install.sh clones internally
install.sh is only a thin bootstrapper: it clones BRANCH (default
"master") of the nextcloudpi repo itself and runs the real installer
from that fresh checkout, including the distro-support check. Fetching
install.sh from a pinned tag alone left BRANCH defaulting to "master",
so the internally-cloned code was unaffected and still failed with
"distro not supported" - confirmed by testing the previous fix. Pass
BRANCH explicitly so the internal clone also targets the pinned tag.
* Bump NextCloudPi to Debian 13, matching upstream's trixie move
Upstream's master ncp.cfg now targets release "trixie" (Debian 13);
bookworm (Debian 12) is no longer in the supported check_distro list
at all. Move our own default to Debian 13 and pin the installer ref
to v1.58.0-rc1, the only tagged ref with release=trixie so far (no
stable trixie release exists yet upstream).
* Revert installer pin, track master again
master now targets trixie itself (matches the Debian 13 bump), and
the only tagged trixie ref was an RC explicitly marked "expect bugs".
Tracking master gets upstream trixie fixes as they land instead of
being stuck on a stale test release.
* Work around nextcloudpi's broken ssh.socket restart on Debian 13
Debian 13's openssh-server ships socket-activated by default. NCP's
own bin/ncp/NETWORKING/SSH.sh detects that (systemctl is-active
ssh.socket) but then runs "systemctl restart ssh" in that branch
instead of reloading, which collides with the port ssh.socket already
holds and fails with "Job for ssh.service failed" (#15944). Switch the
container to classic ssh.service before handing off to their
installer so it takes the safe "systemctl reload ssh" branch instead.
* Add obsidian-livesync (ct)
* Update ct/obsidian-livesync.sh
Co-authored-by: Sam Heinz <sam@samheinz.com>
* Fix source line for build.func in obsidian-livesync.sh
Updated the source line to always fetch build.func from the specified URL.
---------
Co-authored-by: push-app-to-main[bot] <203845782+push-app-to-main[bot]@users.noreply.github.com>
Co-authored-by: CanbiZ (MickLesk) <47820557+MickLesk@users.noreply.github.com>
Co-authored-by: Sam Heinz <sam@samheinz.com>
* remove portainer from tools.func
* remove comment in tools.func and remove portainer from docker setup
* remove portainer from alpine-docker
* formatting alpine docker
* remove portainer update in docker ct and homeassistant
* fix(romm): remove stale 1.x alembic migrations on update
RomM releases before v2.4 shipped dot-version migration files
(1.6.2_.py, 1.7.1_.py, 1.8_.py, 1.8.1_.py, 1.8.2_.py, 1.8.3_.py,
2.0.0_.py) alongside the 4-digit series. When the romm app is
upgraded from a pre-v2.4 install to a current release, these
files survive in /opt/romm/backend/alembic/versions/ and cause
alembic to fail with 'Multiple head revisions are present for
given argument head', preventing the backend from starting.
Add a defensive cleanup step in the update function that runs
right after fetch_and_deploy_gh_release. The cleanup removes any
leftover 1.x and 2.0.0_ migration files plus cached __pycache__
directories. It is a no-op on clean installs of the current
release, and only affects files in the alembic/versions/ folder.
* Apply suggestion from @CrazyWolf13
Co-authored-by: Tobias <96661824+CrazyWolf13@users.noreply.github.com>
---------
Co-authored-by: Sam Heinz <sam@samheinz.com>
Co-authored-by: Tobias <96661824+CrazyWolf13@users.noreply.github.com>
* UmlautAdaptarr: use the Debian 13 Microsoft repo with its 2025 signing key
The container is Debian 13 (var_version 13) but the script configures the
Microsoft debian/12 prod repo with suite bookworm.
The move to debian/13 was reverted in #8392 because apt reported "OpenPGP
signature verification failed" (#8385), diagnosed at the time as Microsoft
not having populated the trixie repo. The actual cause was the signing key:
debian/13/prod is signed by EE4D7792F748182B (microsoft-2025.asc), while the
script kept microsoft.asc (EB3E94ADBE1229CF). The suite and URL were changed
but the key was not.
The trixie repo carries the required packages at current patch level
(dotnet-sdk-8.0 8.0.423-1, aspnetcore-runtime-8.0 8.0.29-1).
This makes the call identical to the six other scripts already on the
Debian 13 Microsoft repo (technitiumdns, igotify, mail-archiver, rdtclient,
fileflows, immichframe).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* UmlautAdaptarr: migrate existing containers to the Debian 13 repo on update
Per review feedback: the install-side fix only helps new containers.
Existing ones keep the Debian 12 repo indefinitely, because update_script
only fetches a GitHub release and never touches apt.
Repoints them when the stale Debian 12 repo is detected, mirroring the
conditional setup_deb822_repo calls in ct/technitiumdns.sh and
ct/fileflows.sh. The guard makes this a no-op once migrated.
setup_deb822_repo's microsoft* globs also clear the pre-#9839
microsoft-prod.sources layout; its key lived in /usr/share/keyrings,
which cleanup_old_repo_files does not cover, so it is removed explicitly
as ct/technitiumdns.sh does.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Tim Moore <tim.moore@ingenuity.com.au>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* fix(bazarr): store data in /var/lib/bazarr instead of inside /opt/bazarr
The installer creates /var/lib/bazarr and update_script() uses it as the
"is Bazarr installed" guard, but nothing pointed Bazarr at it. Bazarr
defaults its data directory to <install dir>/data, resolved from its own
source file rather than WorkingDirectory, so a stock container kept
config/ db/ backup/ cache/ log/ restore/ in /opt/bazarr/data - the
directory fetch_and_deploy_gh_release redeploys over - while
/var/lib/bazarr stayed empty.
Pass -c /var/lib/bazarr in the unit, matching the -data= flag the other
*arr scripts use. bazarr.py re-execs its child with sys.argv[1:], so the
flag survives the restart Bazarr performs while loading its config.
update_script() gains a one-time migration for existing installs. It runs
outside the release check so containers already on the latest version are
migrated too, is skipped when the unit already names a data directory,
refuses (before stopping the service) when both locations hold data, and
copies before removing so a failed migration leaves the original database
in place.
Fixes#16097
* fix(bazarr): drop explanatory comments per review
* Pin Vikunja install/update to v2.3.0
Set both install and update scripts to deploy Vikunja v2.3.0 instead of latest. The update flow now checks against this pinned release and includes context that v2.4.0 is temporarily avoided due to an upstream startup failure caused by the packaged systemd SystemCallFilter.
* minor fix
CanbiZ (MickLesk)