* 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
Follow-up to #16072, as requested in review.
Converts the one-line non-free.list entry to a deb822 non-free.sources
block matching mylar3 and sabnzbd, and renames the cleanup rm to match
the new filename.
Also drops the redundant main and contrib components, which the base
debian.sources already provides. Declaring them a second time made apt
emit "Target Packages ... is configured multiple times" warnings on
every build; only non-free is needed for unrar.
Co-authored-by: Tim Moore <tim.moore@ingenuity.com.au>
Co-authored-by: Claude Opus 5 <noreply@anthropic.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
Both scripts provision Debian 13 containers (var_version 13) but add a
Debian 12 (bookworm) non-free apt source to obtain unrar.
Because the base image only enables the `main` component, trixie's
non-free is never enabled, so bookworm is the only source offering
unrar and the containers deterministically install the Debian 12 build
(1:6.2.6-1+deb12u1) instead of trixie's 1:7.1.8-1.
Mylar3 additionally never removes the source, leaving bookworm
non-free and non-free-firmware permanently enabled at priority 500 on
a Debian 13 system.
Aligns both with install/sabnzbd-install.sh, which already sets up the
same unrar dependency correctly against trixie.
Co-authored-by: Tim Moore <tim.moore@ingenuity.com.au>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* 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
The container was switched from bookworm to trixie in #16036, but
software-properties-common does not exist in Debian 13. apt aborts the
whole dependency line on the single missing package (exit code 100), so
a fresh install never gets past "Installing Dependencies".
The package only provides add-apt-repository, which this script never
calls — no PPAs or custom repos are configured anywhere. It is a dead
dependency, so dropping it needs no replacement; every other package on
that line exists in trixie.
Fixes#16053
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Install Java via setup_java instead of distro openjdk
Apache Tika's Java runtime was installed by calling apt directly for
openjdk-17-jre-headless. This tied the JDK to whatever Debian ships, and
that coupling has now broken: openjdk-17 is no longer available on Debian
13 (Trixie), where openjdk-21 is current. It also made this the only
script in install/ that installs Java by hand, while every other Java
application in the repository uses the shared setup_java helper.
Switch to setup_java, which installs Eclipse Temurin from the Adoptium
repository. Temurin is versioned independently of the Debian release, so
a future distribution upgrade cannot remove the JDK out from under the
application the way this one did.
Java 21 satisfies both current and upcoming Tika: 3.x requires Java 11 or
newer, and 4.x raises the floor to Java 17.
The surrounding msg_info/msg_ok pair is dropped because setup_java emits
its own progress messages; keeping them would nest the output.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Bump Apache-Tika container to Debian 13
The container declared Debian 12 (Bookworm) as its base, which had become
an outlier: 475 of the repository's ct scripts target Debian 13 and only
22 still target 12. build.func also sets trixie as the default ARM64
template codename, so this script's declared base had drifted away from
the repository default.
The declared version is not cosmetic. check_container_os_guard() reads
var_os/var_version as the script's recommended OS and compares them
against a container's /etc/os-release, prompting on interactive runs and
aborting headless ones when they disagree. Debian 12 was also the reason
the previous openjdk-17 dependency looked valid; on Debian 13 that
package no longer exists, which is addressed in the preceding commit.
Existing Debian 12 containers keep working, because update_script only
replaces the Tika jar and never touches the operating system or Java.
They will, however, now hit the OS mismatch guard on update and be asked
to move to Debian 13 first. That is intended rather than a regression,
but it is a visible change for existing users.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
