From 6869905017903de96ba18cd60ad5fcc842975d6e Mon Sep 17 00:00:00 2001 From: CI/CD Date: Wed, 9 Sep 2026 11:50:57 +0200 Subject: [PATCH] feat: add davinci resolve image --- .gitignore | 2 + README.md | 35 ++----- davinci/CLAUDE.md | 181 +++++++++++++++++++++++++++++++++++ davinci/Dockerfile | 71 ++++++++++++++ davinci/README.md | 137 ++++++++++++++++++++++++++ davinci/davinci-dependencies | 37 +++++++ davinci/davinci-run | 17 ++++ houdini/README.md | 25 +++-- houdini/build-and-push.sh | 21 ---- 9 files changed, 469 insertions(+), 57 deletions(-) create mode 100644 davinci/CLAUDE.md create mode 100644 davinci/Dockerfile create mode 100644 davinci/README.md create mode 100644 davinci/davinci-dependencies create mode 100644 davinci/davinci-run delete mode 100644 houdini/build-and-push.sh diff --git a/.gitignore b/.gitignore index 1577a16..53c3f81 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,5 @@ *.tar.gz *.tar.bz2 *.iso +*.run +*.zip diff --git a/README.md b/README.md index fa3f617..a08ffd0 100644 --- a/README.md +++ b/README.md @@ -10,10 +10,9 @@ One self-contained folder per app: ``` / - Dockerfile # often multi-stage: shared base + amd / nvidia variant - build-and-push.sh # build + push to the registry - -run # launcher installed in the image (app entrypoint) - README.md # specifics: prerequisites, licensing, distrobox create, gotchas + Dockerfile # often multi-stage: shared base + amd / nvidia variant + -run # launcher installed in the image (app entrypoint) + README.md # specifics: prerequisites, build + push, distrobox create, gotchas ``` No shared base image across different apps — each has its own system @@ -31,10 +30,8 @@ duplicate on principle. ## Private registry -Registry: `docker.slambin.fr`. If it's a real domain with TLS (reverse proxy -+ cert) in front, nothing to configure on the container engine side — -`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": +The apps a meant to be pushed to the private registry: `docker.slambin.fr`. +And then run using distrobox or podman. ```bash podman run -d --name registry --restart=always \ @@ -42,27 +39,7 @@ podman run -d --name registry --restart=always \ 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 - [`houdini/`](houdini/README.md) — Houdini Apprentice +- [`davinci/`](davinci/README.md) — DaVinci Resolve diff --git a/davinci/CLAUDE.md b/davinci/CLAUDE.md new file mode 100644 index 0000000..51fc737 --- /dev/null +++ b/davinci/CLAUDE.md @@ -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. diff --git a/davinci/Dockerfile b/davinci/Dockerfile new file mode 100644 index 0000000..0fc0cd3 --- /dev/null +++ b/davinci/Dockerfile @@ -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__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 diff --git a/davinci/README.md b/davinci/README.md new file mode 100644 index 0000000..5913bea --- /dev/null +++ b/davinci/README.md @@ -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. diff --git a/davinci/davinci-dependencies b/davinci/davinci-dependencies new file mode 100644 index 0000000..ec283f9 --- /dev/null +++ b/davinci/davinci-dependencies @@ -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 diff --git a/davinci/davinci-run b/davinci/davinci-run new file mode 100644 index 0000000..c3e62fe --- /dev/null +++ b/davinci/davinci-run @@ -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 "$@" diff --git a/houdini/README.md b/houdini/README.md index 7125954..ff10d66 100644 --- a/houdini/README.md +++ b/houdini/README.md @@ -8,7 +8,7 @@ used via distrobox: by `distrobox --nvidia` 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 > account. Keep the registry **private** — never push these images publicly. @@ -25,14 +25,25 @@ launcher), `build-and-push.sh`. ## Build & push -Edit the variables at the top of `build-and-push.sh` (version, tarball name, -EULA date if it changed), then: - ```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 diff --git a/houdini/build-and-push.sh b/houdini/build-and-push.sh deleted file mode 100644 index 880866c..0000000 --- a/houdini/build-and-push.sh +++ /dev/null @@ -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