| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Another point where we rely on nixpkgs-path.nix from within release.nix,
where we already have the correct path to nixpkgs passed as an argument.
So let's simply pass that argument along to the actual test.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
After looking at that expression again, it turns out that we actually
don't even need to use __withPkgsPath, because all of the functionality
in there can be done using primops only.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using __withPkgsPath is a way better name, because two underscores in
front of it commonly designate an internal attribute, which it is.
The callNetwork function now works in a similar vain as callMachine,
having a canonical way to specify the path to nixpkgs.
I've also changed the recursive search of machines to use the
__withPkgsPath attribute as a way to detect whether it's a machine.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a bit unfortunate that I removed the extraConfig attribute from
<vuizvui/machines> back then (49dc58c6f8d72a4e142176f25da52666ef9ae268).
Now we could have used this argument to pass the nixpkgs path from
release.nix back into call-machine.nix, but introducing that extra
argument again would break the configs of all of the systems using
Vuizvui.
So instead, I've added a function exposed by call-machine called
withPkgs, which overrides the whole attribute set returned by
callMachine to use nixpkgs from the given argument.
This allows us to run in restricted evaluation mode as enforced by Hydra
and Nix 2.0 and while we could simply disable restricted eval, it's even
better if we comply with it.
Unfortunately I lied a bit, because we've been running in restricted
eval mode before. This time however it seems that some change in Nix has
caused this to be even more restrictive because now Nix search paths are
not allowed as well. Relying on those within a Hydra jobset however is
discouraged anyway.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
No changes of functionality, but having paths with a common ancestor
that flood the horizontal space isn't really nice to view side-by-side.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now we're not using the system attribute at all and we can still
use nixpkgs.system to set the attribute for a particular machine.
So we now can pass configuration attributes to the second argument of
callMachine *directly* instead of using specific subattributes, which I
think feels is a more natural way so users don't need to look up that
"extraConfig" is for adding configuration values.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
Commit 31809189d5126979e51b4fb4cf0fa7a35a401e53 introduced this.
Unfortunately using extraConfig as a fallback isn't really how this was
intended to work, so let's make sure we _always_ supply the extraConfig
to the module.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
On NixOps as well as for NixOS test networks, there is a nodes attribute
which allows to reference configuration definitions from other modules.
Currently this isn't used at all but might come in handy if we want to
cross-reference machine configurations (for example referencing IP
addresses in a static network configuration).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
Just to keep the default.nix clean and easy to read.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
This is to name it closer to what NixOps calls a network expression, so
that it's clear that there is more abstraction going on like setting the
hostname rather than just being a plain mapAttrs over callMachine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
It's only for consistency and so has no real feature changes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
We now no longer need to import the call-machine.nix directly but now
can use import <vuizvui/lib> in order to get *both* the callMachine and
the callMachines function.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far callMachine only accepted the system attribute as its sole
argument, but especially if there are more machines with common
attributes, it makes sense to actually call the machines with option
definitions that are for example enabling a specific profile module.
For example:
let
commonAttrs.extraConfig = {
common.profile.enable = true;
};
in {
foo = callMachine ./foo commonAttrs;
bar = callMachine ./bar commonAttrs;
}
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
Factor out the common iso code and use the minimal installer module to
create a vuizvui installer for the current config. Add vuizvui to the
NIX_PATH in the resulting system.
|
|
|
|
|
|
|
| |
We can't possibly test those on Hydra, so let's exclude them from the
release.nix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
In NixOS/nixpkgs@edb8991 the version got bumped to 16.09, so
fileSystem.*.options no longer takes a plain string.
The original change has been introduced in NixOS/nixpkgs@3c5fca9 and we
already use it everywhere in vuizvui but not for the ISO image builder
yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The shortcut is mainly to make things a bit easier, instead of:
nix-build '<vuizvui/machines>' \
-A aszlig.tishtushi.eval.config.system.build.toplevel
We can now do something like this:
nix-build '<vuizvui/machines>' \
-A aszlig.tishtushi.build
... in order to get a system store path out of a machine definition.
This also fixes an evaluation error in the top-level default.nix. Thanks
to @Profpatsch for bringing this to my attention.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
This reverts commit 3bf7b0dc9d087d7c141f317456e7abdd60ceda2a.
Since NixOS/nixpkgs@269f261 there is a separate "nomodeset" boot menu
option, so we no longer need this workaround.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
Regression introduced by 8c1b7661ae7801233df2ef5cacb07c7382d74fdd.
We now have an "eval" attribute, so we shouldn't try to reference or
shadow it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gets rid of the use attribute, which is now called "config". We had
the "config" attribute before but it was kinda pointless, because it was
just the import of the path and nothing else.
So the config attribute now is the machine configuration with all of the
vuizvui modules imported as well.
The "build" attribute is now called "eval", which is more appropriate,
because it's the evaluation of the configuration and not the finished
system build.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
The tests from vuizvui itself weren't properly included in release.nix,
because we're patching up our own source tree and thus the evaluator is
unable to find the right path.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
The upstream tests all have their attributes cleaned up by the
"hydraJob" function, so we can't check for the "test" attribute.
Luckily this isn't a problem, because we're only searching for "anything
not plain attribute namespacing" anyway.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
So my gut feeling in 90c080e was't wrong after all, so we need to create
jobs for all the tests the machines include.
In order to make this easier, we're going to re-use the collection of
all test attributes from release.nix so putting it in lib/ makes sense.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
The function is gettin rather large, so it makes sense to move it into
another file so that the default.nix in machines/ won't be cluttered up
with all the implementation-specific details.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This means, we don't have that lib directory anymore and also we're not
doing text substitution on the kernel config but instead override the
original attributes.
However, this needs to be refactored even further, so we can use the
NixOS kernel system, which allows for certain modules to require
specific kernel features. That way we can automatically create a kernel
config from the list of required features and we only need to set a
specific base config instead of specifying the *full* kernel config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
This should get rid of the duplication already marked with XXX and of course
should make the machine-specific configuration way easier to read.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|