b92cad188c
git: warn on signing format default change
The default value for programs.git.signing.format changed in 25.05
from an implicit "openpgp" to null. Keep the existing gated
mkOptionDefault behavior so the signing block only materializes when
other signing settings are in use, but route the versioned value and
static docs text through the shared state-version helper.
Add a focused current-state-version test that covers a non-empty
signing configuration with no explicit format, alongside the existing
legacy implicit-openpgp and explicit-format tests.
evaluation warning: chandler profile: The option `programs.git.userName' defined in `/home/chandler/projects/machine-config/sam/configuration.nix' has been renamed to `programs.git.settings.user.name'.
evaluation warning: chandler profile: The option `programs.git.extraConfig' defined in `/home/chandler/projects/machine-config/sam/configuration.nix' has been renamed to `programs.git.settings'.
evaluation warning: chandler profile: The option `programs.ssh.addKeysToAgent' defined in `/home/chandler/projects/machine-config/sam/configuration.nix' has been renamed to `programs.ssh.matchBlocks.*.addKeysToAgent'.
25.11 and unstable are using spice-vdagent 0.23.0, which doesn't seem to
work for display resizing. (It's likely that it's just a config error,
but this appears to revert it for now. I'll probably try to report/fix
the bug upstream at some point now that I've identified it.)
For future reference, here's how I bisected the problem to this package:
I didn't want to have to deal with compiling the universe from source to
check each commit, so I started with the commits that nixos-unstable
once pointed to, which would have been built by Hydra and cached. I used
`npc` for this:
git clone git@github.com:samestep/npc
NPC_REV=main NIX_BIN=`which nix` GIT_BIN=`which git` cargo build --release
~/projects/npc/target/release/npc fetch # I wasn't able to find a way around this
~/projects/npc/target/release/npc bisect start nixos-unstable
~/projects/npc/target/release/npc bisect bad nixos-unstable # currently broken
~/projects/npc/target/release/npc bisect good f02fddb8acef29a8b32f10a335d44828d7825b78 # formerly working
`npc` will then print out commit hashes for me to try, which I can
check out and run:
git -C ~/projects/nixpkgs checkout b6a8526db03f735b89dd5ff348f53f752e7ddc8e
sudo nixos-rebuild -I nixpkgs="/home/chandler/projects/nixpkgs" boot && reboot
~/projects/npc/target/release/npc bisect <good|bad> $(git -C ~/projects/nixpkgs rev-parse HEAD)
This process repeats until it identifies a good and bad commit:
$ ~/projects/npc/target/release/npc bisect good $(git -C ~/projects/nixpkgs rev-parse HEAD)
done bisecting nixos-unstable
8913c168d1c56dc49a7718685968f38752171c3b is the first bad commit
7df7ff7d8e00218376575f0acdcc5d66741351ee is the last good commit
Now, there's still a pretty big gap here, so I'll want to do some
further bisection!
[chandler@sam:~/projects/nixpkgs]$ git rev-list --count 7df7ff7d..8913c168
3099
[chandler@sam:~/projects/nixpkgs]$ git diff --shortstat 7df7ff7d..8913c168
3716 files changed, 45544 insertions(+), 38260 deletions(-)
Now I can do a regular `git bisect`:
$ git -C ~/projects/nixpkgs bisect start
$ git -C ~/projects/nixpkgs bisect good 7df7ff7d8e00218376575f0acdcc5d66741351ee
$ git -C ~/projects/nixpkgs bisect bad 8913c168d1c56dc49a7718685968f38752171c3b
$ # …
$ git -C ~/projects/nixpkgs bisect bad
1491cf86eb405b21e518f1a94763524de36ee661 is the first bad commit
commit 1491cf86eb405b21e518f1a94763524de36ee661 (HEAD)
Author: R. RyanTM <ryantm-bot@ryantm.com>
Date: Tue Sep 23 12:31:00 2025 +0000
spice-vdagent: 0.22.1 -> 0.23.0
pkgs/by-name/sp/spice-vdagent/package.nix | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
For this, I removed basically all packages, so I wouldn't have to
rebuild e.g. chromium from source! I did end up rebuilding the kernel
once, which took a while; most of the bisect steps didn't actually make
any changes so the whole process was pretty fast.
This isn't a new issue; not even to me!
https://news.ycombinator.com/item?id=38946967
> chandlerswift on Jan 11, 2024 | on: Conditional Git Configuration
>
> I'd attempted to configure this some time back, but never gotten it
> working, and this was the kick in the pants I needed to finally get
> it working!
>
> In case anyone is stuck in the same way that I was, the trailing
> slash at the end (which I had previously omitted, not realizing) is
> necessary for this to work. The docs[0] mention this, but I'd managed
> to repeatedly miss it:
>
> > If the pattern ends with /, * will be automatically added. For
> > example, the pattern foo/ becomes foo/*. In other words, it matches
> > "foo" and everything inside, recursively.
>
> [0]: https://git-scm.com/docs/git-config#Documentation/git-config...
:doh: