MLX backends require xcrun metal/metalib which are unavailable in the
Nix sandbox. Pass -DOLLAMA_MLX_BACKENDS="" to cmake to skip the
Metal toolchain check. Core Metal/llama.cpp backend is unaffected.
Addresses two review comments — different reviewers, same direction:
* @SuperSandro2000 on the original PR #528150 (line 118 of
pkgs/by-name/ol/ollama/package.nix): "Why are we not using tag if
there is a tag?". Drop the SHA + `# tag b9509` shape that required
reviewers to cross-check the SHA matched the inline comment.
* @prusnak on this follow-up #528374: "I think we should use `tag`
instead of `rev`." `fetchFromGitHub`'s dedicated `tag` field is
preferred over `rev = "<tag-string>"` — same git object, same
tarball, same hash, but signals intent at the schema level and
renders into the store path nicely.
* Line 113 prose comment (the other half of SuperSandro's review on
#528150): "We should not repeat the version in this comment and
have to update that, too, on every update." Drop `currently b9509`
from the prose; the remaining text explains the mechanism (tracks
upstream's `LLAMA_CPP_VERSION` file, pre-staged because
FetchContent can't network in the sandbox) without naming a
specific version that would drift on every bump.
Pure source-readability change. `nix-build -A ollama --no-out-link`
on x86_64-linux produces the same store path as master, confirming
the tag resolves to the same git object → same tarball → same hash
→ no rebuild impact.
The same lines exist on `release-26.05` via the original backport
#528272; happy to mirror this fix there if you apply the
`backport release-26.05` label.
Assisted-by: Claude <noreply@anthropic.com>
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>
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>
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
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>
