| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
CVE patch is out already, but let’s wait until upstream has all the
patches.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the options in nix.conf are now exposed as a submodule with a
freeform type and since that change[1] got introduced, we get a bunch of
warnings during machine evaluation:
trace: warning: The option `nix.useSandbox' defined in `...' has been renamed to `nix.settings.sandbox'.
trace: warning: The option `nix.maxJobs' defined in `...' has been renamed to `nix.settings.max-jobs'.
trace: warning: The option `nix.buildCores' defined in `...' has been renamed to `nix.settings.cores'.
To shut them up, I went through all machines and modules and renamed the
remaining options that were not renamed back then when @devhell did some
renames in a0297bf921399c3243dcca99626d8697f0735abe.
This was done by looking through the output of:
$ git grep -A 10 '\<nix\(\.\| *=\)' machines modules
After that I tested the contents of the nix.conf of all the machines
against the changes this commit introduced via the following command:
$ nix-build --no-out-link -E '
with import <nixpkgs/lib>;
map (m: m.eval.config.environment.etc."nix/nix.conf".source)
(collect (m: m ? eval) (import ./machines))
'
I've sorted the resulting nix.conf files and diffed on that result and
the only difference that showed up was the following:
allowed-users = *
-auto-optimise-store = false
auto-optimise-store = true
builders-use-substitutes = true
cores = 0
This is because the previous way to generate the config was by
concatenating strings whereas the new way works on an attribute set, so
we get deduplication by design.
[1]: https://github.com/NixOS/nixpkgs/pull/139075
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @devhell
Cc: @Profpatsch
Cc: @sternenseemann
|
| |
|
|
|
|
| |
Apparently one of its python dependencies went EOL and everything went
to fuck because python is a crapfest and nixpkgs policies around it
are stupid. yay.
|
| |
|
|
|
| |
This is not pretty, some of the code lives in vuizvui, some lives in
tvl depot. But at least it seems to work for now :)
|
| |
|
|
| |
though the backup service is broken on the machine anyway, idk
|
| | |
|
| | |
|
| |
|
|
|
| |
Changes the weechat setup so that I can have multiple instances, each
gets their own unix user & separate weechat instance.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Starting with Kernel 5.6 adding this package is no longer necessary.
Since the kernelPackages.wireguard attribute returns `null` for that
version, evaluation fails.
cc @Profpatsch
|
| | |
|
| |
|
|
|
|
| |
The goal is to be able to have multiple weechat services on one
machine, so a bunch of people can run their weechat clients under
different service users.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The general consensus seems to be to use
vuizvui.user.<username>.<category>.<module name>
instead of
vuizvui.<category>.<user name>.<module name>
Things done to test this change:
* Checked build of machines.profpatsch.legosi.build
* Checked evaluation of machines.profpatsch.shiki.build
|
| |
|
|
|
| |
This should backup every service in `/var/lib` and anything I add in
the future that I might have missed.
|
| |
|
|
|
|
|
|
|
|
| |
Previously I had actually rebuilt the system locally, but since I use
the deploy script, I don’t need to have a full up-to-date nixpkgs
checkout, and only copy over the system closure.
Thus, set the path to only contain nixpkgs, and only a link to the
latest github unstable tarball in case I really need it e.g. for a nix
shell.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also add the service to legosi so I can use it from the weechat user.
|
| | |
|
| |
|
|
| |
No libpurple for just XMPP, phew.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While it's fine to use <nixpkgs> on most systems, we deliberately want
to avoid the use of <nixpkgs> to make sure that whenever we for example
run <nixpkgs/nixos/lib/eval-config.nix> with a custom "pkgs" argument we
are guaranteed that we get the version we specify.
So this is one of the reason I used <nixpkgsSrc> on Hydra instead of
<nixpkgs>, so that whenever we have such occasions where we can't
guarantee such things, the evaluation will fail.
And right now, it does:
in job 'machines.profpatsch.legosi':
file 'nixpkgs/nixos/modules/profiles/qemu-guest.nix' was not found in
the Nix search path (add it using $NIX_PATH or -I), at
.../machines/profpatsch/legosi.nix:12:5
Fortunately, there is modulesPath, which refers to
<nixpkgs/nixos/modules> of the nixpkgs version passed via "pkgs".
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch
|
|
|
Small Hetzner qemu virtual server.
|
