I would like to build an upstream package and perform some debugging and troubleshooting. It’s not clear to me how to go about this.
I’ve cloned nixpgs and I’ve “built” against my local repo. Of course, all this does is retrieve from the binary cache since the hash hasn’t changed. I realize I can make a change to the derivation to trigger an actual build, but what I actually want to do is manipulate the source of the upstream code itself. I want to make change to the code, build, and try things.
The reason I want to do this is that there are bugs in one or more NixOS packages. The upstream code is fine and works under other distros. I would like to determine the problem and possibly PR patches to fix the package.
This would seem to me to be a very common scenario, particularly for package maintainers. Can someone walk me through the workflow for this?
A clumsy way that has occurred to me is perhaps to edit the derivation to forgo the fetchurl step and somehow use a local, untarred copy of the package. I think that (or something like it) should be possible but it feels hacky and I’d rather learn the conventional way of approaching this.
That rebuilds your system configuration using your copy of the repository, not something I’d do without really knowing what I’m doing. It does not switch though, I’d still be careful. Also it does not even require that the derivation you are fiddling with will get build at all, as your config might not need it.
Hmm, so I see. I was apparently working in the 20.09 branch (my system’s at 19.09). I didswitch and it did build the package in question. Well, easy enough recover from – yay NixOS!
Anyway, rebuilding my system was intentional. The thing I’m looking at is the jack2 client library. It’s used by a server (part of my system config) and by client apps. IOW, I need to wind up with a consistent environment that includes both of those things. I agree that your suggestion is a more conservative approach, but can I achieve this that way?
Well, I am able to rebuild my system, including the jack2 library. However, when I switch, it doesn’t seem to activate the new library build. I assume it’s because I’ve neglected to provide a new hash. I’m kind of stumped.
Are there any library maintainers out there that can set me straight?
The path of the output didn’t seem to be the same as the one in my env.
I didn’t see the behavior change I expected
However, both of those points are moot now, for reasons I’ll elaborate below.
I’ve been executing:
nixos-rebuild switch -p test -I nixpkgs=/home2/nixos/nixpkgs
followed by a reboot into the test profile.
Thanks for the VM suggestion – another thing to try.
I woke up this morning realizing that my thinking around this was flawed. The code I was changing was not the server code but the client library code. To see my change, I would also need to rebuild the client(s) I want to observe in my testing. And it may not be important that I build my entire system, but I may only need to build the client library and the app that links against it. So I may be back to trying nix build or nix-shell.
Does it make sense to build with nix-shell for the library followed by a nested nix-shell for the app?