feat: cleanup the houdini image setup
This commit is contained in:
Simon Lambin
164
houdini/CLAUDE.md
Normal file
164
houdini/CLAUDE.md
Normal file
@@ -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 <date>`, no `--make-dir`, no
|
||||
`--install-license`.** An earlier draft of this Dockerfile invented an
|
||||
`--install-license <path>` 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<ver>/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.
|
||||
@@ -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 <date>`) | 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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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"
|
||||
@@ -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
|
||||
|
||||
@@ -1,11 +0,0 @@
|
||||
version: '3'
|
||||
|
||||
services:
|
||||
hython:
|
||||
container_name: hython
|
||||
hostname: hython
|
||||
build:
|
||||
context: .
|
||||
dockerfile: Dockerfile
|
||||
network_mode: host
|
||||
image: houdini:22.0
|
||||
@@ -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;
|
||||
|
||||
@@ -1,11 +0,0 @@
|
||||
version: '3'
|
||||
|
||||
services:
|
||||
hython:
|
||||
container_name: hython
|
||||
hostname: hython
|
||||
build:
|
||||
context: .
|
||||
dockerfile: Dockerfile
|
||||
image: houdini:22.0
|
||||
|
||||
Reference in New Issue
Block a user