| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Making it a proper module with options allows us to selectively switch
off stuff we don't need, e.g. saneterm. This should help keeping the
closure of ludwig smallish.
Additionally refactor font handling in the module: Instead of including
fonts.nix and assuming Bitstream Vera is available, we check
fonts.fontconfig.defaultFonts for the font to prefer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After resume from suspend the NVMe does not wake up again when the
device was put into D3cold. This is something that is worked around by
TUXEDO Tomte[1] via udev rules. However, I personally don't like this
approach and it can lead to race conditions when we're going into
suspend before udev is initialised.
Interestingly, the device does even go into NPSS via APST, but if
changing to D3cold while APST is enabled, the device does not wake up
again.
Right now I just added a new quirk to disable D3cold during device
probe for now, but we could maybe find a better workaround eg. by
disabling APST before D3cold and re-enabling it again. Not sure whether
this is feasible, but since I have limited time right now I can't dig
more into this.
[1]: https://github.com/tuxedocomputers/tuxedo-tomte/commit/2c8d71170868a2663705fbea6ac150eecb96e6ce
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
| |
Upstream is dumb, but the tool is certainly useful, so let’s patch it
to make it workable and then also patch the nixos module …
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had some weird issues with the low-battery udev rule, mainly it not
triggering when it should. Usually, the event would only get processed
when the battery changed state, e.g. from Discharging to Charging.
Consequently, the laptop would hibernate when you'd save it from running
out of battery by plugging it in, but, if you forgot, it'd be content to
run out of battery.
I'll try upower instead now which is the “normal” solution used by the
major desktop environments. It's has some extra complexity, as it also
provides a d-bus API for other applications to use, but we'll see how it
goes.
|
|
|
|
|
|
|
| |
* Delete patched mandoc derivation and documentation.mandoc module from
the tree, both have an equivalent upstream now.
* Activate upstreamed documentation.man.mandoc module in my machines.
|
| |
|
|
|
|
|
| |
Silly me for not noticing that I was using the pkgs version rather than
the module version. Thanks to @aszlig for pointing out my idiocy. :)
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't do much other than enabling cache.tvl.su as a binary cache
currently, but we can additional settings in the future which are neat
for working with tvl's depot.
I contemplated adding an option to add <depot> to the nixPath, but I
don't want it too desparately right now and it is kind of annoying to
implement for vuizvui, as the default core/common.nix module overrides
any values you set and it is hard to merge the nixPath values, so we'll
probably need an vuizvui.extraNixPath option etc. pp.
|
|
|
|
|
|
|
| |
gonic is a modern alternative to mpd, it indexes music directories and
provides a server with a protocol to request files and metadata.
It has an Android app.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
So far I've almost exclusively used scrot for screenshots, but most of
the time I used an image manipulation program to pixelate stuff, add
descriptions or draw arrows.
Flameshot combines this in a single application, so I expect that from
now on I can spam-post screenshots in even a higher rate than before ;-)
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
| |
This module implements a drop-in replacement for documentation.man which
finally lets me get rid of pkgs.man-db. This is still to be considered
experimental as the required patch hasn't landed in upstream mandoc yet.
Should that happen, I'll try to contribute this module back to nixpkgs.
A more detailed description on the module and mandoc on NixOS can be
found at the top of modules/user/sternenseemann/documentation/mandoc.nix
|
|
|
|
| |
machines/sternenseemann/wolfgang: refactor using new sway module
|
|
|
|
|
|
|
| |
Module for the foot (wayland) terminal emulator. Approach for this
module is to take advantage of toINI and freeform module types to allow
users to freely set any option while still offering some higher level
representations for fields where plain strings would be inconvenient.
|
|
|
|
|
|
|
|
| |
I no longer use Taskwarrior and since my config.patch fails to apply in
the most recent release, I think it's time to finally remove it from my
workstation profile.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
| |
This is in preparation of me leaving SpaceVim behind and not having to
rely on external sources for certain programs, such as Vim, when
installing a new machine.
|
| |
|
|
|
|
| |
Also add the service to legosi so I can use it from the weechat user.
|
| |
|
|
|
|
| |
Headless server for the drawpile shared drawing application.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the following evaluation error:
The option `services.xserver.displayManager.slim' can no longer be
used since it's been removed. The SLIM project is abandoned and their
last release was in 2013.
Because of this it poses a security risk to your system.
Other issues include it not fully supporting systemd and logind
sessions.
Please use a different display manager such as LightDM, SDDM, or GDM.
You can also use the startx module which uses Xinitrc.
Here is the nixpkgs upstream pull request removing SLiM:
https://github.com/NixOS/nixpkgs/pull/73251
Since I was using a custom theme for SLiM and actually liked the
minimalism, it's probably time to start patching LightDM soon. For now
however, I'll stay with a default LightDM configuration and wait until
I'm getting annoyed :-)
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
| |
Even though these options are rather opinionated rather than generally
useful, it makes sense to have an option for that because I'm going to
use it for my managed machines as well.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The config.patch doesn't apply for Gajim 1.0 anymore anyway, so let's
throw everything away, including my custom config in order to start with
a new abomination.
With the new approach, I'm going to patch the configuration defaults
*directly* into Gajim, because one of the problems with the old approach
was that whenever specifics about a configuration value has changed, I
didn't get noticed by a patch failure.
So in the end the config I was ending up was a big mess.
I'm going to start this with a new unpatched version and someday get to
a patched version that I'm staisfied with... hopefully ;-)
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We no longer use the legacy SSH store protocol for taalo but the new
ssh-ng protocol, which makes the implementation of taalo-build a LOT
less clunky.
It also didn't make sense to have this as a NixOS module when we after
all just emit a static store path without any stuff depending on
configuration options.
The new implementation basically just wraps nix-build and nix-store -r
along with the right NIX_REMOTE variable.
With Nix 1.2 this can also be done with the new "nix build" command
using the --store option, but unfortunately "nix build" doesn't yet have
the same functionality as nix-build.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch, @bendlas
|
|
|
|
|
|
|
|
|
| |
Since version 4.0 of xpdf, the UI has vastly changed and the
configuration setting I'm using in this module no longer is necessary
for me. So let's drop the module altogether until I'm getting used to
the new xpdf and find new things I don't like :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't use anything that's machine specific within my Vim
configuration (and even if, we can pass it via the callPackage
arguments) so it's kinda pointless that it's a module instead of a plain
package (override).
This makes it also easier to nix-build the package without the need to
go through the module system.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This dissolves the user.aszlig.system.kernel module, which was not only
to stay on the latest bleeding edge kernel but also to enable BFQ. The
latter has been factored out already a while ago already.
Originally, I had a fully custom kernel config for mmrnmhrm and dnyarri,
but it's no longer the case and thus the user.aszlig.system.kernel
module is now no longer needed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
The service and test has been broken for a long time now and nobody
really has any interest in using it or even fixing it, so I'm removing
it to decrease the amount of crap we have in there.
If somebody still wants to use this someday we can still bring it back.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
Not everybody likes to have the latest release canidate kernel, so we
now have an option called vuizvui.system.kernel.bfq.enable, which *only*
enables the BFQ scheduler per default.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @devhell
|
|
|
|
| |
A simple script to gather DNS & download speed data.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces another profile module called "packages", which contains
all the package configuration (including overrides) of all the machines
in the devhell namespace.
The machine-specific configuration is now merged into the machine
configurations the same way as we've done previously with the services.
One major difference here is that the haskellPackages workaround is no
longer needed in the package configuration, as it is handled by vuizvui.
Tested this by evaluating all machines and all evaluations succeeded.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @devhell
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've added another profile called "services", which now resembles the
services_common.nix from the previous configuration.
The machine-specific definitions now reside directly inside the
machine's Nix expressions for now, until they're properly refactored.
Most of these machine-specific values can be easily modularized,
especially the xrdb config, for example having one base xrdb module
and only small machine-specific definitions if stuff needs to be
overridden.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @devhell
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In his configuration he had machine_common.nix which was imported from
the other machine_*.nix files. However in order to start modularizing
I've converted machine_common.nix into a proper NixOS module which now
resides in modules/user/devhell/profiles/base.nix and can be simply
activated via:
vuizvui.user.devhell.profiles.base.enable = true;
Apart from that I've removed the following configuration definitiens
from machine_common.nix:
nix.binaryCaches = [
"https://headcounter.org/hydra/"
"https://cache.nixos.org/"
];
nix.requireSignedBinaryCaches = true;
nix.binaryCachePublicKeys = [
"headcounter.org:/7YANMvnQnyvcVB6rgFTdb8p5LG1OTXaO+21CaOSBzg="
"cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY="
];
nix.nixPath = lib.mkOptionDefault [
"nixpkgs=/home/dev/git/remote/other_github/nixpkgs"
];
The reason for removing them is because we already handle that via the
vuizvui core modules (modules/core/common.nix).
I've tested this by evaluating the machines by temporarily setting
"allowUnfree = true" (which is part of another module I didn't migrate
yet) and it succeeds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @devhell
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows to add packages to vuizvui.lazyPackages which then aren't
directly installed onto the system but instead built by the Hydra and
only fetched from it as soon as a binary of one of these packages is
executed.
Doing this only within a NixOS module however isn't enough, because by
default gc-keep-outputs is false, so a garbage collect on the Hydra
instance would remove the packages we wrap in vuizvui.lazyPackages.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
| |
Apparently the defined options are now out-of-date.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently I just needed to support HP printers and scanners among all
the managed machines, so I thought it would be a good oportunity to
start a common profile for end user machines.
Right now there isn't that much factored out yet, but instead of copy &
pasting the printer/scanner config into all three machines I'm putting
it into the profile.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e3f8d28d6be67257d70035d122263f3a35adc438 and my
attempts to mitigate this in 0a50f5fab1abf2e70fd5d7a2dd717c2f2c1b983b
and 3b91f25b37ea709f5c86e38a50061199bbed5341.
Vuizvui is a repository for experimental stuff, but NOT a dumpster. So
please refrain from pushing waste into this repository, like markers for
a failed merge.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
|
| |
Regression introduced by e3f8d28d6be67257d70035d122263f3a35adc438.
Another time where a commit references files without actually adding
them. So let's remove the missing module from the module list and let
only those machines break which are actually using it.
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>
|
|
|
|
|
| |
Draws out the general config for all Labtops in its own module and
creates a structure to specify the setting which are different.
|
|
|
|
|
|
| |
Add simple fasd integration for fish.
A command `z` directly jumps to the most “frecent” folder fitting its
argument.
|
|
|
|
|
|
|
| |
This is to not clutter up the hardware/ namespace with patches (we're
going to add one).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
We do things such as placing gnupg into environment.systemPackages, so
calling this just "programs.gpg-agent" doesn't fit that. Especially if
we really want to have a way to specify configuration values in case I'm
getting masochistic someday ;-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since NixOS/nixpkgs@5391882 there no longer is the option to start the
agent during X session startup, which prompted me to write this module.
I was unhappy how GnuPG is handled in NixOS since a long time and wanted
to OCD all the configuration files directly into the module.
Unfortunately, this is something I eventually gave up because GnuPG's
design makes it very hard to preseed configuration. My first attempt was
to provide default configuration files in /etc/gnupg, but that wasn't
properly picked up by GnuPG.
Another way would have been to change the default configuration files,
but that would have the downside that we could only override those
configurations using command line options for each individual GnuPG
component.
The approach I tried to go for was to patch GnuPG so that all the
defaults are directly set in the source code using a giant sed
expression. It turned out that this approach doesn't work very well,
because every component has implemented its own ways how to handle
commandline arguments versus (default) configuration files.
In the end I gave up trying to OCD anything related to GnuPG
configuration and concentrated just on the agent.
And that's another beast, which unfortunately doesn't work very well
with systemd.
While searching the net for existing patches I stumbled upon one done by
@shlevy:
https://lists.gnupg.org/pipermail/gnupg-devel/2014-November/029092.html
Unfortunately, the upstream author seems to be quite anti-systemd and
didn't want to accept that into the upstream project.
Because of this I went for using LD_PRELOAD to pick up the file
descriptors provided by the systemd sockets, because in the end I don't
want to constantly catch up with upstream and rebase the patch on every
new release.
Apart from just wrapping the agent to be socket activated, we also wrap
the pinentry program, so that we can inject a _CLIENT_PID environment
variable from the LD_PRELOAD wrapper that is picked up by the pinentry
wrapper to determine the TTY and/or display of the client communicating
with the agent.
The wrapper uses the proc filesystem to get all the relevant information
and passes it to the real pinentry.
The advantage of this is that we don't need to do things such as
"gpg-connect-agent updatestartuptty /bye" or any other workarounds and
even if we connect via SSH the agent should be able to correctly pick up
the TTY and/or display.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Very preliminary and doesn't have all the option descriptions right, nor
does it have convenience features such as setting allowAdminCommands
based on whether any users are defined with admin privileges.
Of course the latter needs to undergo the decision on how to handle RCON
connections, because the latter *might* need that option.
But apart from that single option, there are a lot more options we need
to flesh out.
Also, the test currently is very limited and only spins up a client,
connects to the server and does a movement (just walk to the right).
Needless to say, it's even quite fragile and relies on OCR to properly
detect the custom pixel fonts from Starbound. Which unfortunately fails
most of the time.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|