Consider a user wanting to set up the Linux builder for the first time,
but with a slightly more generous allocation of resources compared to
the default. They'll do something like this:
```
{
virtualisation.cores = 3;
virtualisation.darwin-builder = {
diskSize = 40 * 1024;
memorySize = 4 * 1024;
};
}
```
This will fail with an error like this:
```
error: a 'aarch64-linux' with features {} is required to build '/nix/store/3acpgmwqwnk8g2gc5r05ar2lvmn01b8a-builder.pl.drv', but I am a 'aarch64-darwin' with features {apple-virt, benchmark, big-parallel, nixos-test}
```
But why would they have to rebuild the NixOS system?! All they did was
change the arguments passed to QEMU, and nothing those options control
would affect the NixOS configuration itself... right?
`config.system.build.toplevel` is defined with `allowSubstitutes` set to
`false` by default, which makes it so that the toplevel can't be
substituted if Nix is trying to use it "directly." So because the above
example would have to rebuild the VM runner, which references toplevel
directly, Nix refuses to substitute it, unless `always-allow-substitutes
= true` is set as a Nix option. (In the case where the QEMU options
aren't changed at all, Nix just substitutes the runner, which sidesteps
this issue as the runner itself doesn't use toplevel as an input.)
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
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
NixOS documentation seems to come at the cost of another Perl dependency, and is currently not disabled-by-default in the `perlless` profile.
Consider this dependency path before the change:
```
$ nix why-depends .#some-image /nix/store/3vq9qasxlqpyq1k95nq3s13g2m6w59ay-perl-5.40.0
/nix/store/gn02dmslv3vihbwgfajws1g3ic9fj1m0-microvm-image-1-rc1
└───/nix/store/pmwncx8ja7h65zr0z9kvjncdxkymvd82-system-path
└───/nix/store/mahxsvm46200qb879bxpdvpmamzss21c-nixos-help
└───/nix/store/0ni8bklq7ykmbnidys169z1s9cagkm66-nixos-help
└───/nix/store/ybl3snmpzjhna4vh8rs4zfrrky0q7xd4-w3m-0.5.3+git20230121
└───/nix/store/3vq9qasxlqpyq1k95nq3s13g2m6w59ay-perl-5.40.0
```
After the change:
```
$ nix why-depends .#some-image /nix/store/3vq9qasxlqpyq1k95nq3s13g2m6w59ay-perl-5.40.0
'git+file:///some/path#some-image' does not depend on '/nix/store/3vq9qasxlqpyq1k95nq3s13g2m6w59ay-perl-5.40.0'
```
This allows users to simply enable support for all hardware by enabling the option `hardware.enableAllHardware`, instead of having to import `modules/profiles/all-hardware.nix`.
This is better, as the enableAllHardware option will be discoverable via search.nixos.org, while the `all-hardware.nix` is hidden inside nixpkgs and hard to discover.
Backward compatibility is provided by replacing the old `profiles/all-hardware.nix` with a file that sets the `enableAllHardware` option to true.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
This is no longer referenced anywhere and so will inevitably bitrot,
and doesn’t do anything that isn’t simple to achieve with the
module documentation.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
Adding custom plugins causes the `vim` command to be a wrapper script
running `vim -u ...`, which makes it not load the default ~/.vimrc.
(This is analogous to #177375 about neovim.)
As of Vim 9, the syntax-highlighting portion of the nix plugin is
upstream; the full plugin is only needed for indentation etc. (see also
e261eb152b). So, using regular pkgs.vim
works around this behavior/bug and causes any ~/.vimrc to get loaded,
without regressing the syntax highlighting support that motivated the
change being reverted here.
This reverts commit 0b5a0cbc69.
noXLibs is an advanced option for advanced users which know how to recognize and debug build failures which might be caused by the added overlays.
The minimal profile should be minimal but also save to use for many people and not cause build failures in packages it really shouldn't.
ReiserFS has not been actively maintained for many years. It has been
marked as obsolete since Linux 6.6, and is scheduled for removal
in 2025. A warning is logged informing users of this every time a
ReiserFS file system is mounted. It suffers from unfixable issues
like the year 2038 problem.
JFS is a slightly more ambiguous case. It also has not been actively
maintained for years; even in 2008 questions were being raised
about its maintenance state and IBM’s commitment to it, and some
enterprise distributions were opting not to ship support for it as
a result. It will [indefinitely postpone journal writes], leading
to data loss over potentially arbitrary amounts of time. Kernel
developers [considered marking it as deprecated] last year, but
no concrete decision was made. There have been [occasional fixes]
to the code since then, but even the developer of much of those was
not opposed to deprecating it.
[considered marking it as deprecated]: https://lore.kernel.org/lkml/Y8DvK281ii6yPRcW@infradead.org/
[indefinitely postpone journal writes]: https://www.usenix.org/legacy/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf
[occasional fixes]: https://www.phoronix.com/news/JFS-Linux-6.7-Improvements
Regardless of whether JFS should be removed from the kernel, with all
the implications for existing installations that entails, I think
it’s safe to say that no new Linux installation should be using
either of these file systems, and that it’s a waste of space and
potential footgun to be shipping support for them on our standard
installation media. We’re lagging behind other distributions on
this decision; neither is supported by Fedora’s installation media.
(It also just so happens that `jfsutils` is the one remaining package
in the minimal installer ISO that has reproducibility issues, due to
some cursed toolchain bug, but I’m not trying to Goodhart’s law
this or anything. I just think we shouldn’t be shipping it anyway.)
- as the comment above already indicates
- neither OpenSSH nor PermitRootLogin are really required for a working
installation device, hence making it easier to change
Untrimmed mbrola-voices is leaking into the installer images again.
Instead of trying to manually squash every path it could possibly
leak through, use a very big hammer.
