It is going to be merged into nixpkgs, under `nixos/hardware`.
This will give better discoverability, and considering the low
turnover (less than 100 commits in the last year and only 350 total)
it won’t make any dent on the size of nixpkgs.
We have a monorepo, let’s use it.
nix-env picked up `default.nix`, which contained our hardware profiles.
This is not only cpu-intensive to evaluate but also fails because
it does some import-from-derivation.
By moving default.nix to release.nix it should be no longer loaded
This makes it possible to build several NixOS systems that use different
nixpkgs in the same nix-build invocation. Today, you can't do that since
the <nixpkgs> path reference is hard-coded in lib/eval-config.nix.
The environment variable "NIXOS_EXTRA_MODULES" is now checked to
contain a path to a file similar to modules/module-list.nix.
This gives the ability to include nixos modules that are not in the
nixos source tree.
This can be useful for modules that are still experimental, or which
aren't useful for other nixos users. Of course, this was already
possible to do this using a forked nixos tree, but with this
functionality, you can just rely on the nixos channel, easing things a
lot.
like `build-vm', but boots using the regular boot loader (i.e. GRUB
1 or 2) rather than booting directly from the kernel/initrd. Thus
it allows testing of GRUB.
svn path=/nixos/trunk/; revision=23747
change a NixOS installation from x86_64-linux to i686-linux (or vice
versa if you have distributed builds enabled - I used this upgrade
from 32-bit to 64-bit NixOS).
svn path=/nixos/trunk/; revision=18177
into one argument "modules".
* release.nix: fixed the manual job.
* ISO generation: break an infinite recursion. Don't know why this
suddenly happens. Probably because of the nixpkgs.config change,
but I don't see why. Maybe the option evaluation is too strict.
svn path=/nixos/trunk/; revision=16878
machine containing a replica (minus the state) of the system
configuration. This is mostly useful for testing configuration
changes prior to doing an actual "nixos-rebuild switch" (or even
"nixos-rebuild test"). The VM can be started as follows:
$ nixos-rebuild build-vm
$ ./result/bin/run-*-vm
which starts a KVM/QEMU instance. Additional QEMU options can be
passed through the QEMU_OPTS environment variable
(e.g. QEMU_OPTS="-redir tcp:8080::80" to forward a host port to the
guest). The fileSystem attribute of the regular system
configuration is ignored (using mkOverride), because obviously we
can't allow the VM to access the host's block devices. Instead, at
startup the VM creates an empty disk image in ./<hostname>.qcow2 to
store the VM's root filesystem.
Building a VM in this way is efficient because the VM shares its Nix
store with the host (through a CIFS mount). However, because the
Nix store of the host is mounted read-only in the guest, you cannot
run Nix build actions inside the VM. Therefore the VM can only be
reconfigured by re-running "nixos-rebuild build-vm" on the host and
restarting the VM.
svn path=/nixos/trunk/; revision=16662
empty now), do more of bashrc.sh declaratively, and moved nsswitch
generation to modules/config/nsswitch.nix.
svn path=/nixos/branches/modular-nixos/; revision=15754
into a NixOS module (modules/system/activation/top-level.nix -
couldn't think of a better name). The top-level derivation is
returned in config.system.build.system.
* Inlined system.sh in top-level.nix so that we don't have to pass
everything through environment variables.
svn path=/nixos/branches/modular-nixos/; revision=15740
modules/config/system-path.nix. system/system.nix is now almost
empty.
* Removed the cleanStart option - it should be possible to get the
same functionality by overriding config.system.path (or defining
config.system.systemPackages with a higher priority - don't know if
that works though).
svn path=/nixos/branches/modular-nixos/; revision=15727
lf-