freebsd: various new packages to support a NixBSD system

[rhelmot]

Description of changes

61 of them,1 small package diff, 1 large package diff (sys), and 1 commit modifying lib and mkDerivation. This lets us boot NixBSD!

There are a few TODOs left in the code but I think they're fine for followup PRs.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
  • x86_64-freebsd (cross from linux)
• 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/)
• 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.

[AndersonTorres]

This is too long. Can it be at least documented?

[Ericson2314]

It does need documentation, but do note it is just being moved. I would be OK with that happening in a later PR.

[rhelmot]

I added an overview.

[AndersonTorres]

This is ambiguous.

What does it mean?
a) does not require modification
b) prohibits any modification

[rhelmot]

I took a look at the actual license file and it seems that it's the latter. I updated the verbage to be more explicit.

[Ericson2314]

Maybe this wrapping stuff should be left for later? Not really sure what it is yet.

[rhelmot]

What's wrong with it? we are in fact doing suid binary wrappers on nixbsd and they work fine. Would you rather it default to off? What's the practical use of running a non-suid login binary?

[Ericson2314]

I just meant that /run/wrappers isn't a Nixpkgs thing, so it's arguably a minor layer violation I think?

[rhelmot]

I changed the parameter to be the wrappedLogin path itself, null if unused, as we discussed on matrix. You should go complain to the other package maintainers for their packages that hardcode wrapper paths!

[Ericson2314]

What's this?

[rhelmot]

looks like it's removing a suid bit

[Ericson2314]

👀

[Ericson2314]

I went through each commit, but I don't wanna nit-pick this to death :)

[JohnRTitor]

Let's not hold this any further, subsequent improvements and bugfixes can come in a later PRs.

[trofi]

freebsd.drm-kmod.patches fails to evaluate with non-existent path:

$ nix-instantiate -A freebsd.drm-kmod.patches --argstr system x86_64-linux
error:
       … while calling the 'concatMap' builtin
         at pkgs/os-specific/bsd/freebsd/lib/default.nix:82:5:
           81|     in
           82|     lib.lists.concatMap splitPatch consolidated;
             |     ^
           83| }

       … while calling the 'map' builtin
         at pkgs/os-specific/bsd/freebsd/lib/default.nix:78:28:
           77|           derive = patchLines: writeText "freebsd-patch" (lib.concatLines patchLines);
           78|           derivedPatches = builtins.map derive filteredLines;
             |                            ^
           79|         in

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: attribute 'path' missing
       at pkgs/os-specific/bsd/freebsd/pkgs/mkDerivation.nix:110:75:
          109|         (lib.optionals (attrs.autoPickPatches or true) (
          110|           freebsd-lib.filterPatches patches (attrs.extraPaths or [ ] ++ [ attrs.path ])
             |                                                                           ^
          111|         ))

Note it's a "syntax" error to try to dereference invalid attribute. Is it possible to have a check to return an exception here? (Inless it's a genuine bug)