nvd: 0.2.3 -> 0.2.4, switch source repository to Sourcehut

[khumba]

Description of changes

A new version of nvd is out, with some new features (a history command, sorting, and an added splash of colour). Additionally, nvd will be moving from Gitlab to Sourcehut shortly, so this PR updates the repository URL. The old repository will be archived and removed in the somewhat near future.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • nixpkgs-review tried to do some weird merge and bailed. I manually built the only reverse dep, nh, but didn't test it's functionality.
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[iFreilicht]

Tested on aarch64_darwin with nix-shell -p nixpkgs-review --run "nixpkgs-review pr 345403". All new features work as intended, dependency nh builds fine as well (though the part of nh that uses nvd is not useful on macOS).

[JohnRTitor]

Source change and update should be done in separate commits

[drupol]

@JohnRTitor I'm genuinely curious to know if that specific rule is enforced or written somewhere in a file?

Context: #343734

[JohnRTitor]

if that specific rule is enforced or written somewhere in a file

Yes, specifically in contributing.md. ¹

• Create a commit for each logical unit.
• [...]

Then we could use git cherry-pick -x to backport just the source update commit for #345406 ²

These are not entirely enforced and mandatory persay, but it's a good practice.

Footnotes

1. https://github.com/NixOS/nixpkgs/blob/b5308e754789375535fad708ea7ab644bbc1c84c/CONTRIBUTING.md#commit-conventions ↩

2. https://github.com/NixOS/nixpkgs/blob/b5308e754789375535fad708ea7ab644bbc1c84c/CONTRIBUTING.md#manually-backporting-changes ↩

[drupol]

You're right and the links are relevant, thanks.

But I'm also starting to believe that we shouldn't block PRs for such details, especially when the CI is green, just like this is the case here.

I think we should emit a warning to the PR author asking to split the commit next time, but I don't think we should block it.

So, if you're OK with it, would it be OK to merge this PR as-is?

[JohnRTitor]

if you're OK with it, would it be OK to merge this PR as-is?

Yes, again these are just for the sake of consistency and style. PRs should not be blocked, especially if it's just a minor change like this. We have 6k+ PRs sitting already.

I also believe that as commiters we can make the necessary changes ourselves in case of a minor PR like this.

[khumba]

Thank you! And sorry, I wasn't aware of that rule, I'll do that next time. (I thought I saw the hash changing just from the source switch, that's partly why I did a single commit, but that was because rev = "refs/tags/..." produces a different directory structure with Sourcehut.)