See the discussion starting here:
https://github.com/NixOS/nixpkgs/pull/206951#issuecomment-1364760917
The `darwin.builder` derivation had a gratuitous dependency
on the current Nixpkgs revision due to
`config.system.nixos.revision`. Setting the revision explicitly
to null fixes this problem and prevents the derivation from being
rebuilt on every change to Nixpkgs.
This adds a new ``parallelShutdown`` option that allows users to control
how many guests can be shut down concurrently. Allowing multiple virtual
machines to be shut down at the same time reduces the amount of time it
takes to reboot the host.
Upstream documentation: https://www.libvirt.org/manpages/libvirt-guests.html#files
When the option list is empty, the fstab generator does not
automatically add "defaults" and generates a non-working fstab (since it
just emits two spaces around where the options would have been which is
only technically one fstab separator).
The `freeformType` of `settings.publicinbox` in this module prevented
users from setting settings on the `publicinbox` section itself (which
is necessary for making e.g. IMAP work correctly), and only allowed
configuration of nested per-inbox sections.
In general I believe that these overly specific types which are
traditional in NixOS, and this kind of config generation, are a huge
footgun. This commit is the least invasive change that makes the
module work correctly.
This brings back the ability to e.g. configure sane-airscan with
`environment.etc."sane.d/airscan.conf".text = ...`.
(AFAICT, sane-airscan loads all config files it finds, so it'll first
load the one from the nixos hardware.sane.* configuration, then the user
specified one in /etc/sane.d/airscan.conf.)
Fixes: 4fbec87a5b ("nixos/sane: point env vars to /etc for quick reload")
Fixes https://github.com/NixOS/nixpkgs/issues/207262
- Extensive documentation in NixOS manual
- Deterministic mode that fixes various identifiers relative to disk
partitions and filesystems in ext4 case
- UEFI variable recording
When test-input-reader runs, it's standard input exists and will
be buffered, so by the time the file exists, the standard input
can already be written to.
I have no reason to believe that a terminal emulator would start
accepting input _after_ launching the command.
I've tested this for hours in a loop without a single failure or
timeout.
