simon/distrobox-images
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add davinci resolve image

Browse Source
This commit is contained in:
CI/CD
2026-09-09 11:50:57 +02:00
parent e512c3e4e3
commit 6869905017
9 changed files with 469 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored
View File

@@ -2,3 +2,5 @@
*.tar.gz *.tar.gz
*.tar.bz2 *.tar.bz2
*.iso *.iso
*.run
*.zip

35
README.md
View File

@@ -10,10 +10,9 @@ One self-contained folder per app:
``` ```
<soft>/ <soft>/
Dockerfile # often multi-stage: shared base + amd / nvidia variant Dockerfile # often multi-stage: shared base + amd / nvidia variant
build-and-push.sh # build + push to the registry <soft>-run # launcher installed in the image (app entrypoint)
<soft>-run # launcher installed in the image (app entrypoint) README.md # specifics: prerequisites, build + push, distrobox create, gotchas
README.md # specifics: prerequisites, licensing, distrobox create, gotchas
``` ```
No shared base image across different apps — each has its own system No shared base image across different apps — each has its own system
@@ -31,10 +30,8 @@ duplicate on principle.
## Private registry ## Private registry
Registry: `docker.slambin.fr`. If it's a real domain with TLS (reverse proxy The apps a meant to be pushed to the private registry: `docker.slambin.fr`.
+ cert) in front, nothing to configure on the container engine side — And then run using distrobox or podman.
`push`/`pull` just work. Only if the registry runs plain HTTP (e.g. a local
test without TLS) does it need to be declared "insecure":
```bash ```bash
podman run -d --name registry --restart=always \ podman run -d --name registry --restart=always \
@@ -42,27 +39,7 @@ podman run -d --name registry --restart=always \
registry:2 registry:2
``` ```
**podman** — `/etc/containers/registries.conf.d/local.conf`:
```toml
[[registry]]
location = "docker.slambin.fr"
insecure = true
```
**docker** — `/etc/docker/daemon.json`, then restart docker:
```json
{ "insecure-registries": ["docker.slambin.fr"] }
```
## Licensing / EULA
Several of these apps (Houdini included) are installed from a proprietary
binary downloaded with a personal account, and the EULA generally forbids
redistribution. The registry must stay **private** — never push an image
containing one of these binaries to a public registry.
## Apps ## Apps
- [`houdini/`](houdini/README.md) — Houdini Apprentice - [`houdini/`](houdini/README.md) — Houdini Apprentice
- [`davinci/`](davinci/README.md) — DaVinci Resolve

181
davinci/CLAUDE.md Normal file
View File

