Nix debug tools appreciated - NixOS build has failed for the past month - pipewire build failure on raspberry pi

I’ve tried to build the nix configuration for my server (a raspberry pi 4b) a few times over the past month, but I have repeatedly gotten the same build failure: pipewire. Its build environment claims that it depends on libcamera and doesn’t have it (even though pipewire in nixpkgs has had libcamera included by default and on the reqired v0.2.0 for a while). Pipewire is not even mentioned in its configuration, which confuses me even more. I went through its config files multiple times and I wasn’t able to find that might be pulling it in.

I thought this was an upstream issue, so I’ve waited a while to see if it would get solved, but it seems to be local given that I’ve waited over a month and things are still the same. I would really like to get to the bottom of this.


The build error is below. Are there any tools for viewing what files bring in what dependencies a nix configuration has? Or possibly for viewing all enabled nix options?

error: builder for '/nix/store/xsdmp9630lbrb329m7wmsig0y90ilxli-pipewire-1.0.5.drv' failed with exit code 1;
       last 10 log lines:
       > Run-time dependency jack found: YES 1.9.22
       > Run-time dependency vulkan found: YES 1.3.280
       > Has header "vulkan/vulkan.h" with dependency vulkan: YES
       > Dependency libcamera found: NO found 0.1.0 but need: '>= 0.2.0'
       > Run-time dependency libcamera found: NO (tried pkgconfig and cmake)
       > Looking for a fallback subproject for the dependency libcamera
       >
       > spa/meson.build:99:18: ERROR: Automatic wrap-based subproject downloading is disabled
       >
       > A full log can be found at /build/source/build/meson-logs/meson-log.txt
       For full logs, run 'nix log /nix/store/xsdmp9630lbrb329m7wmsig0y90ilxli-pipewire-1.0.5.drv'.
error: 1 dependencies of derivation '/nix/store/w8nn0l6f8ld413mj91q54r6iqyifbgsp-SDL2-2.30.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/9y234ggxyfccjwd3w4ad4ca4rl34ciib-openal-soft-1.23.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/yq0inaf139nkgdd0hyrxj9h366685lnr-gst-plugins-bad-1.22.9.drv' failed to build
error: 1 dependencies of derivation '/nix/store/kv26al19kx3xjyzdczkn38bm19kgyfal-gtk4-4.12.5.drv' failed to build
error: 1 dependencies of derivation '/nix/store/acj6maaw2q2d9b9202rrbgk50vfxabam-NetworkManager-fortisslvpn-gnome-1.4.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/dxhrk8vjw6f6ln0ms0wgv3agmqrzhd2w-NetworkManager-l2tp-gnome-1.20.14.drv' failed to build
error: 1 dependencies of derivation '/nix/store/6vrdzir8rsrmjm7mm93c4rh8vrm0qxhw-NetworkManager-openconnect-1.2.10.drv' failed to build
error: 1 dependencies of derivation '/nix/store/1siqm60x7qjy171rl29qf3dm4pnvjbna-NetworkManager-openvpn-1.10.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/wx8iys17jsjid56i96h12w4y4ghw8wqs-NetworkManager-sstp-gnome-1.3.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/9d8qaggvzb71vv62w8hssmrn9zkdgqx6-NetworkManager-vpnc-1.2.8.drv' failed to build
error: 1 dependencies of derivation '/nix/store/p5kha7pb2rxshapdi6pc7w00x7s6mgwp-gcr-4.1.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/idagc605vbacjm4kwkrcf4lmngcr5c2p-etc.drv' failed to build
error (ignored): error: cannot unlink '/tmp/nix-build-linux-6.1.63.drv-1/source/build': Directory not empty
error: 1 dependencies of derivation '/nix/store/rxgx052vn5bq5msh5imxxg77vh53l93w-system-path.drv' failed to build
error: 1 dependencies of derivation '/nix/store/dn47rzzwrzjjmpcrsr4qdr6yvadlk48f-nixos-system-srv-24.05.20240427.58a1abd.drv' failed to build

I tried to reproduce the build failure of pipewire, but both a local cross build with nix build github:NixOS/nixpkgs/master#pkgsCross.aarch64-multiplatform.pipewire and the native builds for aarch64 on Hydra are working fine.

