we use stdenv.hostPlatform.uname.processor, which I believe is just like
`uname -p`.
Example values:
```
(import <nixpkgs> { system = "x86_64-linux"; }).stdenv.hostPlatform.uname.processor
"x86_64"
(import <nixpkgs> { system = "aarch64-linux"; }).stdenv.hostPlatform.uname.processor
aarch64
(import <nixpkgs> { system = "armv7l-linux"; }).stdenv.hostPlatform.uname.processor
"armv7l"
```
Instead of making the configuration less portable by hard coding the number of
jobs equal to the cores we can also let nix set the same number at runtime.
The volumeID will now be in the format of:
nixos-$EDITON-$RELEASE-$ARCH
an example for the minimal image would look like:
nixos-minimal-20.09-x86-64-linux
Note we're not using wayland default in the graphical media because it
could cause headaches for Nvidia users. But the session is still available
if someone logs out.
In 0945178b3c we decided that Perl-based
VM tests should be deprecated and will be removed between 20.03 and
20.09. So let's switch `nixos-build-vms(8)` to python as well (which is
entirely interactive, so other scripts won't break).
In my experience, the test-driver isn't used most of the time, so this
patch is mainly supposed to get rid of the (probably misleading)
deprecation warning when running `nixos-build-vms`. Apart from that, the
interface for python's test-driver is way nicer.
In some cases, /dev/stderr may not point to a sensible location. For
example, running nixos-enter inside a systemd unit where the unit's
StandardOutput and StandardError are set to be sockets. In these
cases, this line would fail.
Piping to fd2 directly works just as well, even under strange and
twisted executions.
Co-authored-by: Michael Bishop <michael.bishop@iohk.io>
"master" is not a valid SHA-1 commit hash, and it's not even
necessarily the branch used. 'nixos-version --revision' now returns an
error if the commit hash is not known.
In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
When installing a fresh NixOS system it occasionally happens that you
encounter issues that are rather hard to track down since
`nixos-install(8)` doesn't provide any debugging flags.
This patch adds `-L` to force `nix build` to display the build-log on
stderr and `-v` to increase the log-level of Nix.
1. This makes aggregates of submodules (including the very important
"nixos-option users.users.<username>" case) behave the same way as any
other you-need-to-keep-typing-to-get-to-an-option-leaf (eg:
"nixos-option environment").
Before e0780c5:
$ nixos-option users.users.root
error: At 'root' in path 'users.users.root': Attribute not found
An error occurred while looking for attribute names. Are you sure that 'users.users.root' exists?
After e0780c5 but before this change, this query just printed out a raw
thing, which is behavior that belongs in "nix eval", "nix-instantiate
--eval", or "nix repl <<<":
$ nixos-option users.users.root
{
_module = {
args = { name = "root"; };
check = true;
};
createHome = false;
cryptHomeLuks = null;
description = "System administrator";
...
After this change:
$ nixos-option users.users.root
This attribute set contains:
createHome
cryptHomeLuks
description
extraGroups
group
hashedPassword
...
2. For aggregates of other types (not submodules), print out the option
that contains them rather than printing an error message.
Before:
$ nixos-option environment.shellAliases.l
error: At 'l' in path 'environment.shellAliases.l': Attribute not found
An error occurred while looking for attribute names. Are you sure that 'environment.shellAliases.l' exists?
After:
$ nixos-option environment.shellAliases.l
Note: showing environment.shellAliases instead of environment.shellAliases.l
Value:
{
l = "ls -alh";
ll = "ls -l";
ls = "ls --color=tty";
}
...
When running e.g. `nixos-option users.users.ma27`, the evaluation breaks
since `ma27` is the attribute name in `attrsOf (submodule {})`, but not
a part of the option tree and therefore breaks with the following
errors:
```
error: At 'ma27' in path 'users.users.ma27': Attribute not found
An error occurred while looking for attribute names. Are you sure that 'users.users.ma27' exists?
```
This happens since the option evaluator expects that either the option
exists or the option is a submodule and the "next" token in the
attribute path points to an option (e.g. `users.users.ma27.createHome`).
This patch checks in the `Attribute not found` condition if the attribute-path
actually exists in the config tree. If that's true, a dummy-attrset is created
which contains `{_type = "__nixos-option-submodule-attr";}`, in that case, the
entire entry of the submodule will be displayed.
