This is useful for adding extra functionality or defaults to _every_
nixos evaluation.
My use case is overriding behaviour for all nixos tests, for example
setting packageOverrides to newer versions and changing some default
dependencies/settings.
By making this accessible through an environment variable, this can now
be fully accomplished externally. No more need to fork
nixos/nixpkgs (which becomes a maintenance burden), just use the channel
instead and plug in via this envvar.
It was trying to find "gs" via execve, so use execvpe instead. It's
probably better to use gs's absolute path, but maybe not every
cups-filters user needs it.
Fixes this error, as seen when trying to open a guest VM when
virt-viewer is accessed over ssh with X forwarding:
GLib-GIO-ERROR **: Settings schema 'org.gnome.system.proxy' is not installed
A similar issue was fixed for virt-manager in commit
fb8a2b3be7 ("virt-manager: fix missing
schema error")
We divert to the $out/share/virtualbox directory only if we have
hardening enabled, so let's put the extension pack into
$out/libexec/virtualbox instead if we're compiling without hardening.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The warning was displayed whenever services.virtualboxHost.enable was
true, but if people were to enable hardening, they'd still get that
annoying message.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* Add missing dependency on 'spice_protocol'
* Fix new build error which came now that ./configure enables SPICE support:
building virt-viewer
CCLD virt-viewer
/nix/store/b8qhjrwf8sf9ggkjxqqav7f1m6w83bh0-binutils-2.23.1/bin/ld: cannot find -lgdbm
/nix/store/b8qhjrwf8sf9ggkjxqqav7f1m6w83bh0-binutils-2.23.1/bin/ld: cannot find -lcap
collect2: error: ld returned 1 exit status
Fix by adding gddbm and libcap as inputs. Yes, libcap is needed
_in addition_ to libcap_ng (I tested removing libcap_ng, it failed).
Without this change, virt-viewer cannot be used with guests machines
that uses SPICE.
DwarfTherapist does some ugly stuff by matching the first 8 characters
of the md5sum of the game binary to match its binary content. This patch
adds support to automatically patch the ini files.
Creates unnecessary cruft in the root users home directory, which we
really don't need. Except the log, but therefore we now cat the log to
stderr and the private temporary directory is cleaned up afterwards.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should display a big fat warning that people can hardly miss until
we have fixed the issues with the host-only-interfaces that persist when
hardining is enabled.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Essentially adds two more VirtualBox VMs to the test and also increases
the memory size of the qemu VM to 768 MB to make sure we don't run out
of memory too soon.
We're testing whether those two VMs can talk to either each other
(currently via ICMP only) or to/from the host via TCP/IP.
Also, this restructures the VM test a bit, so that we now pass in a
custom stage2Init script that has access to the store via a private
mount over the /nix/store that's already in the initrd. The reason why
this is a private mount is that we don't want to shadow the Nix store of
the initrd, essentially breaking cleanup functionality after the custom
stage 2 script (currently this is only "poweroff -f").
Note that setting the hostname inside the VirtualBox VM is *not* for
additional fanciness but to produce a different store path for the VM
image, so that VirtualBox doesn't bail out when trying to use an image
which is already attached to another VM.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Yes, this is only on the package level, so it's possible to use
VirtualBox for example installed by nix-env -i, which of course doesn't
have access to the functionality provided by the various VirtualBox
kernel modules.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Hardening mode in VirtualBox is quite restrictive and on some systems it
could make sense to disable hardening mode, especially while we still
have issues with hostonly networking and other issues[TM] we don't know
or haven't tested yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We're going to create more than one VirtualBox VM, so let's dynamically
generate subs specific to a particular VirtualBox VM, merging everything
into the testScript and machine expressions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
