| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
It's actually a backport of Realtek's own USB WiFi driver that is not
(yet?) in mainline. I'm using this for tyree (the T100HA) because the
internal WiFi card isn't recognized by SDHCI yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We already have a directory just for hardware-specific configuration
options and the module option already says "vuizvui.hardware", so it
should better be consistent with the directory layout.
Tested using:
nix-instantiate release.nix -A machines.profpatsch.katara
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
| | |
|
| |
|
|
|
|
|
|
| |
This module is for declaratively specifying SDL_GAMECONTROLLERCONFIG, an
environment variable used by SDL 2 to map arbitrary controllers to that
of an XBox reference controller.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
| |
This should go into its own hardware module, so it might be helpful for
others as well (especially if we're going to put it into upstream
<nixpkgs>).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
| |
It's only a very handy keybinding for toggling the outline, because it
sometimes gets very annoying if you don't want to go full screen but
still don't want that outline eating up space (and no, I don't want to
reach for the mouse).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is primarily for whenever I'm on the road with varying degrees of
internet connectivity.
What it essentially does is ssh to mmrnmhrm, then ssh to taalo and then
run nix-store --serve --write on it. Taalo is the Hydra master of
https://headcounter.org/hydra/ and it has remote builds enabled.
The script essentially only builds on the remote host but doesn't fetch
the builds. The latter can be done if the Hydra is added as a build
cache to the local system, which in case of vuizvui is by default.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
| |
This is basically just to get started and for testing whether our idea
will actually work out as planned. My gut feeling is that Hydra
explicitly needs jobs for these tests, but we'll see.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building ISO images for all machines really doesn't make sense if we
only have _one_ machine at the moment, where we really use it (kzerza).
So we now have an option which can be defined for a particular machine
configuration, which is then going te be excempted from the ISO building
process.
The latter isn't yet implemented however, only the option is here right
now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This comes with a patch to chainload taskwarrior configs and defaults to
the config supplied by the module. So if we want to play around with
different configuration values, it's easy to do by just adding a
~/.taskrc.
Note that the patch uses nestlevel 2 for ~/.taskrc, because if we would
use the default (1), the default configuration would be applied prior to
parsing ~/.taskrc, which of course would balk our plan.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
| |
This reverts commit fc53a72f48ae6b567e7bf9901a2bd3657853633c.
Applied upstream at NixOS/nixpkgs@224ed7e.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
| |
This is very useful if you're running a lot of the same instances of
particular applications. For example virtual machines or even lots of
terminals.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
| |
This is for @richi235 only, but the module is generic enough to be
included in the top-level modules. I highly doubt that anyone else would
have a use for this, at least until we have replaced the module with a
kernel space variant of the same.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I've moved the restrictions config of Postfix into the default module
for now and actually fixed it so that it's actually working (the config
value wasn't set before). Also, the option type was incorrectly set to
types.list, which aliases to types.listOf and expects another function
(kind) as its argument.
This marks the end of LaberNix and the beginning of a new Vuizvui!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just moving the overrides into the base profile isn't enough here,
as we wouldn't be able to refer to packages anymore, because the global
nixpkgs.config override is now gone.
Instead, we're now putting pkgs.vuizvui.* into the NixOS module system
by a new profiles/common.nix, which is used unconditionally for all
machines.
Of course, the result of this is that we now need to change all
references to vuizvui-related packages, which also is a good thing,
because we will no longer shadow existing packages from upstream
nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
| |
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
| |
Gets rid of my own crap in the vuizvui pkgs namespace and makes it
easier for other users to selectively use my Vim configuration.
It's still not as fleshed out as I wish it would be, but let's do that
later if needed.
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>
|
| |
|
|
|
|
|
|
| |
Now we no longer pollute the repository root with Gajim (for example in
cfgfiles/) and it's also easier to enable/disable my personal Gajim
config among my own machines.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
| |
The profile is now a directory with a default.nix, which makes it more
managable without shovelling the whole packages.nix into the profile
module.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Both files are specific to my machines only and need to be generalized
in order to be useful for anyone else.
Moving these files has a few other censequences, such that we now need
to automatically import the module-list.nix in callMachine.
Speaking of module-list.nix, the file is now alphabetically sorted.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
| |
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
Some modules might be generic enough to be included in modules/
directly, but for now, let's just get them out of the way.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
Allows to declaratively specify the Git configuration options using
nested attribute sets.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
| |
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
| |
Unfortunately it's only "fancy" in quotes because the way it's activated
is using a dummy socket file with the user "aszlig" hardcoded at the
moment. In terms of security it isn't a problem, because vlock is using
PAM for authentication and it falls back to authenticating against the
root user.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
| |
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
This also means that we now have to explicitly enable a certain feature,
such as vuizvui.i3 (which is the only module right now).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
