sops-install-secrets: Add option to disable tests

[Noodlez1232]

When cross-compiling sops-install-secrets, running the tests can take a long time, especially when using qemu binfmt emulation for the different hosts. I'd love to be able to disable these tests to speed up my NixOS build times.

[IncredibleLaser]

Does this even work reliably with qemu binfmt anymore?

A month ago, I was able to build this for a aarch64-Linux host on my x86_64 machine within minutes. Now, it just stays hours either at buildPhase or installPhase (basically choosing one at random), maxing out a core without any visible progress.

Currently, I'm stuck again at building sops-install-secrets-0.0.1 (buildPhase): Building subPackage ./pkgs/sops-install-secrets (this has been running for over an hour) and from my experience I had at the beginning of the week, if I cancel this and restart, it might get to checkPhase.

I'd guess this is related to golang/go#70329

Anyhow, before I sent this off, I could get it to work by disallowing parallel building, checking and installing. So it does seem to be the linked issue. Building took very long (about 23 minutes here), but it was always doing something and it eventually completed, in less time than I gave it when not limiting the build.

In case you're hit by this as well, you can do the following for the affected hosts (quick and dirty, maybe there's a better way to do this):

sops.package =
  inputs.sops-nix.packages.${pkgs.stdenv.hostPlatform.system}.sops-install-secrets.overrideAttrs
    {
      enableParallelBuilding = false;
      enableParallelChecking = false;
      enableParallelInstalling = false;
    };

Since this is only for one of my machines, this is enough, otherwise you might to do more to make this flexible and depending on architecture… Though I'd prefer if the bug didn't exist in the first place.

[jaanonim]

I have similar issue but it's getting stuck later on install:

building sops-install-secrets-0.0.1 (installPhase): Running phase: installPhase

