linux_xanmod, linux_xanmod_latest: 2025-02-19

[eljamm]

https://dl.xanmod.org/changelog/6.12/ChangeLog-6.12.14-xanmod1.gz
https://dl.xanmod.org/changelog/6.12/ChangeLog-6.12.15-xanmod1.gz

Will start testing tomorrow.

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.

[eljamm]

This update seems fine from my tests. There is a new release out, but I'm leaning more towards merging this first and testing that later.

That said, I've also been thinking that there doesn't seem to be any major issues with updating xanmod, so why don't we merge releases first and then test as we go? This will allow us to keep up with upstream better and reduce security risks from having outdated kernels. Other kernels in nixpkgs seem to follow a similar pattern: "If it builds, it's good to merge".