We are migrating packages that meet below requirements:
1. using `callPackage`
2. called path is a directory
3. overriding set is empty (`{ }`)
4. not containing path expressions other than relative path (to
makenixpkgs-vet happy)
5. not referenced by nix files outside of the directory, other
than`pkgs/top-level/all-packages.nix`
6. not referencing nix files outside of the directory
7. not referencing `default.nix` (since it's changed to `package.nix`)
8. `outPath` doesn't change after migration
The tool is here: https://github.com/Aleksanaa/by-name-migrate.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
upstream added this extra cp, but it fails because it has already copied over the required symlinks. since we provide our own runtime anyway, i'm not sure what value this has regardless.
+ for dep in $(ldd "${BUILD_DIR}/bin/ollama_llama_server" | grep "=>" | cut -f2 -d= | cut -f2 -d' ' | grep -v "${GOARCH}/rocm${ROCM_VARIANT}" | grep -e rocm -e amdgpu -e libtinfo -e libnuma -e libelf)
+ cp -a /nix/store/d7wl4hnydqbqc2j1qg29sybpc614wkz8-rocm-path/lib/libhipblas.so.2 /nix/store/d7wl4hnydqbqc2j1qg29sybpc614wkz8-rocm-path/lib/libhipblas.so.2.0 ../../dist/linux-amd64//../linux-amd64-rocm/lib/ollama
++ readlink -f /nix/store/d7wl4hnydqbqc2j1qg29sybpc614wkz8-rocm-path/lib/libhipblas.so.2
+ '[' /nix/store/2c04lrnax0x0jcdrdins3wykm1lb1360-hipblas-6.0.2/lib/libhipblas.so.2.0 '!=' /nix/store/d7wl4hnydqbqc2j1qg29sybpc614wkz8-rocm-path/lib/libhipblas.so.2 ']'
++ readlink -f /nix/store/d7wl4hnydqbqc2j1qg29sybpc614wkz8-rocm-path/lib/libhipblas.so.2
+ cp /nix/store/2c04lrnax0x0jcdrdins3wykm1lb1360-hipblas-6.0.2/lib/libhipblas.so.2.0 ../../dist/linux-amd64//../linux-amd64-rocm/lib/ollama
cp: '/nix/store/2c04lrnax0x0jcdrdins3wykm1lb1360-hipblas-6.0.2/lib/libhipblas.so.2.0' and '../../dist/linux-amd64//../linux-amd64-rocm/lib/ollama/libhipblas.so.2.0' are the same file
This removes the absurd mechanism introduced to jam them into the
patches attribute, along with the pointless busywork of updating
the list of patches and their hashes on every release.
buildGoModules runs preBuild hooks in the module download fixed-output
derivation, so llama.cpp got built and immediately discarded, to then
immediately be built again for the actual Go build.
Pr #323249 removed `rocmPath` from `LD_LIBRARY_PATH`, but the comment
> since `rocmPath` is in `LD_LIBRARY_PATH`, ollama uses rocm correctly
makes me think I already tested this and that it doesn't work
`linuxPackages.nvidia_x11` is a driver, and isn't intended to be directly linked like a library.
`autoAddDriverRunpath` should be able to make ollama work without it.
