jiebi/CodeConvo huggingface dataset:
Change:
{ stdenv, lib, fetchurl, zip, unzip <del> , jzmq, jdk, python , confFile ? "", extraLibraryPaths ? [], extraJars ? [] }: </del> <ins> , jdk, python , confFile ? "" , extraLibraryPaths ? [] , extraJars ? [] }: </ins> stdenv.mkDerivation rec { <del> name = "apache-storm-" + version; version = "1.2.1"; </del> <ins> pname = "apache-storm"; version = "2.1.0"; name = "${pname}-${version}"; </ins> src = fetchurl { <del> url = "mirror://apache/storm/${name}/${name}.tar.gz"; sha256 = "177dqgbviagrpvalg8h67mwiwwgmiqsg0hh97hcqqcjg71ypnjkv"; </del> <ins> url = "mirror://apache/storm/${name}/${name}.tar.gz"; sha256 = "1i3z08rfy7aavshrbrskv9dmlhx1fjgrhhqm0pczfam4vnas8yg2"; </ins> }; <del> buildInputs = [ zip unzip jzmq ]; </del> <ins> buildInputs = [ zip unzip ]; </ins> installPhase = '' mkdir -p $out/share/${name} mv public $out/docs mv examples $out/share/${name}/. <del> rm -f lib/jzmq* || exit 1 </del> mv external extlib* lib $out/. mv conf bin $out/. mv log4j2 $out/conf/.

Discussion:
, (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
According to this comment , should not be affected. Nontheless, this is a very old version and there are only two packages depends on it: rzmq (apparently supports 4.x but is broken since 2016) jzmq (support 3.x and looks unmaintained) jzmq is only needed by apache stom but the dependecy as since been dropped: see can you update apache storm so we can get rid of jzmq?
Change:
wxGTK = wxGTK30; boost = boost160; }; <ins> kicad-with-packages3d = kicad.overrideAttrs (old: { modules = old.modules ++ [ old.passthru.packages3d ]; }); </ins> kicad-unstable = python.pkgs.callPackage ../applications/science/electronics/kicad/unstable.nix { wxGTK = wxGTK30;

Discussion:
KISYSMOD and KISYS3DMOD point to missing directories. On my system they are and , respectively. Neither of these paths exist though. I do see a few other kicad-5.0.0 directories in the Nix store, but I'm not sure if I should use those (and if so, which one). the environment variables (Preferences Configure Paths...)
The library is also supposed to be at which does not exist while points to it.
Mostly fixed by . Symbols and footprints are now included, and the variables point to the correct location. We don't have the 3D models by default as they're five gigabytes, for that you need to use the derivation (which unfortunately means recompiling kicad for now).
Change:
"-DLLVM_INSTALL_TOOLCHAIN_ONLY=OFF" "-DMLIR_TOOLS_INSTALL_DIR=${placeholder "out"}/bin/" "-DLLVM_ENABLE_IDE=OFF" <del> "-DLLD_INSTALL_PACKAGE_DIR=${placeholder "out"}/lib/cmake/mlir" </del> <ins> "-DMLIR_INSTALL_PACKAGE_DIR=${placeholder "out"}/lib/cmake/mlir" </ins> "-DLLVM_BUILD_TESTS=${if doCheck then "ON" else "OFF"}" "-DLLVM_ENABLE_FFI=ON" "-DLLVM_HOST_TRIPLE=${stdenv.hostPlatform.config}"

Discussion:
Steps to reproduce the behavior: a package that depends on mlir via cmake and get the following error: Now it wasn't quite obvious to me at first, but I have a theory what is happening here: The the package has an and output, thus the static libraries end up in the output, while the cmake files end up in the output. I don't really know how output splitting works, but I guess that nix simply replaces all references to the path, for each output pretending there's only a single such out path, therefore creating a path where the static libraries don't actually exists. This is further confirmed looking at the store paths of the out output: which mlir-tblgen /nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/bin/mlir-tblgen ls /nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/lib/libMLIRPresburger.a /nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/lib/libMLIRPresburger.a (out output store path + path from the cmake output above) ls /nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/lib/cmake ls: cannot access '/nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/lib/cmake': No such file or directory (no cmake in the out output store path) ls /nix/store/zjjkxmbpwxh6w8f3gg145k9zg1wvl432-mlir-17.0.6-dev/lib/ cmake (the dev output contains only cmake in the lib directory) I've built mlir locally with , and the error is gone. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important].

[reaction]: [issues you find important]:
Thanks for your bug report. I have to double-check this, but as you suggested, it seems that it should use the or instead of the output. I'll check it later and fix it.
Change:
stdenv.mkDerivation rec { name = "zstd-${version}"; <del> version = "1.3.3"; </del> <ins> version = "1.3.4"; </ins> src = fetchFromGitHub { <del> sha256 = "15h9i9ygry0znlmvll5r21lzwgyqzynaw9q2wbj4bcn7zjy4c1pn"; </del> <ins> sha256 = "090ba7dnv5z2v4vlb8b275b0n7cqsdzjqvr3b6a0w65z13mgy2nw"; </ins> rev = "v${version}"; repo = "zstd"; owner = "facebook";

Discussion:
it'd be nice to have this as an optional package with the already existing package or as a standalone package
Change:
, Carbon , Cocoa , CoreMedia <ins> , withUnfree ? false </ins> }: let

Discussion:
I reported some flakey test in freerdp upstream and they hinted that maybe we could be building freerdp better: Filing this so I don't forget to look at it.
I use freerdp all the time, so I have patched things up on my side and will open a proper PR when I have been running with it for a while. FYI, we are in fact already building against ffmpeg.
Change:
makeCmakeFindLibs(){ isystem_seen= <ins> iframework_seen= </ins> for flag in $NIX_CFLAGS_COMPILE $NIX_LDFLAGS; do if test -n "$isystem_seen" && test -d "$flag"; then isystem_seen= export CMAKE_INCLUDE_PATH="$CMAKE_INCLUDE_PATH${CMAKE_INCLUDE_PATH:+:}${flag}" <ins> elif test -n "$iframework_seen" && test -d "$flag"; then iframework_seen= export CMAKE_FRAMEWORK_PATH="$CMAKE_FRAMEWORK_PATH${CMAKE_FRAMEWORK_PATH:+:}${flag}" </ins> else isystem_seen= <ins> iframework_seen= </ins> case $flag in -I*) export CMAKE_INCLUDE_PATH="$CMAKE_INCLUDE_PATH${CMAKE_INCLUDE_PATH:+:}${flag:2}"

Discussion:
I have a system without Command Line Tools or XCode and nix'es cmake can't find headers and tries to pick up system frameworks. Try to build this: On my system I get: System: Darwin Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: 17.09pre-git () Sandboxing enabled: no
Related to
Change:
stdenv.mkDerivation rec { pname = "gegl"; <del> version = "0.4.46"; </del> <ins> version = "0.4.48"; </ins> outputs = [ "out" "dev" "devdoc" ]; outputBin = "dev"; src = fetchurl { url = "https://download.gimp.org/pub/gegl/${lib.versions.majorMinor version}/gegl-${version}.tar.xz"; <del> hash = "sha256-0LOySBvId0xfPQpIdhGRAWbRju+COoWfuR54Grex6JI="; </del> <ins> hash = "sha256-QYwm2UvogF19mPbeDGglyia9dPystsGI2kdTPZ7igkc="; </ins> }; <del> patches = [ # https://gitlab.gnome.org/GNOME/gegl/-/merge_requests/136 # Fix missing libm dependency. (fetchpatch2 { url = "https://gitlab.gnome.org/GNOME/gegl/-/commit/ee970f10f4fe442cbf8a4f5cb94049deab33e786.patch"; hash = "sha256-0LLKH+Gg+1H83kN7hJGK2u+oLrw7Hxed7R4tTwT3C5s="; }) ]; </del> nativeBuildInputs = [ pkg-config gettext

Discussion:
Package name: gegl Latest released version: 0.4.48 <!-- Search your package here: --- Current version on the unstable channel: 0.4.46 Current version on the stable/release channel: 0.4.46 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- I can take over the package if you wish. Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If you are able to bump the package (and babl), feel free. I probably will not be able to get to it this week.
Change:
stdenv.mkDerivation rec { pname = "termius"; <del> version = "7.1.0"; </del> <ins> version = "7.15.1"; </ins> src = fetchurl { <del> url = "https://deb.termius.com/pool/main/t/termius-app/termius-app_${version}_amd64.deb"; sha256 = "801579b931ca0ad5340085df8863042336e2b609dd1cd6771260c873f3d2bb73"; </del> <ins> # Termius switched to using non-versioned downloads https://s3.amazonaws.com/termius.desktop.autoupdate/linux/Termius.deb url = "https://web.archive.org/web/20210710174019/https://s3.amazonaws.com/termius.desktop.autoupdate/linux/Termius.deb"; sha256 = "16zc7ywz3hl1awkc4wk0rd94nsy55l98j2yzfdxcjiixky4gk8wn"; </ins> }; desktopItem = makeDesktopItem {

Discussion:
Describe the bug cannot be installed because the requested URL returned error 403. To Reproduce Steps to reproduce the behavior: Expected behavior should be installed. Screenshots Relevant logs are as below: Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Change:
sourceVersion = { major = "3"; minor = "12"; <del> patch = "4"; </del> <ins> patch = "5"; </ins> suffix = ""; }; <del> hash = "sha256-9tQZpth0OrJnAIAbSQjSbZfouYbhT5XeMbMt4rDnlVQ="; </del> <ins> hash = "sha256-+oouEsXmILCfU+ZbzYdVDS5aHi4Ev4upkdzFUROHY5c="; </ins> }; };

Discussion:
Package name: python312 Latest released version: 3.12.5 <!-- Search your package here: --- Current version on the unstable channel: 3.12.4 Current version on the stable/release channel: 3.12.4 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
merged
Change:
<del> { lib , buildPythonPackage , fetchFromGitHub , setuptools-generate , setuptools-scm , colorama , jinja2 , jsonschema , pygls , tree-sitter0_21 , pytestCheckHook </del> <ins> { lib, buildPythonPackage, fetchFromGitHub, setuptools-generate, setuptools-scm, colorama, jinja2, jsonschema, pygls, tree-sitter, pytestCheckHook, </ins> }: buildPythonPackage rec {

Discussion:
Steps to reproduce the behavior: Originally found building Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
That's not a build failure, but an evaluation failure. If you want to make not depend on , you need to figure out where does this dependency comes from, and try to remove it. The reason we disabled is documented in the code: Note that although the issue is fixed, we intentionally provide an expression for , so that we can build with it. See also: You can work around this issue by using instead, or try to be creative and make depend on the latest (and not ), by fixing the upstream issue . Good luck!
I'm closing this, as this is an upstream issue. Ideally it would have been possible to declaratively write with Nix why packages are disabled for certain Python implementation, and that would have improved the evaluation failure message you observed. I think I saw discussion about such a feature, but I can't find any links now unfortunately.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
<del> { stdenvNoCC, lib, fetchFromGitea, just, inkscape, makeWrapper, bash, dialog }: </del> <ins> { stdenvNoCC, lib, fetchFromGitea, just, imagemagick, makeWrapper, bash, dialog }: </ins> stdenvNoCC.mkDerivation rec { pname = "kabeljau"; <del> version = "1.2.0"; </del> <ins> version = "2.1.0"; </ins> src = fetchFromGitea { domain = "codeberg.org"; owner = "annaaurora"; repo = "kabeljau"; rev = "v${version}"; <del> hash = "sha256-RedVItgfr6vgqXHA3bOiHXDpfGuHI+sX4jCHL9G5jYk="; </del> <ins> hash = "sha256-yZHDnzNTdDXHR+Pi3NODqw4npzuthHgOJYnTmIvGyUE="; </ins> }; # Inkscape is needed in a just recipe where it is used to export the SVG icon to several different sized PNGs. <del> nativeBuildInputs = [ just inkscape makeWrapper ]; </del> <ins> nativeBuildInputs = [ just imagemagick makeWrapper ]; </ins> postPatch = '' patchShebangs --host ${pname} <del> substituteInPlace ./justfile  --replace " /bin" " $out/bin"  --replace " /usr" " $out" </del> ''; installPhase = '' runHook preInstall <del> just install </del> <ins> just --set bin-path $out/bin --set share-path $out/share linux-install </ins> wrapProgram $out/bin/${pname} --suffix PATH : ${ lib.makeBinPath [ dialog ] }

Discussion:
Steps to reproduce the behavior: on Darwin Calls Inkscape which tries to create working files in the sandbox. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Is this really an Inkscape problem and not a this directory can't be created on darwin problem?
It's "inkscape breaks when run in the sandbox". I wonder if a tempdir would solve it.
Here's the relevant bit of the log: means Inkscape crashed. Unfortunately, this winds up hanging that's used after a change. I have a patch on hold while we clear these blockages (the patch unblocks 100+ packages on Darwin). Ii might work if inkscape was launched into a writable temp directory.
i can't test this since i don't have a darwin machine…
i guess the justfile can't be modified upstream because it'd be a nix-specific solution
Closing per (couldn't reproduce)
is cross-platform so it would work everywhere. It doesn't handle fancy text layouts well, but if you don't have that it would be a safe solution.
Please see for a working solution using
Change:
<ins> { lib , stdenv , fetchurl , installShellFiles }: let arch = with stdenv.hostPlatform; if isx86_64 then "amd64" else if isAarch64 then "arm64" else if isi686 then "386" else if isPower64 && isLittleEndian then "ppc64le" else if isS390x then "s390x" else throw "Unsupported arch: ${stdenv.hostPlatform.system}"; platform = if stdenv.hostPlatform.isDarwin && stdenv.hostPlatform.isAarch64 then "macos_arm64" else if stdenv.hostPlatform.isDarwin then "macos" else "linux_${arch}"; in stdenv.mkDerivation (finalAttrs: { pname = "ibmcloud-cli"; version = "2.17.0"; src = fetchurl { url = "https://download.clis.cloud.ibm.com/ibm-cloud-cli/${finalAttrs.version}/binaries/IBM_Cloud_CLI_${finalAttrs.version}_${platform}.tgz"; sha256 = { "x86_64-darwin"     = "18f0dylgwwn9p1jmchqhq061s435n85qr2872i532whbrziwwjf3"; "aarch64-darwin"    = "1rid6rv601z4ayd3yi5srqbfn5bspypxarikvm563ygxawh1bxyi"; "x86_64-linux"      = "0ry8ix5id2zk04w9d9581g127f9jpj7bwg3x0pk3n9yfwn61g96d"; "aarch64-linux"     = "0s5jaqhyl234670q1mg89in2g5b9w3gzvnzl8qmlmgqkaxvzxj94"; "i686-linux"        = "0iw8y7iy9yx7y8v8b2wfl24f2rv9r20yj7l4sislxspfyvqv54p2"; "powerpc64le-linux" = "19ac0na163l9h7ygbf3jwwv7zf0wagqvn6kcdh871c690i86wg9z"; "s390x-linux"       = "1zvy28jpxijzgdbr9q4rfyx6mk295mqp4nk8z299nm9ryk4q81lv"; }.${stdenv.hostPlatform.system} or (throw "Unsupported system: ${stdenv.hostPlatform.system}"); }; nativeBuildInputs = [ installShellFiles ]; installPhase = '' runHook preInstall install -D ibmcloud $out/bin/ibmcloud mkdir -p $out/share/ibmcloud cp CF_CLI_Notices.txt CF_CLI_SLC_Notices.txt LICENSE NOTICE $out/share/ibmcloud export HOME=$(mktemp -d) installShellCompletion --cmd ibmcloud --bash <($out/bin/ibmcloud --generate-bash-completion) runHook postInstall ''; meta = with lib; { description = "Command line client for IBM Cloud"; homepage = "https://cloud.ibm.com/docs/cli"; license = licenses.asl20; maintainers = with maintainers; [ emilytrau ]; platforms = [ "x86_64-linux" "aarch64-linux" "i686-linux" "powerpc64le-linux" "s390x-linux" ] ++ platforms.darwin; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; mainProgram = "ibmcloud"; }; }) </ins>

Discussion:
Project description <!-- Describe the project a little: --The command line client for . Metadata homepage URL: source URL: license: ? platforms: linux
Change:
"-drive if=pflash,format=raw,unit=1,file=$efiVars" ] ); <del> memSize = 1024; </del> <ins> inherit memSize; </ins> } '' export PATH=${binPath}:$PATH

Discussion:
Building an Amazon AMI with zfs root fails with inside the vm getting an error trying to allocate memory partway through building the new store. It isn’t surprising that a zfs-using system needs more memory when doing intensive filesystem writes. Unfortunately I don't know how to adjust the config (other than globally in a nixpkgs fork) for how much memory to give the vm. $ nix-build -A amazonImageZfs.x8664-linux … error: reading directory '/nix/store/4l99mg8j2c3bqjlc10ncdfcq5vaazxb9-nixos-22.11pre130979.gfedcba/nixos/pkgs/tools/misc/tagref': Cannot allocate memory (the specific package or failure point varies a little on each run based on random timings and resource usage) system: host os: multi-user?: sandbox: version: channels(root): channels(dan): nixpkgs:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
, qttools , re2 , spdlog <ins> , wrapQtAppsHook </ins> , voipSupport ? true , gst_all_1 , libnice }: <del> mkDerivation rec { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "nheko"; version = "0.11.1";

Discussion:
Steps to reproduce the behavior: i noticed the break after the nheko 0.10.2 -0.11.0 upgrade landed in nixos-unstable: hydra failure (click for the build log): build is currently broken in both master () and has been fixed in nixos-22.11, see for having initiated the backport. tagging as maintainer of both mtxclient and nheko. Please run and paste the result.
tested against the outstanding mtxclient 0.9.0 -0.9.1 PR: still broken.
I have no idea why a standard library would depend, let alone be missing, on a different architecture.
Likely due to us using outdated gcc (gcc9) on aarch64-linux. The story is complicated, but is being addressed.
Forcing it to use gcc11Stdenv may fix the issue.
It seems so: I tested by cross-compiling mtxclient (I don't have an aarch64 system).
Opened
Great... now coeurl fails to build. EDIT: Fixed, but nheko is still broken.
hope nobody minds this extra notification that is me thanking you all for jumping in so readily to fix things, even for someone you’ve never met. anyone reading this: what you’re doing here has more impact than you know.
Change:
'' + (if enableQt then '' substituteInPlace ./electrum/qrscanner.py  --replace ${libzbar_name} ${zbar.lib}/lib/libzbar${stdenv.hostPlatform.extensions.sharedLibrary} <ins> sed -i 's/qdarkstyle<2.7/qdarkstyle<3.0/' contrib/requirements/requirements.txt </ins> '' else '' sed -i '/qdarkstyle/d' contrib/requirements/requirements.txt '');

Discussion:
Describe the bug The recent commit causes electrum to fail to build with the error: No matching distribution found for qdarkstyle<2.7 To Reproduce Steps to reproduce the behavior: nixpkgs and checkout commit Expected behavior The build should complete successfully. Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): I DON'T USE channels nixpkgs: Maintainer information:
I tried this patch to remove the <2.7 restriction and electrum seems to work just fine. Apparently the reason for enforcing qdarkstyle<2.7 is to avoid making a dependency, per commit I'll check with upstream to see what they intend to do.
Change:
"-H:Name=${executable}" "-march=compatibility" "--verbose" <ins> "-J-Dsun.stdout.encoding=UTF-8" "-J-Dsun.stderr.encoding=UTF-8" </ins> ] # Extra arguments to be passed to the native-image , extraNativeImageBuildArgs ? [ ] # XMX size of GraalVM during build , graalvmXmx ? "-J-Xmx6g" <del> # Locale to be used by GraalVM compiler , LC_ALL ? "en_US.UTF-8" </del> , meta ? { } , ... } @ args:

Discussion:
After babashka can't display Unicode characters I have a babashka script that outputs the following JSON: The text is a Nerd Font Symbol code point. After the output is: Steps to reproduce the behavior: This has been fixed in the past by I did not test other packages that could be affected by the PR.
Pretty sure this is related to this bug in GraalVM upstream: I am curious if this is affecting projects using GraalVM 21.0.0 vanilla or if not, how is it working and why it is broken in .
It does seem that even setting up inside the C compiler environment is not sufficient to make it work. CC to see if they have more context on what the possibly issue is.
I also hit this today. I tested the same version(v1.3.186) from upstream binary release, which does not have this issue. Shall we always sync the same version of graavm as upstream build ci?
I don't think this is the issue and even if it was, it is not like babashka is the only GraalVM package we have.
I know that folks can't reproduce this issue with upstream, but I also can't reproduce it with GraalVM using Java, e.g.: A patch if anyone wants to test to be applied to : So, can anyone reproduce this issue with GraalVM Native Image itself? If not, the only thing I can think is that the issue here is the GCC (i.e.: non-static) version (upstream compiles with by default). Or something else.
So I got this warning: But this was after already started to build, so I assume this is the same issue as and need to be fixed upstream.
To explain in more details why I think this is an upstream issue: I don't get the same in the initial part of the build, only when the build starts that I get this warning. So what I assume is doing: Running the CC (C Compiler) inside a shell with clean environment We see the , because this shell couldn't set the proper locale thanks to missing environment variables (e.g.: ) Since this shell environment has no environment variables (at least, not the environment variables that we need), this ends up breaking macOS compilation and locale (Unicode) support in Linux Not sure why it works in GraalVM itself though yet. This is all really strange.

While I'm not familiar with graalvm, I do find a hack for this issue, maybe can weigh in to test whether this hack is valid: Some inspiration from a random reddit post and those issues: And I do find it's using , so I thought if I those two into build args, maybe it'd work. And indeed it seems to work.. After I built bb with above args,
BTW, I cannot reproduce with GraalVM Native Image on helloworld java as well. Helloworld produced by GraalVM Native Image has correct unicode output.
Thanks for investigating this issue. Opened so we can have this fixed.
Change:
type = types.attrsOf types.str; default = { }; example = { <del> HOME = "/tmp"; </del> OLLAMA_LLM_LIBRARY = "cpu"; <ins> HIP_VISIBLE_DEVICES = "0,1"; </ins> }; description = '' Set arbitrary environment variables for the ollama service.

Discussion:
Steps to reproduce the behavior: ollama service the model dir Ollama should work, files and directories have rw permissions for anyone and the file system is not read-only. It used to work before an update. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Could you try manually renaming the file to see if you get the same error? If you still get the error, the problem is probably with your system config. If you don't get the error, the problem could be with the ollama binary, or with the service config. Maybe try it as root as well to see if there's a difference. By the way, the reason it's trying to rename the files is due to a change in .
Renaming files solves the problem of starting ollama, but does not solve the overall problem. I can't install a new model, for example.
I found what the problem is. The ollama service has set, which creates a new user for the service and enables some sandboxing that includes making most of the filesystem read-only. I'm not sure at the moment the best way to fix this without compromising on security, so I'll do some more research on how systemd works, and any relevant systemd options. At worst, I should be able to create a nixos option that disables this sandboxing entirely. If you have any suggestions, I'd be happy to hear them.
In the meantime, a temporary workaround that I think should work is this nixos config: