| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Otherwise, neither nix-env nor packagePlatforms will able to pick up the
nested derivations.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have an "i3wm" test in upstream <nixpkgs> which is much more
thorough than the unfinished test I've made here.
The intention of this test however was to specifically test the Vuizvui
service module. Nevertheless, it's still just a dummy test and the
"i3wm" test works much better, so let's remove it until we have a more
complete implementation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Since NixOS/nixpkgs@73f1f5e, we have to refer to imagemagick.out for the
binaries, because we otherwise end up with the .dev output.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
| |
Not sure if having this as a machine config is the way to go.
Comments, @aszlig?
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just a small workaround for NixOS/nixpkgs#15498, because putting the
Vuizvui version of Tomahawk into systemPackages will propagate Qt 5.5
into the system path, which in turn causes KDE initalization to
dlopen() Qt 5.5 libraries while being linked against Qt 5.6 libraries.
We currently can't link Tomahawk against Qt 5.6, because it depends on
QtWebKit, so moving Tomahawk to Qt 5.6 is not an option yet until
QtWebEngine is packaged.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Since we have disabled allowUnfree, this is the only package that was
left on my machines and I really don't even use that firmware, so it's
safe to just remove it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
The only package which pretty much is a major nuisance is Skype here and
we really need to find a way to add it to the system without actually
building it. But for now, let's mark it explicitly as unfree and
non-distributable.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The CPU microcode is already excempted from it and unrar is unfree but
redistributable, so let's use our new unfreePkgs module attribute for
that.
Apart from that I haven't found anything else on my machines, but let's
see what happens after Hydra evaluates the jobset.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
A more permanent fix for f50de454fd2f4c919195b1cc904b89343c243451.
At least we can now easily change the underlying implementation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
| |
The name "profiles" really doesn't match what these modules are for.
Instead they define the very core of Vuizvui and its internal plumbing
and those options are available/enabled to all machines and modules.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This basically provides module arguments with different variations of
the pkgs arguments so that it's easier to allow specific unfree packages
selectively.
Note that I deliberately chose "unfreeAndNonDistributablePkgs", because
we really want to let those packages stand out. We want to avoid
building those packages on Hydra as much as possible.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We want to have lib.vuizvui instead of polluting the <nixpkgs/lib>
namespace with our functions.
Apart from that the default.nix was broken because of 49dc58c, which
factored away the argument from <vuizvui/machines>.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
The printer is a Canon PIXMA MX920 and it uses a proprietary protocol
for network printing :-(
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
I found this quite annoying sometimes if the screen is so dark that you
can't see anything. Just switching to red is pretty much sufficient I'd
say, at least for me.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
It's been a while since the last update, so let's change that.
I haven't tested whether the current version works, only tested building
against it and it built fine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Right now we haven't packaged QtWebEngine for Qt 5.6, so we can't easily
switch towards using the qt5 attribute, which is Qt 5.6 already.
So we need to make sure that attica, extra-cmake-modules and qca are
using qt55 explicitly as well so we don't have any reference to Qt 5.6
anymore left (checked using nix-store -qR on the .drv).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having the default locale set to de_DE it feels pretty weird getting
output that sounds awkward (well, obviously because German IS awkward)
and I often have to pause for a minute to understand what the message
should actually mean.
The main user of the system is rarely working in the shell, but even
during those occasions it's difficult for me if I get something like
"There is an error message saying <some blurb in German>".
Also, having command line completion is a good idea as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
This attribute has been renamed in NixOS/nixpkgs@a2e40003a19de448.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Probably this stuff should be in a common module, but right now this
should do it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
It's a lot more controllable running as a user service rather than
having it started with the X session, especially because I occasionally
tend to turn it off.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
This test has been introduced by NixOS/nixpkgs@e936f7d and was part of
NixOS/nixpkgs#15275.
The check attribute is always true for this test, because it has to be
run no matter which configuration you're using. It basically makes sure
that boot stage 1 is working correctly.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
The output actually doesn't exist and I got it confused with commit
fdc46c027f3116c7f86fce445798b841bf850f99. The .docdev output for
stdmanpages actually doesn't even make sense because it's *only*
developer documentation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
It's about time to add these, because using a browser to look up the
definitions from a standard library function is quite annoying.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
With the merge of the closure-size branch, developer manpages are no
longer in the default output of the "man-pages" package.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I use FireFox occasionally for whenever I'm forced to run ugly Java
plugins (in particular Hetzner's Lara machines use it).
I hope IcedTea is capable of running the Lara plugin, but even when not,
it's not a big deal-breaker as I didn't have to use Lara consoles for a
whole while now. And if it's the case, I can still look for a "fix" :-)
So another step towards being free of proprietary software.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
Apart from an evaluation error (because ["nixos" "keymap"] results in an
attrset rather than a plain derivation), checking for the active keymap
explicitly makes more sense here. For example a user of a Neo keyboard
layout won't care about a failure of the Dvorak keyboard layout and vice
versa.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the following missing tests which were missing for our
machine-based checks:
* Taskserver
* bridging, IPv4 and IPv6 for containers
* dnscrypt-proxy
* imperative containers
* keymap (only runs if not on qwerty)
* netbooting
These are the tests which were missing in Vuizvui as of current nixpkgs
revision NixOS/nixpkgs@bf8130684878747be7b1cc393f8aa147c500f14f.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
It doesn't list a single machine and the profile module also uses the
pluralized version, so let's pluralize the file name as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
| |
A common annoyance among a lot of people and also requested by this
particular user.
Note that this now also sets consoleUseXkbConfig, so that we only need
to configure the keymap once.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
With 49dc58c, the extra argument for <vuizvui/machines> is now gone, so
we need to reflect that in the documentation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch, @lukasepple
|
|
|
|
|
|
|
| |
We factored away the system attribute from <vuizvui/machines> and it's
now a plain attrset. Unfortunately I forgot about the release.nix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now have a common library for Vuizvui functions, so we can expose it
using the default.nix to make them accessible via
(import <vuizvui> {}).lib
... very similar to (import <nixpkgs> {}).lib in addition to the shorter
form (which is also possible for <nixpkgs/lib>):
import <vuizvui/lib>
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Should make the configurations much more easy to read.
I did a small comparison between the machine derivations of the old
Labtop and the Labtop with the new callMachines implementation using:
diff -U 0 =(nix-store -qR old_labtop.drv | sort -t- -k 2) \
=(nix-store -qR new_labtop.drv | sort -t- -k 2)
The following store paths were different in the output:
/nix/store/...-etc.drv
/nix/store/...-initrd.drv
/nix/store/...-kernel-modules-shrunk.drv
/nix/store/...-nixos.conf.drv
/nix/store/...-nixos-system-labtop-16.09pre82222.fc92bbf-vuizvui.drv
/nix/store/...-stage-1-init.sh.drv
/nix/store/...-system-units.drv
/nix/store/...-unit-systemd-modules-load.service.drv
This is okay and is due to the reversed module evaluation order, because
we now have the module definition enabling the Labtop profile in
extraConfig instead of in the root config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is particularly needed for the Labtops and it allows to call a full
attribute set of machines to be incorporated into a single file as one
big attribute set.
Its functionality is kind of similar to the NixOps network expressions
by providing default hostnames (in our case with a priority of 900 to
still make it overridable without pain).
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>
|
|
|
|
|
| |
Commit I forgot; there was a change in the gpg-agent behavior and this
sets it up correctly again.
|
|
|
|
|
| |
Slides with white background are an insult to the viewers.
Also adjusts some other sizing stuff.
|