Even when i use this workaround :-(

[SuperSandro2000]

You can do that via an overlay and overrideAttrs with doCheck = false or is that not working?

[IncredibleLaser]

You can do that via an overlay and overrideAttrs with doCheck = false or is that not working?

Maybe I misunderstand you, but I don't think an overlay (as in nixpkgs.overlays) does anything here. The respective option by default doesn't refer to a package in pkgs. And personally, from my own limited experience, I don't think this affects the tests only. It can seemingly fail there, but it can also fail anywhere else. But I might be wrong.

Also, the offending package already ships with that exact option:

sops-nix/pkgs/sops-install-secrets/default.nix

Line 21 in 2d0cf89

doCheck = false;

[SuperSandro2000]

What do you mean it can fail "anywhere"? If it can fail anywhere building the package than disabling the tests probably won't help.

What you linked is not an option, it is a condition to support Darwin to not build the test binary where is run somewhere else.

Is building that binary what fails? Please post some logs.

[IncredibleLaser]

Building worked for me after I applied the attributes I posted before.

What do you mean it can fail "anywhere"? If it can fail anywhere building the package than disabling the tests probably won't help.

The build doesn't visibly fail, it will just stall, at least in my case I had a qemu process that maxed out a core, but there was no visible progress. The same symptoms as in the issue I linked. There is no failure that you can easily observe, but it can hang in buildPhase or installPhase.

What you linked is not an option, it is a condition to support Darwin to not build the test binary where is run somewhere else.

You need to explain that to me (if you want), the only Darwin-conditional I see is in line 29 where postInstall depends on stdenv.isLinux, line 21 I linked is non-conditional and already sets doCheck = false.

Is building that binary what fails? Please post some logs.

Yes, it's sops-install-secrets that is the issue only, sops itself probably wouldn't be an issue because that binary usually runs on the platform you build on, but sops-install-secrets is run on the target with a different architecture to decrypt the secrets.

[jaredmontoya]

Issue reproduction instructions:
Try to run nix build --system aarch64-linux .#sops-install-secrets on a x86_64-linux system with:

boot.binfmt.emulatedSystems = [ "aarch64-linux" ];

It should hang forever.

This is a big issue when for example you want to deploy to a weak raspberry pi which can't build it's configuration by itself and the only powerful machines you have are x86_64-linux.

Unfortunetely like you said disabling tests probably won't help and the core issue is golang/go#70329 which didn't affect the go 1.22 compiler.

[SuperSandro2000]

Building worked for me after I applied the attributes I posted before.

There you reduce parallelism to a minimum. Does running the build with -j1 also fix it?

---

Did you try real cross compilation without using binfmt?

[IncredibleLaser]

There you reduce parallelism to a minimum. Does running the build with -j1 also fix it?

Aren't these doing exactly that? I checked the processes during build and it was always go … -j1 with my fixes applied when it worked, and they failed with -j 24 (12 cores with 2 threads each) when nothing was applied.

So yes, running it with -j1 fixed it for me, but the only other way I see to achieve this is via --cores 1, but then you have to build everything with a single thread, or am I mistaken?

[jaredmontoya]

Did you try real cross compilation without using binfmt?

nixpkgs = {
  hostPlatform = {
    system = "aarch64-linux";
  };
  buildPlatform = {
    system = "x86_64-linux";
  };
};

This is what happens (some go package fails to cross compile):

error: Cannot build '/nix/store/isbmchy6d7r1c2zdqc17g2m70sck23j3-carapace-1.6.0-go-modules-aarch64-unknown-linux-gnu.drv'.
       Reason: builder failed with exit code 1.
       Output paths:
         /nix/store/l6rf0dp381z94dxy8hjvrap75bd5pfch-carapace-1.6.0-go-modules-aarch64-unknown-linux-gnu
       Last 25 log lines:
       > source root is source
       > unpackPhase completed in 2 minutes 34 seconds
       > Running phase: patchPhase
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: configurePhase
       > Running phase: buildPhase
       > go: downloading github.com/carapace-sh/carapace v1.11.0
       > go: downloading github.com/carapace-sh/carapace-spec v1.5.0
       > go: downloading github.com/carapace-sh/carapace-selfupdate v0.0.10
       > go: downloading github.com/carapace-sh/carapace-bridge v1.5.0
       > go: downloading github.com/spf13/cobra v1.10.2
       > go: downloading github.com/carapace-sh/carapace-shlex v1.1.1
       > go: downloading gopkg.in/yaml.v3 v3.0.1
       > go: downloading github.com/carapace-sh/carapace-pflag v1.1.0
       > go: downloading github.com/pelletier/go-toml v1.9.5
       > go: downloading github.com/carapace-sh/ssh_config v1.4.1-0.20251016142129-177d27a2d08a
       > go: downloading gopkg.in/ini.v1 v1.67.1
       > go: downloading golang.org/x/mod v0.32.0
       > # runtime/cgo
       > aarch64-unknown-linux-gnu-gcc: error: unrecognized command-line option '-m64'
       > cmd/carapace/main.go:13: running "go": exit status 1
       > # runtime/cgo
       > aarch64-unknown-linux-gnu-gcc: error: unrecognized command-line option '-m64'
       > cmd/carapace/cmd/shim/generate.go:3: running "go": exit status 1
       For full logs, run:
         nix log /nix/store/isbmchy6d7r1c2zdqc17g2m70sck23j3-carapace-1.6.0-go-modules-aarch64-unknown-linux-gnu.drv
error: Cannot build '/nix/store/974y35r3i5mmdymf9vqw7wv27q1c0cb5-carapace-aarch64-unknown-linux-gnu-1.6.0.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/zfirap5ch0wlnbydcj80a5kz6y9ldkgy-carapace-aarch64-unknown-linux-gnu-1.6.0

[IncredibleLaser]

There are also other packages that fail real cross compilation, for example nginx which in the past I did in fact need to build: https://trac.nginx.org/nginx/ticket/2240 and https://trac.nginx.org/nginx/ticket/1928 which is the primary reason I went with binfmt in the first place

[SuperSandro2000]

I am not convinced this would be a good change. We are just fighting symptoms of deeper problems here.

I would recommend to replace

sops-nix/modules/home-manager/sops.nix

Lines 233 to 240 in e85540f

	package = lib.mkOption {
	type = lib.types.package;
	default = (pkgs.callPackage ../.. { }).sops-install-secrets;
	defaultText = lib.literalExpression "(pkgs.callPackage ../.. {}).sops-install-secrets";
	description = ''
	sops-install-secrets package to use.
	'';
	};

with a package that suites your need more.

[IncredibleLaser]

Just replacing the package in the home-manager module wouldn't be enough for most people, for example I don't even use the home-manager module on NixOS with home-manager enabled and just set the owner for the users' files; and even then the question would be what package would be a replacement? I'm not aware of any other package (other than overrides for the original) that would work here.

Also, I'm not sure which change you're talking about – adding the sequential attributes to the default build? I think it wouldn't make sense to add them by default, but what could be done is adding another package like sops-install-secrets-qemu (name might not be perfect but you get the gist) that has these parameters enabled and add a section to the documentation mentioning that it might be needed to select this package for hosts that are built for using qemu.

[cyberworm-uk]

I think the issue is upstream. It's good to have it documented here with potential work arounds but it's not actually sops-nix where the problem is. The sops.package option to apply overrides to disable parallel building has been working for me.

However, I was just trying to make a minimal test case for this and to my surprise, it just builds for me with no intervention at all after an update (running with nixos-unstable).

λ nix build "github:mic92/sops-nix#packages.aarch64-linux.sops-install-secrets" -L --rebuild
# not following nixConfig from remote flake...
sops-install-secrets> Running phase: unpackPhase
sops-install-secrets> unpacking source archive /nix/store/l027s51pv1b41nf9x8xgv7wkcm7dkicx-source
sops-install-secrets> source root is source
sops-install-secrets> Running phase: patchPhase
sops-install-secrets> Running phase: updateAutotoolsGnuConfigScriptsPhase
sops-install-secrets> Running phase: configurePhase
sops-install-secrets> Running phase: buildPhase
sops-install-secrets> Building subPackage ./pkgs/sops-install-secrets
sops-install-secrets> buildPhase completed in 6 minutes 22 seconds
sops-install-secrets> Running phase: installPhase
sops-install-secrets> installPhase completed in 1 minutes 36 seconds
sops-install-secrets> Running phase: fixupPhase
sops-install-secrets> shrinking RPATHs of ELF executables and libraries in /nix/store/4zs4syyrbwlrsj1mjw948skxzp8zccv8-sops-install-secrets-0.0.1
sops-install-secrets> shrinking /nix/store/4zs4syyrbwlrsj1mjw948skxzp8zccv8-sops-install-secrets-0.0.1/bin/sops-install-secrets
sops-install-secrets> checking for references to /build/ in /nix/store/4zs4syyrbwlrsj1mjw948skxzp8zccv8-sops-install-secrets-0.0.1...
sops-install-secrets> patching script interpreter paths in /nix/store/4zs4syyrbwlrsj1mjw948skxzp8zccv8-sops-install-secrets-0.0.1
sops-install-secrets> stripping (with command strip and flags -S -p) in  /nix/store/4zs4syyrbwlrsj1mjw948skxzp8zccv8-sops-install-secrets-0.0.1/bin
sops-install-secrets> shrinking RPATHs of ELF executables and libraries in /nix/store/sxpg6vpjgczw972qilax0p90ig4vw24a-sops-install-secrets-0.0.1-unittest
sops-install-secrets> shrinking /nix/store/sxpg6vpjgczw972qilax0p90ig4vw24a-sops-install-secrets-0.0.1-unittest/bin/sops-install-secrets.test
sops-install-secrets> checking for references to /build/ in /nix/store/sxpg6vpjgczw972qilax0p90ig4vw24a-sops-install-secrets-0.0.1-unittest...
sops-install-secrets> patching script interpreter paths in /nix/store/sxpg6vpjgczw972qilax0p90ig4vw24a-sops-install-secrets-0.0.1-unittest
sops-install-secrets> stripping (with command strip and flags -S -p) in  /nix/store/sxpg6vpjgczw972qilax0p90ig4vw24a-sops-install-secrets-0.0.1-unittest/bin

qemu and kernel version

λ /nix/store/zp6ng0m41wfpp5xf7bjzxsypb4a94fhc-qemu-user-10.2.1/bin/qemu-aarch64 --version
qemu-aarch64 version 10.2.1
Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
λ uname -a
Linux desktop 6.19.2 #1-NixOS SMP PREEMPT_DYNAMIC Mon Feb 16 16:11:45 UTC 2026 x86_64 GNU/Linux

---

Maybe also worth noting: the original post was just that tests take a long time, rather than "it deadlocks with -j >1". To address that, this will skip the tests where doCheck = false; doesn't:

sops.package =
  sops-nix.packages.${pkgs.stdenv.hostPlatform.system}.sops-install-secrets.overrideAttrs
    {
      postInstall = "";
      outputs = [ "out" ];
    }

[IncredibleLaser]

However, I was just trying to make a minimal test case for this and to my surprise, it just builds for me with no intervention at all after an update (running with nixos-unstable).

Same, just tried and it seemed to work.