Test locally changed package that is used by a systemd service

I try to find a way to test a new version of a locally changed package within my system configuration.
I saw there is a new pipewire version so i took the pipewire folder from nixpkgs and modified version and hash in default.nix:

rev = "0.3.49";
sha256 = "sha256-8heX/9BsPguIOzHOuqEQdt6MS3eS4HxR4A+FUZKNpdo=";

Then I changed the package variable of the enabled pipewire service in my configuration.nix:

services.pipewire.package = (pkgs.callPackage /home/denna/projects/pipewire-nix/default.nix { });

There is no error but after nixos-rebuild switch pipewire is still on version 0.3.48 despite that 0.3.49 got build and is available in the store.
(I restarted the computer to be sure its not just that systemd havn’t been updated sufficiently)
I see that the recommendation is to keep the change of the package within nixpkgs, but I want to understand why my attempt doesn’t work.

I looked in the wrong way for the version that is used by systemd and in my user-environment i had a version that covered the version of pipewire that is used by cli. I just had to uninstall that to reduce confusion.

What you’re describing should work: nixpkgs/pipewire.nix at 9b168e5e62406fa2e55e132f390379a6ba22b402 · NixOS/nixpkgs · GitHub

Where are you checking this version? Did you restart the service, and/or computer? It being in systemd.packages makes me wonder if it requires a full systemd restart to take effect.

yes i restarted my computer.

If you’re using pipewire --version, any chance you have the nixpkgs version in an environment.systemPackages somewhere, causing that to mask the one added by services.pipewire.enable?

Personally I would create an overlay and use overrideAttrs to change the version used in the pipewire derivation, but copying the directory and callPackage-ing is effectively doing the same thing, so something else must be wrong.

Oh, also keep in mind that the version attribute may well be set to the old version, in which case it will look like the package hasn’t updated, but that’s just cosmetic.

the version is changed in nixpkgs/default.nix at 9b168e5e62406fa2e55e132f390379a6ba22b402 · NixOS/nixpkgs · GitHub
this is also the folder I copy/paste: pkgs/development/libraries/pipewire

Probably needs systemctl daemon-reload

unfortunately doesn’t help.

Systemd should warn about that, though, and restarting the whole device will have the same effect… I’m stumped at this point. I’d check what binary the unit is actually running with systemctl status, and if that’s the correct version figure out where the version from my PATH is coming from.

ok you are right that it works. i just don’t understand where the “user-environment” pipewire is comming from:

[olaf@nixos:~]$ systemctl --user status pipewire
â—Ź pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/etc/systemd/user/pipewire.service; linked-runtime; vendor preset: enabled)
    Drop-In: /nix/store/9x3yg7yb9cb9vd8ka7g51wbqf0gfd7h5-user-units/pipewire.service.d
     Active: active (running) since Wed 2022-03-30 17:19:41 CST; 1h 20min ago
TriggeredBy: â—Ź pipewire.socket
   Main PID: 1380 (pipewire)
      Tasks: 2 (limit: 19085)
     Memory: 4.7M
        CPU: 1.414s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
             └─1380 /nix/store/y9f9bbwl3jyslhsyhp21v2507q5mrjg7-pipewire-0.3.49/bin/pipewire

Mar 30 17:19:41 nixos systemd[1280]: Started PipeWire Multimedia Service.

[olaf@nixos:~]$ whereis pipewire
pipewire: /etc/pipewire /nix/store/lirmg3cwnahcwsvvrb4gwakwkykn89rx-user-environment/bin/pipewire /nix/store/wnqiw6mp0sh8iba8288gfxzl94j547m3-system-path/bin/pipewire

[olaf@nixos:~]$ /nix/store/lirmg3cwnahcwsvvrb4gwakwkykn89rx-user-environment/bin/pipewire --version
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48

[olaf@nixos:~]$ /nix/store/wnqiw6mp0sh8iba8288gfxzl94j547m3-system-path/bin/pipewire --version
Compiled with libpipewire 0.3.49
Linked with libpipewire 0.3.49

its from some nix-env attempt a few days ago.

Ah, yes. Anything installed with nix-env isn’t coupled to the system configuration, but your “profile”. This is doubly bad because root has a separate profile which will get very confusing if you’ve ever stuck a sudo in front of that, as many people do out of package installing habit from other distros. Using nix-env on NixOS is an anti-pattern, it leads to situations like this - probably the 10th time or so I’ve actively been confused by this myself, if usually through others not mentioning they use it :wink:

Just remove all your nix-env'd packages, use environment.systemPackages in the future and forget that command even exists.

I got into using this because whatever I tried, the installation didn’t change. But the problem was that i didn’t update the hash. Is this a bug in fetchFromGitLab or expected behavior? I needed to add a wrong hash first to get the new one. I would expect to that a rev/version change would lead to the error the wrong key triggers.

I don’t know in detail what happened with your experiment here, but rather than using a “garbage” hash I’d suggest using an empty string. Nix will then use sha256-AAAAAAAAAAAAAAAAAAAAAAA or whatever, which is much easier to spot as a garbage hash than a valid one.

what happened was that only changing version didn’t trigger any error.
Setting rev = "0.3.49"; just recompiled (not even sure about that) and wrote the old version into a new folder with the new rev/version name.

Yep! That’s expected. Nix uses the checksum to assert whether the input has changed, if the checksum doesn’t change obviously the input didn’t change so you can skip the download. If the user supplied a false checksum with their input that’s on them. See the nix pills section on the topic of fixed-output derivations. It’s how you get to download things in the otherwise pure build system, since normally external dependencies and side effects aren’t allowed.

I think in this case it will rebuild, because you updated the version in the derivation, so the derivation changed and it must rebuild in case there was an actual meaningful change. To my knowledge there are no intermediate build output caches.

1 Like