How to test and apply custom changes in nixos locally?

I changed nixos/modules/security/pam.nix in my local repo with a fix from a PR that is not approved yet. Now I would like to test the changes and apply them locally. Could you please advise how to do that?

2 Likes

You could export NIX_PATH=nixpkgs=/path/to/your/checkout and then run a nixos-rebuild

Thank you very much!
I was wondering how are security or other fixes done after a release. Do users wait for the next release or there is some other mechanism?

Security patches and fixes for broken packages can (and should) be applied during the entire lifetime of the stable release. They’ll typically be applied to master when applicable before being backported to the stable branch. So if the PR you’re testing addresses a security issue present in 20.09, we’ll want to make sure that gets backported.

How is the backport to the stable branch done? For example we have now release and a tag 20.09. If there were a security issue would it go to 20.09.1 or to 20.10?

Backports go to release-${version} as described in the contribution guide

It appears to me that if the backports are done without increasing the version then the tag is not something we can rely on. So if someone tells you I’m on 20.09 we wouldn’t know if s/he is on the original 20.09 or a certain number of commits later. Or I’m wrong?

The tag only marks the branching off. The channel is defined by the release specific branch.

I’m not sure I understand. Channels are another concept. I’m talking about git. What I’m saying is that if one developer tells another developer that he is using 20.09 then the other one wouldn’t know what 20.09 is.

each release has its own branch, you can cherry-pick patches to these release-specific branches. Once the CI/hydra checks the tests work fine, channels advance for that release. ISOs are updated accordingly so depending on when you download your 20.09 ISO, they may be different and will include security patches as they get added.

You wouldn’t know in Ubuntu or RHEL either… I’m using Ubuntu 20.04 doesn’t tell you anything but that the system I use, probably uses software that is probably compatible with the same software as it was at release day of Ubuntu 20.04.

Though with NixOS we have to possibility to do a nix-info and get the exact commit the current systems configuration was built from.

Oh, I’m not saying NIX is inferior. I wouldn’t be here if that were the case :slight_smile:
Perhaps, we can do even better. Anyway, thanks a lot for all your comments.

Well, of course you can build your system in a way that you can say “I’m on commit 78dc359abf8217da2499a6da0fcf624b139d7ac3”, but usually “I’m on unstable” is good enough for everyone to give tipps about how to configure stuff or help solving issues with some Firefox issues because of empty profiles…

To be honest, my configuration even is done by specifying the 20.09 branch, and just run niv update occassionally to get to the most recent commit on the branch.

There is not a single channel anymore that was managed by nix-channel on my system. It is all managed by home-manager and system configuration flake.

nix/OS uses the git tooling so you can do powerful things…

git diff

will show you the difference between two commits, and in the nix context the difference in the two systems (build wise).

gitk can make this look a little nicer… or any other of the many git GUI tools.

I was about to do the test in my system by changing the enivornment variable but I’ve decided first to see what’s going on.

git clone git@github.com:NixOS/nixpkgs.git
git checkout 20.09
rm *
cp -r /nix/var/nix/profiles/per-user/root/channels/nixos/* .
git status|wc -l

I get 463 lines of output from the above command, namely from modified or removed files. Shouldn’t they be close to zero? I haven’t noticed any change with this even after I upgraded my system.

Answering myself here.

Setting nixpkgs part of NIX_PATH to a local checkout must be done together with setting git to a particular point in the commit history. Otherwise one will get a nix system that is in a unwanted state after switching to it. To a newcommer like me it wasn’t obvious what that point should be. Naturally since I was using 20.09 I did git checkout 20.09 but that resulted in lots of differences between it and my local state. Luckily, I found out that nixos-version returns information that contains the exact git point that corresponds to the local nix state. For example:

$ nixos-version
20.09.2497.4a75ca4a4e7 (Nightingale)

To set the correct point one should do:

git checkout 4a75ca4a4e7

and only then implement or rebase the required changes.

Setting the approprate value within the NIX_PATH is also not trivial and new users can use some help.

nix.nixPath = [
“nixpkgs=…”
“nixos-config=/etc/nixos/configuration.nix”
“/nix/var/nix/profiles/per-user/root/channels”
];

What is also important is the mechanism changes are backported to a release. A release is created by creating a tag at certain point in time. All changes are implemented on its top. So for example to see the list of changes since a 20.09 one can do:

git shortlog --no-merges HEAD --not 20.09

as long as the HEAD is the current point set earlier.

In order to implement changes of the current release it would be more practical to use a branch and not a certain commit. The appropriate branch for the current release is called nixos-<version> which in the current case is nixos-20.09. This way you can benefit from all fixes in the current release and be on a stable branch.

Finally to a comment like this:

my answer would have been that to eliminate the ambiguity they can specify not only the relelase but also the point in time their system is by stating the outcome of the nixos-version command.

None of these were obvious to me and I didn’t understand the comments to my questions and I hope that if someone gets here this comment will make the thing clearer.

1 Like