Only Vulkan and CPU (plus Intel SYCL) builds are installed now. Benchmarks
show Vulkan generally matches or beats the ROCm build for llama.cpp (except
some prompt-processing cases), while ROCm is far more complex to provision:
the prebuilt HIP backend needs a matching ROCm runtime, and consumer/iGPU
architectures such as gfx1150 additionally require HSA_OVERRIDE_GFX_VERSION
because rocBLAS ships no kernels for them. Vulkan drives NVIDIA, AMD, and
Intel GPUs on Linux with none of that setup, so auto-detection now selects
the Vulkan build for any supported GPU and the CPU build otherwise.
Installs prebuilt llama.cpp binaries from GitHub releases on AMD64/ARM64,
defaulting to the latest release or an explicit tag. Auto-detects the GPU
(sysfs PCI vendor IDs, lspci/nvidia-smi fallback) and picks ROCm, Vulkan,
or a plain CPU build, with a graceful fallback chain; NVIDIA GPUs get the
Vulkan build since upstream ships no CUDA build for Linux. Extracts into
<destdir>/lib/llama.cpp and symlinks the executables into <destdir>/bin
(the binaries carry RUNPATH "$ORIGIN"). Accelerator overridable via flags
or PHOTOPRISM_LLAMA_ACCEL; optional LLAMA_SHA256 verification.
Follow-up to the contributor change that moves shell customization out of
per-user home directories:
- Migrate the resolute, trixie, and questing (+ slim) dev images to the
shared install-bashrc.sh; the shared create-users.sh now hands users a
minimal skeleton, so images still writing to /etc/skel/.bashrc would
otherwise lose their aliases and prompt.
- Restore export PATH="$PATH:$HOME/.local/bin" (needed for claude/gh) in
the full dev images by writing it to /etc/bash.bashrc; kept out of the
slim and production images, which never had it.
- Guard the /etc/skel/.config copy in create-users.sh so production images
without it don't emit a spurious error, and use rm -f /root/.bashrc.
- Fix the install-bashrc.sh header reference and silence an intentional
SC2016 on the runtime-expanded PS1.
Stage each download in a temporary file and verify it against the SHA-256 published by the upstream release (s6-overlay per-asset .sha256, yt-dlp SHA2-256SUMS) before installing. Abort on mismatch and warn when no manifest is published so older pinned tags still install.
Add a vulkan target to scripts/dist/Makefile so PHOTOPRISM_INIT="vulkan"
installs mesa-vulkan-drivers and vulkan-tools directly, and extend
install-gpu.sh to provision the Mesa Vulkan drivers for detected Intel and AMD
GPUs plus vulkan-tools for NVIDIA verification.
libheif 1.21 renamed the CLI binaries: heif-convert is now a symlink to
heif-dec and heif-thumbnailer is no longer shipped at all. Updating the
header and inline comments in install-libheif.sh and build-libheif.sh
to match what the scripts actually produce on current libheif releases.
When invoked as "sudo bash install-nodejs.sh" by an unprivileged user, "~"
expanded to the calling user's home before sudo elevated, so root's
".npmrc" ended up with "cache=/home/<user>/.cache/npm" and subsequent
"sudo npm install -g" runs left root-owned cache dirs inside the user's
home. Hardcode the path so the cache always lands under root.
install-chrome.sh now pins Debian Bookworm to apt priority 100 with
chromium-* elevated to 990, preventing apt from "upgrading" unrelated
Ubuntu packages like libjpeg-dev to Bookworm's higher-versioned one
(which would pull libjpeg62-turbo-dev and collide with Ubuntu's
libjpeg-turbo8-dev). The conflict affected all Ubuntu+Bookworm-
chromium ARM64 builds; Resolute happened to surface it first.
The Resolute Dockerfiles now install libheif (1.21.2) from the
Resolute apt repo and explicitly pull the codec plugins, replacing
the older 1.20.2 archive previously fetched by install-libheif.sh.
Signed-off-by: Michael Mayer <michael@photoprism.app>
Ubuntu 26.04 ("resolute") and Debian trixie+ no longer ship the
"cgroupfs-mount" package — modern systemd handles cgroup v2 mounting
natively. With the package gone from the index, the existing
"apt-get install" line aborted with:
E: Package 'cgroupfs-mount' has no installation candidate
before Docker itself was installed. Probe the index via "apt-cache show"
and include the package only when it is actually available; older
distros that still ship it are unaffected.
Two issues prevented the script from running cleanly when piped into
sudo (the most reliable invocation over SSH):
1. The header recommended `bash <(curl …)`, but with sudo the process
substitution opens /dev/fd/63 in the unprivileged parent shell and
the elevated bash cannot read it — the script aborted with
`bash: /dev/fd/63: No such file or directory`. Replace with the
`curl -fsSL … | sudo bash` pattern (and keep an explicit
download-then-run fallback). Also call out the broken sudo + process
substitution form so users do not retry it.
2. With stdin piped to bash, `gpg --dearmor` tried to write status to
/dev/tty and failed with `gpg: cannot open '/dev/tty'`, breaking the
keyring import (and silently leaving an empty keyring on a fresh
host). Pass `--no-tty --batch --yes` to both gpg calls.
Tested end-to-end on Ubuntu 26.04 ("resolute") via
`curl -fsSL …/install-chrome.sh | sudo bash` from a clean state
(no preexisting keyring or apt list): keyring valid OpenPGP file, deb
fetched and installed, `google-chrome --version` returns 147.0.7727.116.
- Flag <name>.ServeHTTP(<writer>, c.Request) calls without a nearby
LimitRequestBodyBytes so SDK-delegated handlers (MCP today, future
SDKs tomorrow) are held to the same body-cap contract as BindJSON.
- Also flag direct reads via io.ReadAll, io.LimitReader,
json.NewDecoder, xml.NewDecoder, and yaml.NewDecoder on c.Request.Body
Signed-off-by: Michael Mayer <michael@photoprism.app>
Set BUILDKIT_STEP_LOG_MAX_SIZE=5 MiB and BUILDKIT_STEP_LOG_MAX_SPEED=10 MiB/s
on both the local and remote ssh://arm multibuilder nodes so long apt-get
transcripts on unstable Ubuntu bases aren't truncated during preview builds.
