I mistakenly added extra whitespace in
https://github.com/NixOS/nixpkgs/pull/401872 which negatively affects
aesthetics of our documentation.
Thought it was part of nixfmt-rfc-styles output, but can't reproduce.
Might have had configured the wrong nixfmt.
It was easy to accidentally trigger infinite recursion if you depended
on `toplevel` in any way before. For instance, if you used
`CopyBlocks` with an image containing `toplevel`. This was because
`toplevel`'s assertion / warning logic has to be evaluated, but that
means evaluating `image.repart`'s assertions / warnings, which
requires evaluating the `repartConfig` attrsets to check for malformed
`Label`s. That causes the module system to type check *all*
`repartConfig` keys, even though most of them aren't used in the
assertions / warnings. So evaluating `system.build.image` evaluates
`repartConfig.CopyBlocks`, which evaluates `toplevel`, which evaluates
assertions / warnings, which evaluates `repartConfig.CopyBlocks` to
type check it. Infinite loop.
Even ignoring this recursion problem, it's still better for the repart
module to have its own assertions / warnings options. You don't have
to use `toplevel` in a repart image, so its assertions / warnings
would have been ignored in that case anyway. This way they're *always*
checked when you build an image.
The current workflow for starting the `linux-builder` on macOS is to run
`nix run nixpkgs#darwin.linux-builder`, which adds keys to the store and
then starts the builder.
Adding the keys requires user input (due to `sudo`) but the actual
builder should just stay running in the background somewhere.
I'd like to automate this process, but it's currently rather complex:
the first part of the script needs user input for `sudo`, and then
there's no signal when the process has finished starting up. The user
will need to see stdout/stderr during the first part, which makes it
challenging to capture it for the second part to determine when startup
has finished.
To fix this, I've split the `create-builder` script into an `add-keys`
script (interactive) and a `run-builder` script (background). These new
scripts are exposed in the `passthru` attributes for external users. The
`create-builder` script is now a simple call of `add-keys` and then
`run-builder`.
See: https://nixos.org/manual/nixpkgs/unstable/#sec-darwin-builder
lib/test.nix relies on `fileset.toSource` which creates a source dir
with the files of interest. `testers.shellcheck` passes all the files in
the source dir to shellcheck. The issue is related to relative path
sourcing, i.e. `source ./lib.sh` where shellcheck cannot make any
assumptions about the working directory.
Options were:
1) Disable this warning with a directive
Prior disabling in the tree:
- pkgs/tools/nix/info/info.sh
- nixos/modules/testing/test-instrumentation.nix
2) Set source-path to SCRIPTDIR with a directive
https://github.com/koalaman/shellcheck/wiki/Directive#source-path
Even though we don't enable external script following for shellcheck
with `-x` flag given every file in the source dir is passed, this
directive seems to capture the intent to help shellcheck a bit
better.
Went with option 2.
Services utilising postsrsd need to connect to it via a Unix socket.
While the path to that socket is static as of now, the discoverability
of that path suffers from the lack of module documentation and a
scattered definition of the individual path components over at least
three lines, even when reading the module source.
By exposing the socket path as a readOnly NixOS option, that value shows
up in the options overview and can be re-used in other parts of NixOS
config.
While we're not (fully) supporting the related features, yet, we already
prevent accidental storage of secrets in the store. This will also avoid
breaking changes in the future, when those features are properly
supported.
The options part of "services.headscale.settings" get rendered directly
into a JSON file. As such, any declared values need to match the actual
config key that upstream uses or they are ineffective.
One such key is "derp.auto_update_enable", which controls whether or not
auto-updates for the DERP map are enabled. This key is misspellt though:
the config is called "derp.auto_update_enabled", and that has always
been the case since the config has been introduced in 57f46ded (Split
derp into its own config struct, 2021-10-22). Any unknown key is simply
ignored by Headscale, and as such the setting is ineffective.
Fix this by renaming the option.
When using Merkuro in Plasma 6, the 'Contacts' widget will automatically
be added to the default panel. Unfortunately, it does not work unless
`kdePackages.kcontacts` is also present in the environment. This adds
the dependency if Plasma 6 is also enabled alongside Merkuro.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