Hmm, interesting. I tried running that on my x86 desktop, as well as my aarch64 raspberry pi, and it built successfully in both places. Seems to indicate that there’s something else causing the problem, possibly something that’s not from nixpkgs? I have all my flake’s inputs up-to-date, but it’s possible there’s something in there I wasn’t expecting?

Are you by any chance mixing multiple Nixpkgs as your flake inputs, or using an overlay that comes with an override of the libcamera or the pipewire package?

Turns out it was this: inputs.raspberry-pi-nix.nixosModules.raspberry-pi in modules from my flake.nix, which came from github:tstat/raspberry-pi-nix in my inputs. I used it to get started with my raspberry pi running NixOS, but maybe it’s not needed as much any more?

Glad that you found the culprit. By the way, the overriding of libcamera is done in the libcamera overlay, which is separate from the core overlay provided by the flake. Maybe you can use the core overlay without the libcamera one.

From a glance it seems like the raspberry-pi-nix flake mainly helps in generating config.txt from Nix options, and it provides the RPi’s fork of the kernel. While it is possible to run NixOS on Raspberry Pi’s without such helper flake (which I do on my own Pi’s), I’m not sure if it’s easy to migrate away from the helper flake.

Oh huh, I was unaware that the raspberry pi requires a special kernel. No wonder I have to build it all the time :stuck_out_tongue:. How do you manage your pi’s? Or, what’s the “recommended” way to use them with NixOS? I started using this helper flake because it made it easy to generate a boot image, which I had failed to do many times previously.

Also, do you happen to know what the relevance of config.txt is when not using the official debian image? I used to think it was only used by the official image.

I should probably do this too - cc @tstat

*opened an issue

1 Like

raspberry pi requires a special kernel

It doesn’t require a special kernel—my Pi’s are running the mainline kernel, and the entry on NixOS wiki also uses the mainline kernel. I don’t know the differences between the two kernels for Pi’s, but my Pi’s are working for all the things that I need them to do.

How do you manage your pi’s

My main Pi is setup in a somewhat… non-standard way. I installed the Raspberry Pi 4 UEFI Firmware Images (link to GitHub) to the EFI partition, and have it boot up systemd-boot just like on an X86 host. The setup process is briefly documented on the readme of my repo for it (link to Codeberg).

the relevance of config.txt when not using the official debian image

The config.txt file is relevant regardless of the choice of OS, because the config file is read by the firmware (link to RPi docs).

*Updated to include my setup.

Thanks for the link to your config! Consider it starred! I had no idea the raspberry pi could boot with UEFI, it’s something I’ll have to look into doing if I can’t solve this (or if I reinstall in the future). Sounds like I would probably need to reinstall to do it.

I run my pi completely headless because I don’t have a micro hdmi connector (perhaps I should get one :stuck_out_tongue:), so I needed to have my image come with an SSH public key pre-accepted so I could login over the network, which added additional complications to the first time I installed, maybe this could be rolled in too? I wish setting up the rpi wasn’t such an involved process … :frowning:

Ohh I see. So I should probably stick with using the helper flake. (I assume it would break.)

I wonder what would happen if I restart after building without the helper. Part of me thinks it might not boot, but given that this is keeping me from updating it with the rest of my systems, I kinda want to try. Any idea what might happen?

Beware that my setup is pretty non-standard compared to using the official SD card images.

That’s what users.users.<username>.openssh.authorizedKeys.keys is for. You can use nixos-generators (link to GitHub) with your NixOS configuration containing the SSH key preshared to generate a custom image, and use that generated image on an SD card for the first-time setup. I feel the pain of setting up headless devices though.

*Update: The wiki entry suggests another way by just moving the SD card and edit $HOME/.ssh/authorized_keys on another machine. This is a much easier option.

I have no idea. My guess is that it would break, potentially with no easy way to rollback :wink:.

1 Like

Thanks, I needed to hear that. :stuck_out_tongue:

Oh I can’t believe I didn’t think of that :laughing:. Much easier than all the hurdles I was trying to jump over to do it The Nix Way™.


I’ll wait and see what transpires in the issue on github, and try removing the libcamera stuff from the flake myself.

Thanks for your help!

1 Like