From e512c3e4e3dda3bbe70a201406c40adc7815f06a Mon Sep 17 00:00:00 2001 From: Simon Lambin Date: Wed, 9 Sep 2026 08:46:38 +0200 Subject: [PATCH] feat: cleanup the houdini image setup --- README.md | 68 ++++---- houdini/CLAUDE.md | 164 ++++++++++++++++++ houdini/README.md | 197 ++++++---------------- houdini/build-and-push.sh | 2 +- houdini/docker/README | 47 ------ houdini/docker/Ubuntu/Dockerfile | 15 -- houdini/docker/Ubuntu/docker-compose.yml | 11 -- houdini/docker/Windows/Dockerfile | 19 --- houdini/docker/Windows/docker-compose.yml | 11 -- 9 files changed, 249 insertions(+), 285 deletions(-) create mode 100644 houdini/CLAUDE.md delete mode 100644 houdini/docker/README delete mode 100644 houdini/docker/Ubuntu/Dockerfile delete mode 100644 houdini/docker/Ubuntu/docker-compose.yml delete mode 100644 houdini/docker/Windows/Dockerfile delete mode 100644 houdini/docker/Windows/docker-compose.yml diff --git a/README.md b/README.md index 8e9a6cb..fa3f617 100644 --- a/README.md +++ b/README.md @@ -1,35 +1,40 @@ # distrobox-images -Dockerfiles pour les softs lourds (Houdini, ...) lancés via [distrobox](https://github.com/89luca89/distrobox), -buildés une fois et poussés sur un registry privé plutôt que rebuild à chaque -`distrobox create`. +Dockerfiles for heavy software (Houdini, ...) run via +[distrobox](https://github.com/89luca89/distrobox), built once and pushed to +a private registry instead of rebuilding on every `distrobox create`. ## Convention -Un dossier par soft, autonome : +One self-contained folder per app: ``` / - Dockerfile # souvent multi-stage: base commune + variante amd / nvidia - build-and-push.sh # build + push vers le registry - -run # launcher installé dans l'image (entrypoint applicatif) - README.md # specifics: prérequis, licence, distrobox create, gotchas + 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 ``` -Pas de base image partagée entre softs différents — chacun a ses propres -dépendances système, ça n'apporte rien de mutualiser au-delà du dossier. +No shared base image across different apps — each has its own system +dependencies, sharing more than the folder structure doesn't buy anything. -Deux variantes GPU par soft quand le rendu OpenGL/Vulkan compte (viewport, -préview) : -- `-amd` — Mesa embarqué dans l'image (radeonsi / RADV), marche aussi - pour Intel. -- `-nvidia` — rien embarqué; le driver NVIDIA de l'hôte est monté au - runtime par `distrobox --nvidia`. +Two GPU variants per app when OpenGL/Vulkan rendering matters (viewport, +preview): +- `-amd` — Mesa baked into the image (radeonsi / RADV), also works for + Intel. +- `-nvidia` — nothing baked in; the host's NVIDIA driver is mounted at + runtime by `distrobox --nvidia`. -Si le rendu GPU n'a pas d'importance pour un soft donné, une seule image -suffit — ne pas dupliquer par principe. +If GPU rendering doesn't matter for a given app, one image is enough — don't +duplicate on principle. -## Registry privé +## 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": ```bash podman run -d --name registry --restart=always \ @@ -37,32 +42,27 @@ podman run -d --name registry --restart=always \ registry:2 ``` -HTTP en clair, donc à déclarer en "insecure" côté moteur de conteneurs. - -**podman** — `/etc/containers/registries.conf.d/local.conf` : +**podman** — `/etc/containers/registries.conf.d/local.conf`: ```toml [[registry]] -location = "registry.lan:5000" +location = "docker.slambin.fr" insecure = true ``` -**docker** — `/etc/docker/daemon.json`, puis restart docker : +**docker** — `/etc/docker/daemon.json`, then restart docker: ```json -{ "insecure-registries": ["registry.lan:5000"] } +{ "insecure-registries": ["docker.slambin.fr"] } ``` -Au-delà d'un LAN de confiance, mettre TLS + auth devant plutôt que -`insecure`. +## Licensing / EULA -## Licences / 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. -Plusieurs de ces softs (Houdini compris) sont installés depuis un binaire -propriétaire téléchargé avec un compte perso, et l'EULA interdit en général -la redistribution. Le registry doit rester **privé** — jamais de push d'une -image contenant un de ces binaires vers un registry public. - -## Softs +## Apps - [`houdini/`](houdini/README.md) — Houdini Apprentice diff --git a/houdini/CLAUDE.md b/houdini/CLAUDE.md new file mode 100644 index 0000000..1517a6b --- /dev/null +++ b/houdini/CLAUDE.md @@ -0,0 +1,164 @@ +# Houdini image — design notes and debugging history + +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`). + +## Why these choices + +- **Base image + install command copy SideFX's own `docker/Ubuntu/Dockerfile`** + (shipped inside the Houdini tarball under `docker/Ubuntu/`), not guessed. + That reference folder has been deleted from this repo once its contents + were folded in here — it only ever served as a source to copy from, and + keeping it around invited drift between two copies of the same info. +- **Ubuntu 22.04, not Rocky/RHEL.** The tarball is `gccXX.X`-tagged (here + `gcc14.2`), meaning the runtime needs a `libstdc++` new enough for that + build. Ubuntu's base image keeps `libstdc++6` updated via regular package + updates; RHEL-family distros pin their system toolchain for the whole OS + lifetime, so a Rocky 9 base risks a `GLIBCXX_x` version mismatch depending + on which Houdini build you're on. This was a real, not hypothetical, + concern with the 22.0.429/gcc14.2 build tested here. +- **`--auto-install --accept-EULA `, no `--make-dir`, no + `--install-license`.** An earlier draft of this Dockerfile invented an + `--install-license ` flag that doesn't exist, based on scripted- + install docs that actually describe a *different* tool + (`houdini_installer`, the newer credential-based launcher — irrelevant + here, since it needs network + stored SideFX credentials at build time, + which is worse for a private-registry-baked-tarball workflow). The + flags actually used are copy-pasted from SideFX's own Dockerfile. +- **EULA date is a plain `YYYY-MM-DD`, no `SideFX-` prefix.** The + `SideFX-YYYY-MM-DD` form belongs to `houdini_installer`'s config file, not + to `houdini.install`. Mixing the two up silently breaks `--accept-EULA` + matching. Value as of writing: `2021-10-13` (from + https://www.sidefx.com/legal/license-agreement/ — SideFX can update this + without notice, it's not pinned/checked anywhere). +- **`/opt/hfs` symlink is created explicitly.** `houdini.install`'s default + behavior only creates a major.minor symlink (`/opt/hfs22.0` here), not a + generic `/opt/hfs`. The Dockerfile globs for the installed `hfs[0-9]*` dir + and symlinks it to `/opt/hfs` itself, so `houdini-run` and the + `/etc/profile.d` snippet don't need to know the exact version. + +## Runtime library list + +SideFX's own package list in `docker/Ubuntu/Dockerfile` is built for headless +`hython`/`sesinetd` use (their `docker-compose.yml` only ever runs `hython` +or `sesinetd` as separate services, never the GUI). Running the actual +`houdinifx` GUI needed 4 more libs, each found by `ldd`-checking the real +binaries/plugins in a test build and confirmed missing before adding: + +- `libegl1` — EGL dispatch, `houdinifx-bin` linked against it directly. +- `libatomic1` — `houdinifx-bin`/`hython-bin` both needed it. +- `libxkbfile1` — same. +- `libxcb-cursor0` — this one took the longest to find. Qt6's `xcb` platform + plugin (`libqxcb.so`, under + `/opt/hfs/dsolib/Qt_plugins/platforms/`) hard-depends on it (a known + Qt6 change from Qt5, where cursor theming moved from Xcursor to + xcb-cursor). Without it, Houdini fails at Qt platform-plugin init with a + generic "no Qt platform plugin could be initialized" — nothing points at + the actual missing symbol unless you `ldd` the plugin directly. + +If a future Houdini/Qt version adds new failures here, the fastest diagnosis +path is: `ldd` every `.so` under `dsolib/Qt_plugins/` recursively (see git +history of this file / session transcript for the exact one-liner), not +guessing from the vague top-level Qt error message. + +## `houdini-run` strict-mode compatibility + +`houdini_setup_bash` (sourced by `houdini-run` to set up `$HFS`/`PATH`/etc.) +is not written for `set -euo pipefail`: +- It references variables that are legitimately unset in some code paths + (`set -u` would abort). +- It does things like `d=$(which java)` expecting a silent empty result on + failure (`set -e` would abort on the failed `which`). + +Fix: wrap the `source ./houdini_setup` call with `set +euo pipefail` / +`set -euo pipefail` around it, rather than trying to patch the vendor +script. + +## NixOS / distrobox host environment leakage + +Distrobox forwards the *host* shell's environment into the container by +design (needed for `DISPLAY`, `WAYLAND_DISPLAY`, `XDG_*`, D-Bus, etc. to +work at all for GUI apps). On a NixOS host that also sets its own +`LD_LIBRARY_PATH` (observed here pointing at a Nix-store `alsa-lib` built +against a much newer glibc than Ubuntu 22.04 ships), that leaks into the +container and crashes Houdini's binaries at dynamic-link time +(`GLIBC_ABI_GNU2_TLS not found`, etc.) — a library meant for the host's +libc, loaded into a binary linked against the container's older libc. + +`houdini_setup_bash` only ever *prepends* to `LD_LIBRARY_PATH` if it's +already set — it never resets it. So `houdini-run` explicitly +`unset LD_LIBRARY_PATH` before sourcing it, discarding whatever leaked in +from the host and letting Houdini build its own from scratch. This is safe +on any host, not just NixOS — it just happens to matter there. + +This class of problem (host env leaking into the container and colliding +with container-local binaries) is worth checking first if a *new*, +unexplained crash shows up after this image has otherwise worked before. + +## sesinetd / Apprentice licensing — the two real bugs + +Both now handled automatically inside `houdini-run` (not just documented as +manual steps), found via `/var/log/sidefx/sesinetd.log` after a genuinely +confusing symptom in the GUI: + +1. **License file permissions.** `sesinetd` drops privileges to `www-data` + after being started as root via `sudo`. The license file bind-mounted + from the host (`~/.houdini-apprentice/licenses:/usr/lib/sesi/licenses`) + is created with `touch` as the host user, so it's not writable by + `www-data` inside the container. Result: activation's network round-trip + to SideFX succeeds fine (curl-level success), but writing the resulting + license locally fails — surfaced in the GUI as the deeply misleading + **"Success (curl error 0)"** error dialog that just loops back to the + install-license prompt with no indication anything is actually wrong. + The real error only shows up in `/var/log/sidefx/sesinetd.log`: + `[FATAL - Licensing] [Manager] - Failed to open license file.` + Fix: `houdini-run` now `chmod 666`s the license file before starting + `sesinetd`, every time, unconditionally. +2. **Stuck self-signed TLS cert.** If cert generation for `sesinetd`'s HTTPS + listener gets interrupted (observed here across our own repeated + container kill/restart cycles during testing), it leaves 0-byte + `/usr/lib/sesi/ssl/auth.cert` / `auth.priv` behind. On next start, + `sesinetd` tries to read those, fails (`Bad certificate chain: 'PEM + lib'`), and — rather than regenerating — spins retrying at ~100% CPU + forever, never actually finishing startup or opening port 1715. + No error surfaces in the GUI for this one at all; the only symptom is a + pegged CPU core and a license dialog that never succeeds. Fix: + `houdini-run` deletes those two files first if either is 0 bytes. + +Also confirmed, contra a plausible-sounding but wrong worry: SideFX's own +docker README warns that regular (non-floating) licenses need special +"container enabled" entitlements to run `sesinetd` in Docker, working around +it with `network_mode: host` in their own `docker-compose.yml`. That warning +is about Docker's default *isolated* network namespace confusing the +node-lock check. Distrobox shares the host's network namespace by default +(no `--unshare-netns`), which is the same situation as SideFX's own +workaround — so this doesn't apply here, and was confirmed by an actual +successful Apprentice activation. + +## Confidence table (as of the last real end-to-end test) + +Everything below was confirmed with an actual build + an actual +`distrobox create` + `houdini-run` launch on a real AMD iGPU (Vega, +`raven`) host, not just read from docs. + +| Area | Confidence | Note | +|---|---|---| +| Base image + install command | High | Matches SideFX's own Dockerfile; built end to end against the real 22.0.429/gcc14.2 tarball. | +| `/opt/hfs` symlink | High | Confirmed by test build. | +| EULA date value | Medium | `2021-10-13` as of writing; unpinned, SideFX can change it. | +| Licensing works under distrobox's shared netns | High | Confirmed with a real Apprentice activation. | +| Runtime library list | High | Vendor's list + 4 libs added, all confirmed via `ldd` and an actual successful launch. | +| `houdini-run` strict-mode compatibility | High | Confirmed end to end. | +| `sesinetd` license-file-permission and stuck-cert fixes | High | Both bugs actually hit during testing, root-caused via `/var/log/sidefx/sesinetd.log`, fixed in `houdini-run`, confirmed working after the fix. | +| distrobox default hostname | Medium | Pinned explicitly (`houdini-apprentice`) rather than trusting the default, since Apprentice node-locks to hostname too. | +| GUI rendering via XWayland (Hyprland host) | High | Confirmed real AMD hardware acceleration (`glxinfo`: direct rendering, AMD Radeon Vega renderer, not llvmpipe). First launch was slow (container's first-run package install + cold start); later launches fluid. | +| AMD OpenCL (sims) | Low | Not set up; needs ROCm/rusticl. GL/Vulkan viewport is unaffected. | +| NVIDIA variant | Untested | Builds fine (same base, no extra packages), but never run against real NVIDIA hardware — only the `amd` target has been used end to end. | + +## 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 the top-level `../CLAUDE.md` +(if one exists) are for future-Claude context. diff --git a/houdini/README.md b/houdini/README.md index 1c674f0..7125954 100644 --- a/houdini/README.md +++ b/houdini/README.md @@ -1,95 +1,62 @@ -# Houdini Apprentice in distrobox, from a private registry +# Houdini Apprentice in distrobox -Two images built from one shared base: +Two images built from the same `Dockerfile`, pushed to a private registry, +used via distrobox: -- `houdini-amd` — Houdini + Mesa (radeonsi / RADV) for AMD/Intel GPUs -- `houdini-nvidia` — Houdini; the NVIDIA driver is injected at runtime by `distrobox --nvidia` +- `houdini-amd` — Houdini + Mesa, for AMD/Intel GPUs +- `houdini-nvidia` — Houdini only; the NVIDIA driver is injected at runtime + by `distrobox --nvidia` -Files: `Dockerfile` (multi-stage), `houdini-run` (in-image launcher), `build-and-push.sh`. +Registry: `docker.slambin.fr`. Files: `Dockerfile`, `houdini-run` (in-image +launcher), `build-and-push.sh`. -> **Single-image alternative (honest note):** because `distrobox --nvidia` -> mounts the host driver at runtime, a *single* image (base + Mesa) usually -> works for both vendors, with the GPU chosen at `distrobox create` time. Two -> images are cleaner and leaner per vendor, which is what this setup does — but -> if you'd rather maintain one, build only the `amd` target and use it with or -> without `--nvidia`. +> Houdini binaries are baked into these images under a personal SideFX +> account. Keep the registry **private** — never push these images publicly. --- -## 0. Prerequisites +## Prerequisites -- `podman` (or `docker`) and `distrobox` on the host. -- A private registry — see the [repo-level README](../README.md) for setup. -- Your Houdini Linux tarball from your SideFX account, e.g. - `houdini-22.0.429-linux_x86_64_gcc14.2.tar.gz`, placed next to the `Dockerfile`. - The `gccXX.X` suffix means the runtime needs a `libstdc++` new enough for - that build; that's why the base image is Ubuntu 22.04, not Rocky/RHEL — - Ubuntu's base image keeps `libstdc++6` updated, while RHEL-family distros - pin their system toolchain for the OS's lifetime. -- A SideFX account (Apprentice is free) to activate the license on first launch. +- Your Houdini Linux tarball from your SideFX account (e.g. + `houdini-22.0.429-linux_x86_64_gcc14.2.tar.gz`), placed next to the + `Dockerfile`. +- A SideFX account (Apprentice is free) to activate the license on first + launch. -> This Dockerfile mirrors the one SideFX ships inside the tarball itself -> (`docker/Ubuntu/Dockerfile`) for the base image, package list, and install -> command — verified against the vendor's own recipe rather than guessed. Their -> package list is for headless `hython`/`sesinetd` use, though; running the -> actual `houdinifx` GUI needed 3 more runtime libs (`libegl1`, `libatomic1`, -> `libxkbfile1`), found by test-building and `ldd`-checking the binaries — -> already folded into the `Dockerfile`. +## Build & push -> **EULA / redistribution:** Houdini binaries are baked into these images. Keep -> the registry **private**. Do not push Houdini images to a public registry. - ---- - -## 1. Build & push - -Edit the variables at the top of `build-and-push.sh` (registry, version, -tarball name, EULA date), then run it. It builds the shared base once, then the -two variants, and pushes all tags. The base layers are stored only once in the -registry. +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 ``` -> **EULA date format:** plain `YYYY-MM-DD`, no `SideFX-` prefix (that prefix -> belongs to a different, unrelated tool — the newer credential-based -> `houdini_installer` launcher, not the `houdini.install` script used here). -> Current EULA date is `2021-10-13`; double check against -> https://www.sidefx.com/legal/license-agreement/ since SideFX can update it. +Builds both variants and pushes all tags to `docker.slambin.fr`. ---- +## Install / run -## 2. Use it via distrobox - -Pick the image matching your GPU. The two `--additional-flags` bits below are -what make Apprentice licensing survive (see section 3): - -- `--hostname houdini-apprentice` — stable machine name for the node-lock -- a bind mount of the `licenses` file so the activation persists +One-time, on the host — persists the Apprentice license across container +recreation: ```bash -# One-time: create the persisted license file on the host. -mkdir -p ~/.houdini-apprentice -touch ~/.houdini-apprentice/licenses +mkdir -p ~/.houdini-apprentice && touch ~/.houdini-apprentice/licenses ``` -**NVIDIA:** +Create the box (pick the image matching your GPU): ```bash +# AMD / Intel distrobox create \ --name houdini \ - --image registry.lan:5000/houdini-nvidia:latest \ - --nvidia \ + --image docker.slambin.fr/houdini-amd:latest \ --additional-flags "--hostname houdini-apprentice -v $HOME/.houdini-apprentice/licenses:/usr/lib/sesi/licenses" -``` -**AMD / Intel** (drop `--nvidia`; distrobox exposes `/dev/dri` automatically): - -```bash +# NVIDIA distrobox create \ --name houdini \ - --image registry.lan:5000/houdini-amd:latest \ + --image docker.slambin.fr/houdini-nvidia:latest \ + --nvidia \ --additional-flags "--hostname houdini-apprentice -v $HOME/.houdini-apprentice/licenses:/usr/lib/sesi/licenses" ``` @@ -97,16 +64,24 @@ Then: ```bash distrobox enter houdini -houdini-run # starts sesinetd, then launches Houdini FX +houdini-run ``` -On **first launch** Houdini prompts to install the free Apprentice license: log -in with your SideFX account. +First launch prompts to install the free Apprentice license — log in with +your SideFX account. Two things worth knowing: -To add a real app-menu entry (icon, no terminal window) instead of a plain -binary shortcut, export a `.desktop` file from inside the box — the icon path -must point at Houdini's own bundled icon (there's no separate `.desktop` file -shipped, so this one is written by hand): +- The `--hostname houdini-apprentice` flag must stay the same every time you + recreate the box — Apprentice licenses node-lock to hostname as well as + hardware. +- Apprentice licenses expire after 30 days; re-activate the same way (a + quick re-login in the same dialog). + +## App menu entry (icon, no terminal) + +Houdini doesn't ship its own `.desktop` file, and distrobox doesn't have a +built-in way to generate a proper GUI-app entry from a binary — +`distrobox-generate-entry` only makes the generic "Terminal entering X" +shortcut. So write one by hand and export it: ```bash distrobox enter houdini @@ -124,80 +99,8 @@ EOF distrobox-export --app /tmp/houdini.desktop ``` -`distrobox-export` copies the icon out to `~/.local/share/icons/` on the host -and writes `~/.local/share/applications/houdini-houdini.desktop`. Distrobox -also auto-creates a generic `houdini.desktop` ("Terminal entering Houdini") -for every box at creation time — set `NoDisplay=true` in that file (or delete -it) if you don't want both showing up in the app menu. - ---- - -## 3. Apprentice licensing — read this - -Apprentice is the fragile part, by design. Confirmed SideFX behaviour: - -- **No Login Licensing** for Apprentice — only node-locked (workstation) - licenses served by a **local** `sesinetd`, which must be running for Houdini - to start at all. -- The license is **node-locked to the machine hardware _and_ the machine name**. - Change the hostname and the license is invalidated — hence the fixed - `--hostname houdini-apprentice`. Always create the box with the same hostname. -- Apprentice licenses are **valid 30 days**, then you reinstall a fresh free set - (a quick re-login in the same dialog). -- On Linux the keys live in `/usr/lib/sesi/licenses`. The bind mount in section - 2 persists just that file into `~/.houdini-apprentice/`, so recreating or - re-pulling the container keeps the activation (within the 30 days, same host). - Confirmed by an actual Apprentice activation. Two gotchas that took a while - to track down, both now handled automatically by `houdini-run`: - - **File permissions.** `sesinetd` runs as `www-data`, not as your - distrobox user. A bind-mounted file created on the host with `touch` - belongs to your host user and isn't writable by `www-data`, so activation - fails with `Failed to open license file` in - `/var/log/sidefx/sesinetd.log` — surfaced in the GUI as an unrelated- - looking **"Success (curl error 0)"** error that just loops back to the - install-license prompt. `houdini-run` now `chmod 666`s the file before - starting `sesinetd` every time, so this self-heals. - - **Stuck self-signed cert.** If `sesinetd`'s self-signed TLS cert - generation is interrupted (it was, once, across our own container - restarts), it leaves 0-byte `auth.cert`/`auth.priv` files behind, and the - daemon then spins at ~100% CPU retrying against them forever instead of - regenerating — silently breaking activation with no obvious error. - `houdini-run` now deletes those files first if they're empty. - -Practical consequences: - -- **Same physical machine, stable hostname:** activate once; survives container - recreation and image updates until the 30-day expiry. -- **A different physical machine:** the hardware differs, so you re-activate - there (still free). The image is portable; the *license state* is per-machine. - -Inspect or manage licenses from inside the box with `houdini-run hkey` -(graphical) or `sesictrl` (CLI). - -> **"Container-enabled licenses" — why this doesn't apply here:** SideFX's own -> docker README warns that regular (non-floating) licenses need special -> "container enabled" entitlements to run `sesinetd` in Docker, and their own -> `docker-compose.yml` works around it with `network_mode: host`. That warning -> is about Docker's default *isolated* network namespace confusing the -> node-lock check. Distrobox shares the host's network namespace by default -> (no `--unshare-netns`), so the container sees the real host network identity -> — same situation as SideFX's own host-network workaround. Regular Apprentice -> licensing is expected to work unmodified. - ---- - -## 4. Known-fragile / to verify (honest status) - -| Area | Confidence | Note | -|---|---|---| -| Overall Dockerfile + distrobox shape | High | Standard distrobox GUI/GPU pattern. | -| Base image + install command (`--auto-install --accept-EULA `) | High | Copied from SideFX's own `docker/Ubuntu/Dockerfile`; test-built end to end against the real 22.0.429 tarball. | -| `/opt/hfs` symlink | High | The installer only creates a major.minor symlink (`/opt/hfs22.0`); the Dockerfile adds the generic `/opt/hfs` one itself — confirmed by test build. | -| EULA date value | Medium | `2021-10-13` as of writing; SideFX can update the EULA without notice, check the legal page. | -| Licensing works under distrobox's shared netns | High | Confirmed with a real Apprentice activation via the GUI, over the host's shared network namespace. | -| Runtime library list | High | Vendor's list plus 4 libs it was missing for the GUI (`libegl1`, `libatomic1`, `libxkbfile1`, `libxcb-cursor0`), all confirmed by `ldd`-checking `houdinifx-bin`/Qt plugins and by an actual successful launch. | -| `houdini-run` strict-mode compatibility | High | `houdini_setup` isn't written for `set -euo pipefail` (unset vars, `which java` expected to fail silently) — fixed by relaxing those flags just around the `source`; confirmed end to end. | -| `sesinetd` auto-start via the launcher | High | Confirmed under distrobox's real non-root user + sudo setup, including the license-file-permission and stuck-cert fixes described in section 3. | -| distrobox default hostname | Medium | We pin it explicitly rather than trust the default. | -| Actual GUI rendering (X11/Wayland via XWayland) | High | Confirmed: real AMD hardware acceleration (`glxinfo` reports direct rendering, AMD Radeon Vega renderer, not a software fallback), Houdini FX runs and renders normally through XWayland on a Hyprland session. First launch was noticeably slow; subsequent launches were fluid. | -| AMD OpenCL (sims) | Low | Not set up here; needs ROCm/rusticl. GL/Vulkan viewport is fine. | +This copies the icon to `~/.local/share/icons/` on the host and writes +`~/.local/share/applications/houdini-houdini.desktop`. Distrobox also +auto-creates a generic `houdini.desktop` ("Terminal entering Houdini") when +the box is created — set `NoDisplay=true` in that file, or delete it, if you +don't want both entries in the app menu. diff --git a/houdini/build-and-push.sh b/houdini/build-and-push.sh index c44d1ee..880866c 100644 --- a/houdini/build-and-push.sh +++ b/houdini/build-and-push.sh @@ -2,7 +2,7 @@ # Build both variants (shared base) and push. Heavy: run when ready. set -euo pipefail -REGISTRY="${REGISTRY:-registry.lan:5000}" +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 diff --git a/houdini/docker/README b/houdini/docker/README deleted file mode 100644 index a248c8d..0000000 --- a/houdini/docker/README +++ /dev/null @@ -1,47 +0,0 @@ -There are two versions of the Dockerfiles, one for Ubuntu Linux and one for -Windows. Note that the Ubuntu image size is much smaller. - - -Prerequisites: -1. You need Docker and Docker-compose installed if you're on Linux. -2. You need Docker Desktop installed if you're on a Windows or Mac host. -3. You need to modify "EULA_DATE" in the Dockerfile to specify the date for the - installer's `accept-EULA` argument. For example, if the EULA at - https://www.sidefx.com/legal/license-agreement/ was last updated on - April 10, 2020, you would set "EULA_DATE" in the Dockerfile to 2020-04-10. -4. To run sesinetd within docker you must have container enabled licenses. - Regular licenses will not work within containers. - -To create a Houdini Docker image: -1. Download a build of Houdini from www.sidefx.com for the container's platform. -4. Navigate to one of the "Ubuntu" or "Windows" folders. -3. Ensure you have set "EULA_DATE" in the Dockerfile. -4. Run `docker-compose build` - - -Some handy docker-compose commands: -1. `docker-compose run -d -p 1715:1715 sesinetd` will create a container - running the license server (sesinetd). -2. `docker-compose run hython` will start up hython in the interactive terminal - running the container. In the Linux container hython is in - /opt/hfs[VERSION]. - In the Windows container, hython is in - C:/Program Files/Side Effects Software/Houdini[VERSION]. -3. `docker-compose build` will build/rebuild the Houdini Docker images. - - -Some notes about Docker: -1. Docker requires that the Windows image version matches your host's Windows - version. The current Windows Houdini image is based on windows:1903; you - might need to update the Dockerfile accordingly. -2. The Mac and Windows versions do not support the "host" network, but host is - reachable on the special DNS name "host.docker.internal". If you have a - running sesinetd license server on host and would like to connect to it for - license checkout, you could switch point hserver to it. -3. All platforms (Mac/Linux/Windows) support the Linux version image. Only - Windows hosts support the Windows image. -4. Don't forget to toggle which daemon (Linux or Windows) the Docker CLI talks - to if you are using Windows Docker Desktop. You can switch it from the - Docker Desktop menu by selecting: - "Switch to Windows containers to use Windows containers" and - "Switch to Linux containers to use Linux containers" diff --git a/houdini/docker/Ubuntu/Dockerfile b/houdini/docker/Ubuntu/Dockerfile deleted file mode 100644 index f628a36..0000000 --- a/houdini/docker/Ubuntu/Dockerfile +++ /dev/null @@ -1,15 +0,0 @@ -FROM ubuntu:22.04 - -RUN apt-get update && apt-get install -y --no-install-recommends bc fontconfig wget libasound2 libgl1 libglu1 libglu1-mesa libglx0 libice6 libnss3 libopengl0 libpci3 libsm6 libx11-6 libx11-xcb1 libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-randr0 libxcb-render-util0 libxcb-render0 libxcb-shape0 libxcb-shm0 libxcb-sync1 libxcb-util1 libxcb-xfixes0 libxcb-xinerama0 libxcb-xkb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxi6 libxkbcommon-x11-0 libxkbcommon0 libxrandr2 libxrender1 libxss1 libxt6 libxtst6 && rm -rf /var/lib/apt/lists/* - -RUN mkdir houdiniInstaller -COPY houdini* /houdiniInstaller/ - -# Please update the following EULA_DATE to match the latest updated -# date of EULA in yyyy-mm-dd format. E.g. "2020-05-05" -# For Houdini 18.0 and previous version, EULA_DATE should be left empty -ARG EULA_DATE="" -RUN tar -xf /houdiniInstaller/houdini* -C /houdiniInstaller \ - && ./houdiniInstaller/houdini*/houdini.install --auto-install --accept-EULA ${EULA_DATE} \ - && rm -r /houdiniInstaller - diff --git a/houdini/docker/Ubuntu/docker-compose.yml b/houdini/docker/Ubuntu/docker-compose.yml deleted file mode 100644 index 03aeea9..0000000 --- a/houdini/docker/Ubuntu/docker-compose.yml +++ /dev/null @@ -1,11 +0,0 @@ -version: '3' - -services: - hython: - container_name: hython - hostname: hython - build: - context: . - dockerfile: Dockerfile - network_mode: host - image: houdini:22.0 diff --git a/houdini/docker/Windows/Dockerfile b/houdini/docker/Windows/Dockerfile deleted file mode 100644 index 349d06b..0000000 --- a/houdini/docker/Windows/Dockerfile +++ /dev/null @@ -1,19 +0,0 @@ -FROM mcr.microsoft.com/windows:1903 - -SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"] - -COPY "houdini-*-win64-vc141.exe" "C:\\" - -# Please update the following EULA_DATE to match the latest updated -# date of EULA in yyyy-mm-dd format. E.g. "2020-05-05" -# For Houdini 18.0 and previous versions, EULA_DATE should be left empty -ARG EULA_DATE="" - -RUN Start-Process "C:\\houdini-*-win64-vc141.exe" '/S /AcceptEULA=${EULA_DATE} /DesktopIcon=No /FileAssociations=No /StartMenu=No' -Wait; - -RUN Remove-Item -Force "C:\\houdini-*-win64-vc141.exe" - -RUN $vtokens = (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Side Effects Software').ActiveVersion.Split('.'); \ - $helppath = (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Side Effects Software\Houdini').psobject.properties[$vtokens[0] + '.' + $vtokens[1] + '.0.' + $vtokens[2]].Value + 'houdini\help'; \ - Remove-Item -Force $helppath -Recurse; - diff --git a/houdini/docker/Windows/docker-compose.yml b/houdini/docker/Windows/docker-compose.yml deleted file mode 100644 index 6756024..0000000 --- a/houdini/docker/Windows/docker-compose.yml +++ /dev/null @@ -1,11 +0,0 @@ -version: '3' - -services: - hython: - container_name: hython - hostname: hython - build: - context: . - dockerfile: Dockerfile - image: houdini:22.0 -