snx-rs: 2.2.3 -> 2.9.0

[Shavyn]

This is only a version bump of the snx-rs package as the version in nixpkgs (2.2.3) didn't support a feature added later I needed.

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
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[nbraud]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 376344

[nbraud]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 376344

---

x86_64-linux

✅ 1 package built:

• snx-rs

[nbraud]

Seems good.

[nbraud]

@Shavyn This package is currently unmaintained (meta.maintainers == []) so it might not be kept up-to-date 😬
Since you are using it, would you volunteer for maintainership?

I'd also suggest setting up automatic updates so @r-ryantm will automatically generate PRs and notify the maintainer(s)

[Adda0]

Before merging, the commit history should be definitely cleaned up: squashing the commits, removing the merged from ... commits, ideally keeping only one commit, which can then have additional information in the commit long description part from the current commits, if you want.

[Adda0]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 376344

---

x86_64-linux

✅ 1 package built:

• snx-rs

Reviewed points

✅ 12 | ❔ 1 | 🔴 1

• Package name fits the guidelines.
• Package version fits the guidelines.
• The commit text fits the guidelines.
• Package maintainers are notified.
  • The continuous integration system will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
• meta field information fits the guidelines and contain the correct information:
  • License can change with version updates, so it should be checked to match the upstream license.
  • If the package has no maintainer, a maintainer must be set. This can be the update submitter or a community member that accepts to take maintainership of the package.
• The code contains no typos.
• The package builds locally on x86_64-linux.
• All executables run on x86_64-linux.
• All executables tested on x86_64-linux.
• All depending packages build.
• Patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed.
• Patches that are remotely available are fetched rather than vendored.

Possible improvements

Comments

The package builds and runs, but I cannot test the functionality of the package.

[Shavyn]

@nbraud thanks for the reply. I'll consider adding the automation and the possibility to maintain the package (my knowledge of Nix is next to zero).
@Adda0 thanks for your contribution. As you can guess I'm a newbie and this is all new to me. I'm learning how to clean up this mess.

[Adda0]

I looked at the upstream repo. They have a changelog file in there. We should add it to the meta attrset like this:

changelog = "https://github.com/ancwrd1/snx-rs/blob/v${version}/CHANGELOG.md";

Could you make the change while you are at it, too?

[Adda0]

@nbraud thanks for the reply. I'll consider adding the automation and the possibility to maintain the package (my knowledge of Nix is next to zero).

Since this project has regular releases on GitHub, adding an update script should be as easy as adding

passthru.updateScript = nix-update-script { };

[Shavyn]

Thanks for all the inputs, as soon as I come back from work I'll have everything (hopefully) sorted.

[nbraud]

Before merging, the commit history should be definitely cleaned up: squashing the commits, removing the merged from ... commits, ideally keeping only one commit

TBH, that can be accomplished just as well with a squash merge, so I don't see a strong incentive to make people squash the history themselves, especially given that it's then harder for others to see what changed since they last reviewed.

[Shavyn]

I managed to:

• add changelog to meta informations
• remove the test disabling
• (hopefully) squash commits

Sorry it took me so long. For that reason I'm hesitating volunteering to maintain the package. Let me train a little bit more :).

[Adda0]

TBH, that can be accomplished just as well with a squash merge, so I don't see a strong incentive to make people squash the history themselves, especially given that it's then harder for others to see what changed since they last reviewed.

True, but it has disadvantages that, IMO, heavily outweigh its usefulness:

1. This puts the responsibility to the committers to perform another check before merging and carefully think whether squashing the commits makes sense for each PR.
2. This prevents separate meaningful commits when it really makes sense: PRs with changes different from simple updates. Again, the committers must spend more time reviewing each PR.
3. One cannot separate the update to the maintainer list from the update to a package.

Personally, I prefer to make the job of committers as easy as possible, and put the responsibility of preparing the PR to an ideal state to each contributor.

The only real disadvantage I see here is, as you point out, that the diff for the previous reviewers gets mangled. But here we are usually not reviewing "program" code spanning multiple source files, but "only" one "configuration" file which would get modified anyway, so unless you review the specific new commits separately, you will see that the entire file has changed, anyway.

[Adda0]

I managed to:

* add changelog to meta informations

* remove the test disabling

* (hopefully) squash commits

Sorry it took me so long. For that reason I'm hesitating volunteering to maintain the package. Let me train a little bit more :).

Thanks. It looks great. In general, one should not merge the master branch into the feature branch (creating the merge commit), but instead rebase onto the master branch. This would result in a single commit built atop the newest commit on the master branch.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/packages-looking-for-a-maintainer/5442/9

[Adda0]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/packages-looking-for-a-maintainer/5442/9

I mentioned that the package is looking for a maintainer. Hopefully someone steps in.

[Shavyn]

The latest commit adds what @Adda0 suggested in his review, adds myself as maintainer (wish me good luck). I hope I used the git rebase command correctly instead of merging

Thanks everyone for your help.

[Adda0]

Other than the commit for maintainer list update, all seems well. I will do a final rebuild of all binaries soon and if all goes well, I am all for approving the PR. Thank you for the patience with our "demands" and good luck with the maintainership. Hopefully, all will work well with future versions of the package, and there will not be much additional work needed.

And yes, the rebase seems to went well. Great work!

[Adda0]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 376344

---

x86_64-linux

✅ 1 package built:

• snx-rs

Comments

All builds and runs, but I cannot test the functionality of the package. The maintainer information is valid. Looks good to me.

[Shavyn]

Removed the (unintentional) merge master commit. Sorry.