Two darwin-only issues surfaced when building on x86_64-darwin:
1. The conditional postPatch removed three test files
(ml/backend/ggml/ggml_test.go, ml/nn/pooling/pooling_test.go,
model/models/nemotronh/model_omni_test.go) that no longer exist
in v0.30.5 upstream. The `rm` failed with "No such file or directory"
and aborted patchPhase. Tests in the new paths
(e.g. fs/ggml/ggml_test.go) pass on darwin without removal — verified
via the test phase in this commit's local build.
2. preFixup ran `patchelf --shrink-rpath` unconditionally; patchelf is
ELF-only and darwin's Mach-O dylibs don't carry the build-dir RPATH
problem in the first place. Gated on stdenv.hostPlatform.isLinux.
Verified: nix-build -A ollama on x86_64-darwin (macOS 15.6.1, Sequoia)
lands /nix/store/.../ollama-0.30.5; checkPhase green for all listed
packages including x/models/gemma4; ollama --version reports 0.30.5.
Assisted-by: Claude Opus 4.7 <noreply@anthropic.com>
(cherry picked from commit bba51cb247)
Upstream patch release; notably fixes a divide-by-zero crash in
gemma3:12b. Bumps the vendored llama.cpp pin b9493 -> b9509 to match
upstream's LLAMA_CPP_VERSION. Verified ollama-cuda + ollama-vulkan
build on x86_64-linux.
https://github.com/ollama/ollama/releases/tag/v0.30.5
Assisted-by: Claude Opus 4.7 <noreply@anthropic.com>
(cherry picked from commit 0e1071782c)
Two layers were missing for ollama-vulkan after the 0.30.x bump's switch to
per-accelerator runners via ExternalProject_Add:
1. spirv-headers wasn't in nativeBuildInputs, so the parent cmake configure
never even saw `SPIRV-HeadersConfig.cmake`. Add it (header-only — native
is the right slot).
2. The runner sub-builds (`ollama-llama-server-vulkan` et al.) are launched
by `cmake/local.cmake`'s `ExternalProject_Add`, whose child cmake process
inherits env vars but not the parent's `-D` flags. Even after fixing
(1), the child's `find_package(SPIRV-Headers REQUIRED)` at
`ggml-vulkan/CMakeLists.txt:14` couldn't see the config, and once that
was worked around with `CMAKE_PREFIX_PATH` as env, the compile then
failed with `fatal error: spirv/unified1/spirv.hpp` — because
upstream's `target_link_libraries(ggml-vulkan PRIVATE Vulkan::Vulkan)`
notably does NOT link `SPIRV-Headers::SPIRV-Headers`, so the interface
include path the cmake config exports never flows into the compile
commands. Force the include via `NIX_CFLAGS_COMPILE` rather than
patching upstream's CMakeLists across llama.cpp pins.
Verified: `ollama-vulkan` builds end-to-end; `$out/lib/ollama/vulkan/libggml-vulkan.so`
is present (not a silent CPU fallback like the cuda variant suffered in
the first 0.30 attempt).
🤖 Assisted by Claude
(cherry picked from commit 6432d78bff)
Notable upstream build changes folded into this bump:
* llama.cpp moved from in-tree vendoring to CMake FetchContent, pinned
via the `LLAMA_CPP_VERSION` file at the repo root (b9493 here →
llama.cpp commit a731805c). Pre-stage it as `fetchFromGitHub` and
apply Ollama's compat patch in `postPatch` — neither
`cmake/local.cmake` nor `llama/server/CMakeLists.txt` auto-applies
the patch when the source is overridden via
`FETCHCONTENT_SOURCE_DIR_LLAMA_CPP` (the parent's `ExternalProject_Add`
passes `OLLAMA_LLAMA_CPP_SKIP_COMPAT_PATCH=ON` to the child build).
The `apply-patch.cmake` script is idempotent.
* Since 0.30, `cmake/local.cmake` splits the llama.cpp build into
per-runner sub-projects gated by `OLLAMA_LLAMA_BACKENDS`. Without
setting it, only the CPU runner is built — `ollama-cuda` /
`ollama-rocm` / `ollama-vulkan` would all silently fall back to CPU
at runtime, with `libggml-{cuda,hip,vulkan}.so` absent from
`$out/lib/ollama`. Map the package's `acceleration` value to the
cmake backend name the elseif chain accepts:
cuda → cuda_v${cudaMajor} (cuda_v12 / cuda_v13)
rocm → rocm_v${rocmMajor}_${rocmMinor} (rocm_v7_1 / rocm_v7_2)
vulkan → vulkan
* `cmd/launch/*_test.go` are integration tests for user-facing CLI
launchers (claude, qwen, cline, codex, kimi, droid, openclaw,
hermes, …) that install the target binary via npm and exec it on
PATH. Both prerequisites are unavailable in the nix sandbox, so the
launch subpackage's tests can't pass here. Drop them — same
precedent as the existing darwin Metal test removals.
* The llama.cpp sub-build is driven by ExternalProject_Add and does
not inherit the parent's `CMAKE_SKIP_BUILD_RPATH` setting, so its
`.so` payloads end up with build-dir entries in RPATH. Strip with
`patchelf --shrink-rpath --allowed-rpath-prefixes /nix/store` in
preFixup; `$ORIGIN` is preserved unconditionally (non-absolute
entries always allowed) so peer-lib lookup in `$out/lib/ollama`
still works.
Drive-by cleanup: deadnix + statix passes (overrideModAttrs unused
lambda args → `_:_`, `inherit (rocmPackages) stdenv;` /
`inherit (vulkan-tools) stdenv;` for `buildGoModule.override`, drop
unused `coreutils` input — the old launch-test substitutions that
needed coreutils are dropped along with the tests).
Release notes:
https://github.com/ollama/ollama/releases/tag/v0.30.4https://github.com/ollama/ollama/releases/tag/v0.30.0
Assisted-by: Claude Opus 4.7 <noreply@anthropic.com>
(cherry picked from commit 63e0d2d52d)
Otherwise the recursive chown can fail, hence wpa_supplicant doesn't
start, if some read-only file has been bind-mounted into
/etc/wpa_supplicant.
This can happen if one uses `extraConfigFile` to add a file that is
under /etc/wpa_supplicant.
(cherry picked from commit 197a055a02)