@@ -0,0 +1,181 @@
# DaVinci Resolve image — design notes
Context for whoever (Claude) touches this Dockerfile next. Simon doesn't need
to read this — it's implementation reasoning, not usage docs (those are in
`README.md`).
**Update 2026-09-09: the `amd` and `nvidia` targets both build successfully**,
tested with a real `DaVinci_Resolve_21.1_Linux.run` on Docker Desktop/WSL2
(Windows host, no distrobox available there). See "Build test" below for
what was actually verified and how. What's still unverified: an actual
`distrobox create` + `davinci-run` GUI launch on real Linux/GPU hardware —
Windows can't test that part of the stack at all. Treat every "High" below
as "confirmed by an actual build", "Medium/Low" as still resting on prior
art alone.
## Prior art checked before writing this
- [zelikos/davincibox](https://github.com/zelikos/davincibox) — Fedora
toolbox base, actively maintained, tested by its maintainer against real
AMD/Intel GPUs (no NVIDIA hardware). This is where the base image,
`davinci-dependencies` package list, the silent-install invocation, and
the patchelf fix all come from, read as raw files from GitHub (not
paraphrased from search snippets).
- [fat-tire/resolve](https://github.com/fat-tire/resolve) — Rocky Linux
base, raw podman/docker (no distrobox), bakes Resolve into the image at
**build time** using the same `-i -a -y` installer flags. Cross-checking
this against davincibox's `setup-davinci` (which uses the same flags, at
container-runtime instead) is what gave confidence that `-i -a -y` is a
real, working non-interactive install path and not a guess — two
independent projects landed on the same flags.
- Universal Blue / openSUSE forum threads, Blackmagic forum thread: read for
context, not copied from directly.
## Why these choices
- **Fedora toolbox base, not Ubuntu (unlike Houdini).** Kept as-is from
davincibox rather than switched to Ubuntu for consistency with Houdini,
because it's the only base upstream has actually run real Resolve
installs against, and it already ships the sudo/user bootstrap distrobox
expects. The repo convention explicitly allows a different base per app.
- **Resolve baked in at build time, not via a post-`distrobox create` setup
script.** davincibox installs Resolve *after* the box exists
(`setup-davinci`), because it's meant to be a generic base image handed
out to many users with different Resolve versions. This repo's own
convention is the opposite: bake the actual software in and push a
ready-to-run image (see Houdini). Confirmed this is actually possible
(not just theoretically) by finding fat-tire/resolve, which does exactly
this — bakes Resolve into a Dockerfile `RUN` step with no display
attached, using the same installer flags.
- **`-i -a -y` install flags.** Not documented anywhere by Blackmagic
directly (as far as this research found) — the confidence here comes from
two independent community projects (davincibox, fat-tire/resolve) using
the exact same flags to drive the same `.run`/AppImage installer
non-interactively. `QT_QPA_PLATFORM=minimal` + `SKIP_PACKAGE_CHECK=1`
layered on top come from davincibox specifically
(zelikos/davincibox#35) — fat-tire/resolve doesn't set these, so it's
possible they're only needed in some environments; kept them since we're
building with no display at all, which is the case they're meant for.
- **patchelf fix, copied verbatim including the full library paths.**
davincibox's `setup-davinci` builds `--add-needed` arguments from full
paths (`/usr/lib64/libglib-2.0.so.0`, ...), not bare sonames. This looks
unusual — patchelf's `--add-needed` conventionally takes a soname — but
it's copied exactly as upstream has it working, rather than "corrected"
based on how patchelf is normally used elsewhere. If this turns out not to
work, that's the first thing to check against upstream's current version
of the script (it may have changed since this was written).
- **`amd` variant installs both ROCm and Intel's `intel-compute-runtime`.**
Matches davincibox's single `-opencl` variant, which is the same
reasoning Houdini's `Dockerfile` uses for "amd variant also works for
Intel" — no separate Intel target. `mesa-libOpenCL` (rusticl) is removed
first because it's confirmed (zelikos/davincibox#173) to break ROCm.
- **`nvidia` variant is untouched (no OpenCL packages added).** Matches
Houdini's NVIDIA variant shape (nothing baked in, host driver only) but
the actual runtime wiring differs — see the "NVIDIA gotcha" section in
`README.md`. davincibox's README documents needing the NVIDIA Container
Toolkit + CDI device injection (`--device nvidia.com/gpu=all`) rather
than distrobox's simpler `--nvidia` flag, for reasons not fully explained
in their docs (something about their toolbox target needing
`NVIDIA_VISIBLE_DEVICES`/`NVIDIA_DRIVER_CAPABILITIES` env vars set at the
container level, which `--nvidia`'s driver-file bind-mount alone doesn't
set up). Not resolved here; flagged as an open question for whoever tests
this first.
- **App menu entry uses Resolve's own shipped `.desktop`/icon files**
(`/opt/resolve/share`, `/opt/resolve/graphics`), unlike Houdini where one
had to be hand-written from scratch. This is a real difference in what
each app ships, not an inconsistency to "fix" — davincibox's
`add-davinci-launcher` script does the same `sed`-based adaptation,
simplified in the README here since we don't need its toolbox/distrobox
branching (this repo is distrobox-only) or its `remove` mode.
- **Not ported from davincibox:** `switcheroo-control` multi-GPU handling
(`list-gpus`/`switcherooctl launch` wrapping in `run-davinci`) and runtime
GPU auto-detection in the launcher (`lshw`-based, only needed because
davincibox ships one image covering all GPU vendors — this repo already
splits that at build time via `amd`/`nvidia` targets). Both are real
upstream features, deliberately left out here rather than overlooked —
add them back from davincibox's `run-davinci` if dual-GPU laptop
switching turns out to matter.
## Build test (2026-09-09)
Ran on Docker Desktop (WSL2 backend, Windows host) with the real
`DaVinci_Resolve_21.1_Linux.run` (free version) placed next to the
Dockerfile — `docker build --target amd` then `--target nvidia`. No
distrobox involved (Windows), so this only covers the image build itself,
not an actual GUI launch.
- **Dependency install (`base` stage, both variants): passed clean.** All
165 packages in `davinci-dependencies` resolved and installed on
`fedora-toolbox:44` with 0 errors — confirms the list still matches
current Fedora 44 repos.
- **Silent install (`-i -a -y`, `QT_QPA_PLATFORM=minimal`,
`SKIP_PACKAGE_CHECK=1`) actually works at Docker build time, no display
attached.** Installer output ended with `DaVinci Resolve installed to
/opt/resolve` / `Done`. Only benign warnings: missing `xdg-icon-resource`/
`xdg-mime`/`gtk-update-icon-cache` (desktop-integration helpers not
installed, not needed at build time) and a udev reload failure (no real
udev/sysfs in a build container — expected). No AppImage magic-byte issue
hit with this particular `.run` (that workaround, from fat-tire/resolve,
is still not ported — add it back if a future version's `.run` fails
`--appimage-extract`).
- **patchelf fix ran successfully.** `find /opt/resolve/bin -executable
-type f -exec patchelf ...` reported `patchelf: not an ELF executable`
for 3 files (non-ELF things under `bin/` with the executable bit set,
e.g. shell scripts) — harmless, and doesn't fail the build because `find
-exec cmd {} \;` (semicolon form) does not propagate `cmd`'s exit status
to `find`'s own. Verified with `patchelf --print-needed` that `resolve`
and its sibling binaries now carry all 4 `--add-needed` entries.
- **`ldd /opt/resolve/bin/resolve` (the actual entry point): zero missing
libraries.** This is the one that matters — confirms the dependency list
is sufficient for the main binary as actually invoked.
- **False alarm, worth remembering:** running `ldd` directly on individual
`.so` files under `/opt/resolve/libs/*.so` in isolation shows dozens of
"not found" (`libc++.so.1`, every bundled Qt5/OpenCV/Kaldi/OpenEXR lib,
etc.). This is **not a real problem** — `resolve`'s own RPATH is
`$ORIGIN/../libs/:$ORIGIN/../libs/Fusion:...` (old-style `DT_RPATH`,
padded with a long run of `x` characters so Blackmagic's own installer
can rewrite the real path post-install without changing the binary's
size — same trick as the `RESOLVE_INSTALL_LOCATION` placeholder in the
`.desktop` files). `DT_RPATH` on the main executable applies transitively
to the whole process's library resolution, not just its own direct
`NEEDED` entries — so at actual runtime, through `resolve`, all of these
resolve fine. Testing a `.so` file in isolation loses that context and
produces a misleading "missing" list. **Lesson for next time: to check
for real missing libraries in an RPATH-based bundle like this one, `ldd`
only the actual entry point binary, not the library files underneath
it** — scanning every `.so` individually (the approach that worked for
Houdini's Qt plugins, which don't use this RPATH trick) gives false
positives here.
- **The only genuinely missing library found:** `libcuda.so.1`, needed by
`libDecoderCUDA.so` (CUDA RAW decode path) — expected and correct, that
comes from the host NVIDIA driver, not from anything baked into the
image.
- **`nvidia` target builds instantly** (shares the cached `base` stage) and
carries `NVIDIA_VISIBLE_DEVICES=all`/`NVIDIA_DRIVER_CAPABILITIES=all` as
expected. Its actual GPU passthrough behavior (`--nvidia` vs CDI, see
README) is still unverified — no NVIDIA hardware available to test from
here either.
- Not exercised at all: actual GUI launch, license-free playback, OpenCL
compute on real AMD/Intel hardware, audio, the app-menu-entry steps,
Studio+dongle path. All of that needs a real Linux host with distrobox.
## What's still unverified after this build test
| Area | Confidence | Note |
|---|---|---|
| Base image + dependency list | High | Build-confirmed against Fedora 44 repos, 2026-09-09. |
| `-i -a -y` + `QT_QPA_PLATFORM=minimal` + `SKIP_PACKAGE_CHECK=1` at Docker build time, no display | High | Build-confirmed: installer completed and reported success. |
| patchelf fix (paths, not sonames) | High | Build-confirmed: ran without failing the build, `--print-needed` shows the entries landed on `resolve` and siblings. |
| Dependency sufficiency for the actual entry point (`ldd /opt/resolve/bin/resolve`) | High | Build-confirmed: zero missing libraries. |
| AppImage magic-bytes workaround (fat-tire's Arch/Manjaro-specific issue) | Not ported | Not hit with the 21.1 `.run` tested here; add back from fat-tire/resolve's Dockerfile if a future version's `--appimage-extract` fails on it. |
| `amd` variant (ROCm + Intel packages install) | High | Build-confirmed: `dnf install intel-compute-runtime rocm-opencl` succeeded with no extra repos needed. Actual GPU compute correctness (OpenCL kernels running right) still unverified — needs real hardware. |
| `nvidia` variant / `--nvidia` vs CDI | Low | Still a real open question — see "NVIDIA gotcha" in README. Image builds fine either way; only the *runtime* GPU passthrough method is unverified. |
| App menu entry steps | Medium | Directly adapted from a working upstream script, simplified; confirmed the `.desktop` files exist at the documented paths (`/opt/resolve/share/*.desktop`), not run end-to-end. |
| Actual GUI launch / rendering / audio / licensing | Untested | Needs a real Linux host with distrobox + GPU — impossible to test from this Windows/Docker Desktop environment. |
## Repo-wide conventions
See the top-level `../README.md` for the multi-software repo convention
(one self-contained folder per app, shared registry setup notes) — that
file is meant for Simon to read; this one and `../houdini/CLAUDE.md` are for
future-Claude context.

71
davinci/Dockerfile Normal file
View File

@@ -0,0 +1,71 @@
# syntax=docker/dockerfile:1.7
#
# Base image + dependency list copied from zelikos/davincibox
# (https://github.com/zelikos/davincibox), the most battle-tested distrobox
# image for DaVinci Resolve on Linux. One deliberate difference from
# upstream: Resolve itself is baked in at build time here (this repo's
# convention: build once, push, no setup step after `distrobox create`)
# instead of being installed into the box afterwards by their
# `setup-davinci` script.
#
# The silent-install invocation and the patchelf fix below are copied
# verbatim from davincibox's `system_files/usr/bin/setup-davinci` script,
# cross-confirmed against fat-tire/resolve's Dockerfile
# (https://github.com/fat-tire/resolve) which drives the same installer with
# the same `-i -a -y` flags at Docker build time — not guessed.
FROM quay.io/fedora/fedora-toolbox:44 AS base
LABEL com.github.containers.toolbox="true" \
usage="This image is meant to be used with the distrobox command" \
summary="DaVinci Resolve, baked in, for distrobox"
# davincibox's own dependency list, proven against real Resolve installs
# (Fedora Atomic, Bluefin, Bazzite - see davinci/CLAUDE.md).
COPY davinci-dependencies /davinci-dependencies
RUN dnf -y update && \
grep -v '^#' /davinci-dependencies | xargs dnf -y install && \
rm /davinci-dependencies && \
dnf clean all
# The .run installer as downloaded from Blackmagic's site and unzipped
# (DaVinci_Resolve_<version>_Linux.run, or the _Studio_ variant), placed
# next to this Dockerfile.
ARG RESOLVE_INSTALLER=DaVinci_Resolve_Linux.run
COPY ${RESOLVE_INSTALLER} /tmp/resolve.run
# `-i -a -y`: silent install, accept all, assume yes - same flags used by
# davincibox's setup-davinci and by fat-tire/resolve's Dockerfile.
# QT_QPA_PLATFORM=minimal + SKIP_PACKAGE_CHECK=1: needed with no display
# attached, from davincibox (see zelikos/davincibox#35).
RUN cd /tmp && \
chmod +x resolve.run && \
./resolve.run --appimage-extract >/dev/null && \
cd squashfs-root && \
QT_QPA_PLATFORM=minimal SKIP_PACKAGE_CHECK=1 ./AppRun -i -a -y && \
cd /tmp && rm -rf resolve.run squashfs-root
# Resolve's own binaries dlopen these libs without a DT_NEEDED entry
# (avoids the LD_PRELOAD workaround described at
# https://www.reddit.com/r/voidlinux/comments/12g71x0/comment/l2cwo27/).
# Same fix, same (full-path) argument form, as davincibox's setup-davinci.
RUN find /opt/resolve/bin -executable -type f -exec patchelf \
--add-needed /usr/lib64/libglib-2.0.so.0 \
--add-needed /usr/lib64/libgdk_pixbuf-2.0.so.0 \
--add-needed /usr/lib64/libgio-2.0.so.0 \
--add-needed /usr/lib64/libgmodule-2.0.so.0 {} \;
COPY davinci-run /usr/local/bin/davinci-run
RUN chmod +x /usr/local/bin/davinci-run
FROM base AS amd
# Covers AMD (ROCm) and Intel (intel-compute-runtime) in one image, like
# davincibox's "-opencl" variant. mesa-libOpenCL (rusticl) is removed first:
# it breaks ROCm outright (zelikos/davincibox#173).
RUN dnf -y remove mesa-libOpenCL && \
dnf -y install intel-compute-runtime rocm-opencl && \
dnf clean all
FROM base AS nvidia
# OpenCL/CUDA/NVENC come from the host driver, not baked in.
ENV NVIDIA_VISIBLE_DEVICES=all
ENV NVIDIA_DRIVER_CAPABILITIES=all

137
davinci/README.md Normal file
View File

@@ -0,0 +1,137 @@
# DaVinci Resolve in distrobox
Two images built from the same `Dockerfile`, pushed to a private registry,
used via distrobox:
- `davinci-amd` — DaVinci Resolve + ROCm + Intel `intel-compute-runtime`,
for AMD/Intel GPUs
- `davinci-nvidia` — DaVinci Resolve only; the NVIDIA driver/toolchain is
provided by the host
Registry: `docker.slambin.fr`. Files: `Dockerfile`, `davinci-dependencies`
(package list), `davinci-run` (in-image launcher).
This setup is a direct adaptation of
[zelikos/davincibox](https://github.com/zelikos/davincibox) — same base
image, same dependency list, same install flags — with one change: Resolve
is baked into the image at build time instead of being installed into the
box afterwards, to match this repo's "build once, push" convention. See
`CLAUDE.md` for what was changed and why.
Both `amd` and `nvidia` targets have been build-tested end to end (Docker
Desktop/WSL2, real `DaVinci_Resolve_21.1_Linux.run`) — dependency install,
the silent Resolve install, and the patchelf fix all completed cleanly, and
`ldd` on the installed binary shows no missing libraries. Not yet tested:
an actual `distrobox create` + GUI launch on real Linux/GPU hardware (see
`CLAUDE.md` for the full breakdown).
> DaVinci Resolve binaries get baked into these images from your own
> Blackmagic Design download. Keep the registry **private** — never push
> these images publicly. Not affiliated with Blackmagic Design.
---
## Prerequisites
- The DaVinci Resolve (or DaVinci Resolve Studio) Linux `.run` installer
from [Blackmagic's site](https://www.blackmagicdesign.com/products/davinciresolve),
unzipped, placed next to the `Dockerfile` (the download is a `.zip`
containing the `.run` — `unzip DaVinci_Resolve_*_Linux.zip` first).
- Your host user should be in the `render` and `video` groups for GPU
device access: `sudo usermod -aG render,video "$USER"` (log out/in after).
- NVIDIA only: [NVIDIA Container Toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html)
installed on the host (see "NVIDIA gotcha" below).
## Build & push
```bash
REGISTRY=docker.slambin.fr
VERSION=21.1
INSTALLER=DaVinci_Resolve_21.1_Linux.run
for target in amd nvidia; do
podman build -f Dockerfile \
--build-arg "RESOLVE_INSTALLER=${INSTALLER}" \
--target "${target}" \
-t "${REGISTRY}/davinci-${target}:${VERSION}" \
-t "${REGISTRY}/davinci-${target}:latest" .
podman push "${REGISTRY}/davinci-${target}:${VERSION}"
podman push "${REGISTRY}/davinci-${target}:latest"
done
```
## Install / run
```bash
# AMD / Intel
distrobox create \
--name davinci \
--image docker.slambin.fr/davinci-amd:latest \
--additional-flags "--hostname davinci-resolve"
# NVIDIA (see gotcha below re: --nvidia vs CDI)
distrobox create \
--name davinci \
--image docker.slambin.fr/davinci-nvidia:latest \
--nvidia \
--additional-flags "--hostname davinci-resolve"
```
Then:
```bash
distrobox enter davinci
davinci-run
```
### NVIDIA gotcha (unverified)
Houdini's NVIDIA variant just needs `distrobox --nvidia` (host driver files
bind-mounted, enough for GL/Vulkan viewport rendering). DaVinci Resolve
needs full CUDA/OpenCL/NVENC, and upstream davincibox's README documents
using the **NVIDIA Container Toolkit + CDI** route instead:
```bash
distrobox create \
--name davinci \
--image docker.slambin.fr/davinci-nvidia:latest \
--additional-flags "--device nvidia.com/gpu=all"
```
which requires `nvidia-container-toolkit` set up on the host (already the
case on Universal Blue images; see NVIDIA's own install guide otherwise).
Whether plain `--nvidia` is actually enough has not been tested here — try
it first since it's simpler, fall back to the CDI form above if Resolve
reports something like "Unsupported GPU processing mode" on launch.
## App menu entry (icon, no terminal)
Resolve ships its own `.desktop` files and icons under
`/opt/resolve/share` and `/opt/resolve/graphics` — no need to write one by
hand:
```bash
distrobox enter davinci
mkdir -p ~/.local/share/applications
cp /opt/resolve/share/*.desktop ~/.local/share/applications
rm ~/.local/share/applications/DaVinciResolveInstaller.desktop
sed -i 's/RESOLVE_INSTALL_LOCATION/\/opt\/resolve/' \
~/.local/share/applications/{blackmagicraw*,DaVinci*}.desktop
sed -i "s,Exec=,Exec=distrobox enter -n davinci -- /usr/local/bin/davinci-run ," \
~/.local/share/applications/{blackmagicraw*,DaVinci*}.desktop
distrobox-export --app "$HOME/.local/share/applications/DaVinciResolve.desktop"
```
(Adapted from davincibox's `add-davinci-launcher` script — see CLAUDE.md.)
## Known gotchas (from upstream, not yet hit here ourselves)
- **No audio**: Resolve uses ALSA via the `pipewire-alsa` plugin baked into
the image. If your host doesn't run PipeWire, swap it inside the box:
`sudo dnf remove pipewire-alsa && sudo dnf install alsa-plugins-pulseaudio`.
- **Codecs**: the free version's codec support is limited — this is a
Blackmagic licensing limitation, not something this image can fix.
- **Studio + USB dongle**: needs a udev rule on the host to let the
container see the license dongle. See
[davincibox's README](https://github.com/zelikos/davincibox#davinci-resolve-studio-crashes-on-checking-licences)
if you hit "Checking Licences..." crashes.

37
davinci/davinci-dependencies Normal file
View File

@@ -0,0 +1,37 @@
alsa-lib
apr
apr-util
dbus-libs
glx-utils
libglvnd-egl
libglvnd-glx
libICE
librsvg2
libSM
libxcrypt-compat
libXcursor
libXfixes
libXi
libXinerama
libxkbcommon-x11
libxkbfile
libXrandr
libXtst
libXxf86vm
lshw
mesa-libGLU
mesa-libOpenCL
mtdev
nss
ocl-icd
pipewire-alsa
pulseaudio-libs
python3-gobject
switcheroo-control
xcb-util
xcb-util-cursor
xcb-util-image
xcb-util-keysyms
xcb-util-renderutil
xcb-util-wm
patchelf

17
davinci/davinci-run Normal file
View File

@@ -0,0 +1,17 @@
#!/usr/bin/env bash
# Launch DaVinci Resolve.
set -euo pipefail
export QT_QPA_PLATFORM=xcb
export QT_AUTO_SCREEN_SCALE_FACTOR=1
# distrobox exposes the host's /usr/OFX/Plugins (if any) at
# /run/host/usr/OFX/Plugins; link it in so host-installed OFX plugins also
# show up inside the container (same convention as davincibox's run-davinci).
HOST_OFX=/run/host/usr/OFX/Plugins
if [ -d "${HOST_OFX}" ] && [ ! -e /usr/OFX/Plugins ]; then
sudo mkdir -p /usr/OFX
sudo ln -s "${HOST_OFX}" /usr/OFX/Plugins
fi
exec /opt/resolve/bin/resolve "$@"

25
houdini/README.md
View File

@@ -8,7 +8,7 @@ used via distrobox:
by `distrobox --nvidia` by `distrobox --nvidia`
Registry: `docker.slambin.fr`. Files: `Dockerfile`, `houdini-run` (in-image Registry: `docker.slambin.fr`. Files: `Dockerfile`, `houdini-run` (in-image
launcher), `build-and-push.sh`. launcher).
> Houdini binaries are baked into these images under a personal SideFX > Houdini binaries are baked into these images under a personal SideFX
> account. Keep the registry **private** — never push these images publicly. > account. Keep the registry **private** — never push these images publicly.
@@ -25,14 +25,25 @@ launcher), `build-and-push.sh`.
## Build & push ## Build & push
Edit the variables at the top of `build-and-push.sh` (version, tarball name,
EULA date if it changed), then:
```bash ```bash
./build-and-push.sh REGISTRY=docker.slambin.fr
``` VERSION=22.0.429
TARBALL=houdini-22.0.429-linux_x86_64_gcc14.2.tar.gz
# Date the EULA at https://www.sidefx.com/legal/license-agreement/ was last
# updated, format YYYY-MM-DD, no "SideFX-" prefix.
EULA_DATE=2021-10-13
Builds both variants and pushes all tags to `docker.slambin.fr`. for target in amd nvidia; do
podman build -f Dockerfile \
--build-arg "HOUDINI_TARBALL=${TARBALL}" \
--build-arg "HOUDINI_EULA_DATE=${EULA_DATE}" \
--target "${target}" \
-t "${REGISTRY}/houdini-${target}:${VERSION}" \
-t "${REGISTRY}/houdini-${target}:latest" .
podman push "${REGISTRY}/houdini-${target}:${VERSION}"
podman push "${REGISTRY}/houdini-${target}:latest"
done
```
## Install / run ## Install / run

21
houdini/build-and-push.sh
View File

@@ -1,21 +0,0 @@
#!/usr/bin/env bash
# Build both variants (shared base) and push. Heavy: run when ready.
set -euo pipefail
REGISTRY="${REGISTRY:-docker.slambin.fr}"
VERSION="${VERSION:-22.0.429}"
TARBALL="${TARBALL:-houdini-22.0.429-linux_x86_64_gcc14.2.tar.gz}"
# Date the EULA at https://www.sidefx.com/legal/license-agreement/ was last
# updated, format YYYY-MM-DD, no "SideFX-" prefix.
EULA_DATE="${EULA_DATE:-2021-10-13}"
ENGINE="${ENGINE:-podman}"
ARGS=(-f Dockerfile --build-arg "HOUDINI_TARBALL=${TARBALL}" --build-arg "HOUDINI_EULA_DATE=${EULA_DATE}")
for target in amd nvidia; do
"${ENGINE}" build "${ARGS[@]}" --target "${target}" \
-t "${REGISTRY}/houdini-${target}:${VERSION}" \
-t "${REGISTRY}/houdini-${target}:latest" .
"${ENGINE}" push "${REGISTRY}/houdini-${target}:${VERSION}"
"${ENGINE}" push "${REGISTRY}/houdini-${target}:latest"
done