Use this and never find yourself again hitting fn because of muscle
memory! (you can even physically swap the keycaps, at least on M series)
Keycodes have been pulled from https://hidutil-generator.netlify.app/
and the hex value has been converted to a base 10 int.
As `/run` gets recreated every reboot and we can't specify dependencies
for launchd, creating the `workDir` every reboot will require extra
complexity with a separate daemon that runs as `root` otherwise it won't
have sufficient privileges.
As we clean the `workDir` when the service first starts anyway, it ends
up being the same.
- Added the jankyborders service.
- Introduced changes for whitelist and blacklist options and assertions.
- emoved path reference from launchd argument.
- Corrected missing trailing newline in default.nix.
Before this commit, aarch64 users building the following configuration
would end up with an aarch64-linux builder, while after it, they get the
x86_64-linux builder they expect:
```nix
nix.linux-builder = {
enable = true;
package = pkgs.darwin.linux-builder-x86_64;
};
```
Before, in order to get an x86_64-linux builder, they would have needed
to use this configuration instead:
```nix
nix.linux-builder = {
enable = true;
config.nixpkgs.hostPlatform = "x86_64-linux";
systems = ["x86_64-linux"];
};
```
The reason for this is that the linux-builder module calls `override` on
the package option, and the `linux-builder-x86_64` package is also
defined using override:
```nix
linux-builder-x86_64 = linux-builder.override {
modules = [ { nixpkgs.hostPlatform = "x86_64-linux"; } ];
};
```
The module was effectively discarding the `nixpkgs.hostPlatform` option.
Example issue: https://github.com/NixOS/nixpkgs/issues/313784
This is a huge anti‐declarative footgun; `copy` files cannot
distinguish if a previous version is managed by nix-darwin, so they
can’t check the hash, so they’re prone to destroying data, and
copied files are not deleted when they’re removed from the system
configuration, which led to a security bug. Nothing else in‐tree
was using this functionality, so let’s make sure it doesn’t
cause any more bugs.
As explained in the changelog and activation check, the previous
implementation had a nasty security bug that made removing a user’s
authorized keys effectively a no‐op.
As far as I can tell, this isn't required to get fonts to work on
NixOS, so we shouldn't require it on nix-darwin either, even if the
implementations are superficially similar.
Stricter launchd -> StartCalendarInterval type:
- Verify that the integers passed to `Minute`, `Hour`, etc. are within
range.
- When provided, the value for StartCalendarInterval must be a non-empty
list of calendar intervals and must not contain duplicates entries
(throw an error otherwise).
- For increased flexibility and backwards-compatibility, allow an
attrset to be passed as well (which will be type-checked and is
functionally equivalent to passing a singleton list). Allowing an
attrset or list is precisely in-line with what `launchd.plist(5)`
accepts for StartCalendarInterval.
Migrate `nix.gc.interval` and `nix.optimise.interval` over to use this
new type, and update their defaults to run weekly instead of daily.
Create `modules/launchd/types.nix` file for easier/modular use of
launchd types needed in multiple files.
Documentation:
- Update and improve wording/documentation of launchd's
`StartCalendarInterval`.
- Improve wording/documentation of `nix.gc.interval` and
`nix.optimise.interval` ("time interval" can be misleading as it's
actually a "calendar interval"; e.g. `{ Hour = 3; Minute = 15;}`
runs daily, not every 3.25 hours).
Previously, it was not possible to inject PATH entries between profiles
and the “default system” PATH entries. This confounds adding, e.g.
Homebrew on aarch64’s non-standard prefix as higher priority than the
builtin system paths, but lower than Nix profiles.
This is a backwards-incompatible change for some users, but should only
be so in the case a user used `mkOrder` with a value between 1000 (the
default priority) and 1200. Value of 1200 chosen as the same delta from
the default as just below in `environment.profiles` (which uses 800),
and mkAfter is 1500 so will still go after this.
One of cachix-agent's dependencies, `hs-certificate`, makes calls to
`security`. This lives in `/usr/bin`, which isn't available from
launchd. This commit makes the system paths available to cachix-agent.
Fixes#924.
Complex container values like `-array` have their own DSL which does not
allow specifying all data types. Instead of using the DSL use plist
fragments instead.
This commit updates the nix.conf validation logic to accommodate
different versions of Nix. It introduces a conditional assignment
of the `showCommand` variable, which determines the appropriate
command to use based on the Nix version. For versions at least
"2.20pre", it uses "config show"; otherwise, it falls back to
"show-config". This change ensures compatibility across various
Nix releases.
While #859 added basic support for configuring GitHub runners through
nix-darwin, it did not yet support all of the options the NixOS module
offers.
I am aware that this is a rather big overhaul. I think, however, that
it's worth it:
- Copies the `options.nix` from the [NixOS module] with only minor
adaptations. This should help to keep track of any changes to it.
- Respect the `workDir` config option. So far, the implementation didn't
even read the value of the option.
- Allow configuring a custom user and group.
If both are `null`, nix-darwin manages the `_github-runner` user
shared among all instances. Take care of creating your own users if
that's not what you want.
- Also creates the necessary directories for state, logs and the working
directory (unless `workDir != null`). It uses the following locations:
* state: `/var/lib/github-runners/${name}`
* logs: `/var/log/github-runners/${name}`
* work: The value of `workDir` or `/var/run/github-runners/${name}`
if (`workDir == null`).
We have to create the logs directory before starting the service since
launchd expects that the `Standard{Error,Out}Path` exist. We do this
by prepending to [`system.activationScripts.launchd.text`].
All directories belong to the configured `user` and `group`.
- Warn if a `tokenFile` points to the Nix store.
[NixOS module]: https://github.com/NixOS/nixpkgs/blob/3c30c56/nixos/modules/services/continuous-integration/github-runner/options.nix
[`system.activationScripts.launchd.text`]: https://github.com/LnL7/nix-darwin/blob/bbde06b/modules/system/launchd.nix#L99-L123
This commit adds a protocol option for the `linux-builder` and defaults
it to `ssh-ng`. I have observed it needing this with the following:
``` sh
$ nix store ping --store ssh://linux-builder
Store URL: ssh://linux-builder
$ nix store ping --store ssh-ng://linux-builder
Store URL: ssh-ng://linux-builder
Version: 2.18.1
Trusted: 0
```
This seems to make the difference on whether or not Nix picks up
`linux-builder` as an available builder.
enableScriptingAddition no longer triggers IFD
by using runCommand to generate sudoers.d/yabai,
instead of builtins.hashFile and interpolating the string in nix.
Adds a new module which allows to configure multiple GitHub self-hosted
runners on Darwin. The module is heavily inspired by the nixpkgs NixOS
module. Its implementation differs in some ways:
- There's currently no way to configure the user/group which runs the
runner. All configured runners share the same user and group.
- No automatic cleanup.
- No advanced sandboxing apart from user/group isolation
Properly detect the binary name (not just /nix/store/...-bash, but include the
.../bin/bash), and use the symlinked name which also appears in /etc/shells.
```
error: A definition for option `launchd.user.agents.[...].serviceConfig.StartCalendarInterval' is not of type `null or (list of (submodule))'. Definition values:
- In `<unknown-file>':
{
Hour = 0;
Minute = 0;
}
```
Use `PGDATA` environment variable instead of `-D` to maintain
consistency with NixOS module.
Co-Authored-By: Michael Hoang <enzime@users.noreply.github.com>
This option should probably be dropped but I'd prefer to batch that
with using Babelfish by default (or unconditionally, as Home Manager
does) so as to avoid multiple independent breaking changes.
Fixes: #632
`mkEnableOption` wraps its argument in a complete sentence with a
terminating full stop; an additional newline will add an incorrect
space before the end of the sentence in the rendered documentation,
and any additional verbiage that doesn't fit into the form "Whether to
enable [...]." is also incorrect. In the latter case, the description
can be overridden manually.
These are the equivalents of the
NixOS options with the same name, introduced in
d3ac0938a7.
Allows running extra commands while building the system configuration
output, for example to add extra files into the output directory,
and passing arguments to the system builder's mkDerivation.
This adds a small module for configuring the trezor-bridge service,
trezord. This service enables users to interact with their Trezor
hardware wallet through the trezor suite web interface, or to use the
device for U2F auth, SSH login, GPG or password mgmt.
https://trezor.io/learn/a/what-is-trezor-bridge
The options were copied directly from the nixos service module here:
9d6e454b85/nixos/modules/services/hardware/trezord.nix (L16)
The implementation was adapted from the nixos module's systemd service
to a launchd user agent.
Tested successfully locally on an Air M2.
This is a big change that disentangles a lot of mistaken assumptions
about mixing multiple versions of Nixpkgs, treating external flake
inputs as gospel for the source of Nixpkgs and nix-darwin, etc.;
the end result should be much simpler conceptually, but it will be a
breaking change for anyone using `eval-config.nix` directly. Hopefully
that shouldn't be a big issue, as it is more of an internal API and
it's quite likely that existing uses may have been broken in the same
way the internal ones were.
It was previously easy to get into a state where your `lib` comes
from nix-darwin's `nixpkgs` input or a global channel and your
`pkgs` comes from another major version of Nixpkgs. This is pretty
fundamentally broken due to the coupling of `pkgs` to its corresponding
`lib`, but the brokenness was hidden much of the time until something
surfaced it. Now there is exactly one mandatory `lib` input to system
evaluation, and the handling of various additional options like `pkgs`
and `system` can be done modularly; maintaining backwards compatibility
with the previous calling convention is punted to the `default.nix`
and `lib.darwinSystem` entry points. `inputs` is no longer read by
nix-darwin or special in any way, merely a convention for user code,
and the argument is retained in the entry points only for backwards
compatibility.
All correct invocations of the entry points should keep working
after this change, and some previously-broken ones should be fixed
too. The documentation and template have been adjusted to show the
newly-recommended modular way of specifying various things, but no
deprecation warnings have been introduced yet by this change.
There is one potential, mostly cosmetic regression:
`system.nixpkgsRevision` and related options are less likely to be
set than before, in cases where it is not possible to determine the
origin of the package set. Setting `nixpkgs.source` explicitly will
make this work again, and I hope to look into sending changes upstream
to Nixpkgs to make `lib.trivial.revisionWithDefault` behave properly
under flakes, which would fix this regression and potentially allow
reducing some of the complexity.
Fixes: #669
We trust the version information from `nixpkgs.source` when `pkgs` was
constructed by the `nixpkgs` module or `nixpkgs.source` was explicitly
set by the configuration. Otherwise, we rely on Nixpkgs to report its
own version, which handles the same cases as the old logic and opens
the door to Nixpkgs automatically reporting the correct revision when
using flakes.
This is based on the current NixOS `nixpkgs` module, adjusted for the
nix-darwin context and without adding the options due for deprecation
in NixOS.
This gives us the ability to set the package set modularly through
`nixpkgs.pkgs` and builds up infrastructure for handling user-specified
Nixpkgs instantiations more robustly.
The cross-compilation options are currently not very useful due to
even Darwin->Darwin cross-compilation not being wholly functional
yet, but it looks feasible to build an `aarch64-darwin` system from
`x86_64-darwin` with some patching and it should be possible to make
cross-compilation more widely supported after the Darwin SDK situation
in Nixpkgs improves.
One casualty is the error for setting `nixpkgs.*` options when
overriding the package set. That could be ported over to this new
scheme, but it'd increase divergence with the NixOS module and reduce
cross-compatibility of configurations, so I lean towards adding it
upstream to NixOS if anything. (But if people want to keep it I can add
it back.)
This should be less brittle than the version-based check, although
arguably this kind of `lib.version` mismatch should break as early
as possible...
Fixes: #718
