nixos/limine: Fix reading generations for primary profile and specialisations

[boomshroom]

Previously, all generations for the primary system profile read their data from the currently active one rather than their own path, and specialisations in general all used their parent bootspec rather than their own. This fixes both issues.

This commit still uses the parent path's build date for specialisations, but this is more minor issue and the times shouldn't be meaningfully different in most cases anyways.

Things done

• Read system generations from system-{gen}-link rather than system
• Read boot-spec for specialisations from the specialisation entry of the parent boot-spec

• 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.

[phip1611]

LGTM, but I can't test it.

PS: nit: It is good style to trim commit messages to a width of 72 characters

[programmerlexi]

I will look over this later.

[lzcunt]

I agree with phip1611, follow the 50/72 rule in your commit message. First line should be 50 characters or shorter (important but exceeding by a few characters is not a big deal), the rest should fit in 72 columns (I find myself doing 80 columns sometimes but the important bit is that it should be hard-wrapped).

This isn't part of the official nixpkgs commit style guide but IMO should be, the actual number of columns doesn't really matter but everything should be hard-wrapped in the commit message and the first line should ideally be short enough to not make GitHub cut it off.

This was discussed on Matrix, this isn't a big problem.

[phip1611]

This was discussed on Matrix, this isn't a big problem.

Context? In a public Matrix instance?

[lzcunt]

This was discussed on Matrix, this isn't a big problem.

Context? In a public Matrix instance?

In #dev:nixos.org. I've asked people's opinions about the 50/72 rule, where the general consensus seems to be that it's unenforceable without a lint and would be a trivial nitpick spammed in reviews. In hindsight, I agree with this. Your comment still applies, the commit message should probably be hard-wrapped. My comment about the 50/72 rule is unenforceable and could not be adopted in nixpkgs so I won't be nitpicking over it.

TL;DR: my comment doesn't apply and this discussion doesn't involve your comment, so no worries. I'd suggest the commit summary (first line) be untouched (it probably couldn't be made shorter) but the rest (the commit body) wrapped at whereever @boomshroom wants (just don't make single line paragraphs and it's good). Nitpicky stylistic choices about commit messages usually shouldn't block the PR.

[lzcunt]

Tested, works

[programmerlexi]

LGTM