| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following eval error:
The option `services.paperless' can no longer be used since it's been
removed. The paperless module has been removed as the upstream project
died.
Users should migrate to the paperless-ng module (services.paperless-ng).
More information can be found in the NixOS 21.11 release notes.
We don't use paperless in any machines but since we're testing for NixOS
module option definitions, we're running into the eval error above.
Switching to paperless-ng should get rid of them.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While I love the idea of being able to use different interfaces for my
music listening, I'm not sure it's really worth it locally anymore. I
have an MPD server running on the network, which I can still connect to
using `ncmpcpp` for example, but for local playback, such as at work,
there is no point really in keeping it around. For local playback on
`gunnr` I'll just find something else. This would also solve my previous
PipeWire problem.
|
|
|
|
|
| |
I'm a bit annoyed at how `geoclue2` has everything and the kitchen sink
enabled, so I'm refining it here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
buildEnv is conservative with creating symlinks, i. e. it only creates
directories if it has to. Consequently if a directory is only present in a
single package in the environment, it'll be a symlink.
Enter: makewhatis(8), a tool that has never imagined a creation as accursed as
Nix or even NixOS. Thus it assumes that probably no one ever uses symlinks in
their man directory and if they do, it'll be to alias man pages. Consequently
it assumes that all symbolic links are files [1] and ignores them in the
normal mode because they are in the wrong place. To still be able to use
apropos(1) with POSIX man pages, introduce this shell hack to re-create the
symlinked directories before building mandoc's db.
[1]: See also
https://inbox.vuxu.org/mandoc-tech/bccac2cd-01b6-b349-86e5-de4066ed8dee@systemli.org/T/#u
|
|
|
|
| |
Can't believe I've fixed all those aarch64 failures without this so far.
|
|
|
|
| |
The READ_ALLOWED_PATH patch was applied 🥳
|
|
|
|
| |
https://inbox.vuxu.org/mandoc-tech/c9932669-e9d4-1454-8708-7c8e36967e8e@systemli.org/T/#m445439360d5fbe71849001e39ce1e78a8a7d024f
|
| |
|
|
|
|
|
|
|
| |
Nevermind, I did test it before adding it, but I didn't test everything,
and as it turns out it's not what I hoped it would be.
This reverts commit 45894282b28ff8dee8ed7f1a31710ddc6ce275a2.
|
|
|
|
|
| |
I'm working so much with markdown lately that I'd find it helpful if I
didn't have to think of every markdown rule myself.
|
|
|
|
| |
I'm used to `sd` enought now to not forget it in lieu of `sed`.
|
|
|
|
|
|
|
| |
Enabling tab colors like this throws an eval error. Don't have time to
look into it right now, so reverting by adding `any-nix-shell` instead,
which looks useful since the default bash prompt is rather primitive and
gives no info whatsoever.
|
|
|
|
|
| |
This was annoying me for the longest time, but now I have colors back
when ZSH tab completes paths.
|
|
|
|
| |
Looks useful, let's see.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we use 256 color mode in XTerm, using LightBlue in Vim results in
0x5fd7ff but LightBlue in GUI mode will use 0xadd8e6 which has a low
contrast to the default color (0xbebebe).
Since my eyes are not getting better with age, I decided to go with the
old color code that provides better contrast even though I'm quite happy
with the rest of the "more nuanced" colors.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
| |
calling `execlineb -c` has unfortunate quoting issues, cause for
cornercases like arguments that contain spaces or `"` the result would
be a completely broken command line.
Instead, let’s do our own block construction in a small rust
program (for speed). I tried implementing it in bash first but even
prepending spaces to a string is a complete waste of time in that
language.
|
|
|
|
| |
Interesting take on an `nmap` replacement.
|
|
|
|
|
| |
I'm really happy to have found `mnamer`, it's a bit like `beets`, but
for TV series and movies.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm already using this config since a few months and since I'm slowly
getting used to it, let's try to make it the default for my workstation
profile.
Unfortunately, libgit2 uses the Git configuration from /etc, but our
configuration is directly patched into Git and not in /etc but in
"${pkgs.git}/etc", so we need to patch libgit2 to use the right
configuration file.
Another goof is that we can't use ${pkgs.delta} directly in our Git
configuration because it would introduce a circular dependency between
Git itself and delta (which uses libgit2 which in turn refers to
"${pkgs.git}/etc"), so for the time being I'm relying on $PATH for
delta.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
| |
Duh.
This reverts commit 2d8ad8d8d158f5c4d1e3085062ec4619a18416c9.
|
|
|
|
| |
There's really no need to keep this exposed on the internal network.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I don’t remember why I set that limit, but it’s kinda silly since nix
uses all cores by default.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
The output is a bit cleaner and overall it seems to execute faster.
|
| |
|
|
|
|
| |
Neat `ps` alternative.
|
|
|
|
| |
Seems that it suffered the same fate as `pastel`, for now.
|
|
|
|
|
|
|
| |
- `rq` is similar to `jq` but works with more types
- `watchexec` is neat to execute stuff on file change
- `wuzz` is a bit like burpsuite, but on the commandline
- `xsv` is just for CSV and has it's own specific functionality
|
|
|
|
|
| |
Always loved this font a little bit. Not as cool as the ultimate
oldschool fonts, but still.
|
|
|
|
| |
I don't know why, but I enjoy testing new tools replacing old tools.
|
|
|
|
|
|
|
| |
As @aszlig mentioned earlier, this looks like a better plugin. It does
everything I need it to. This commit also enables `termguicolors` which
wasn't the case prior, and without it `vim-hexokinase` cannot function
properly.
|
|
|
|
| |
I'm not interested in shadows on everything.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Regression introduced in 709e45c2a8c231201d3f67c6a954021ca2a5f796.
With that commit I renamed the "config" option to be called "settings",
but not only that, the actual config *file* is now to be found in the
"configFile" option.
Unfortunately I forgot to change that reference, which caused an
evaluation error.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
| |
While ncurses already has support for detecting direct color terminals,
a lot of applications out there do not yet query terminfo but instead
rely on some shady COLORTERM environment variable. While I don't really
like that approach, patching XTerm to set that variable currently is
better than patching all the applications to query terminfo.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, we have passed self instead of super to our custom package set,
but this makes it very hard when overriding other packages and refering
to one of these packages in Vuizvui.
To fix this, I not only used mkBefore to make sure that the overlay
comes before every other overlay but also using super makes sure that
whenever we do overrides in Vuizvui, the package *before* the current
overlay is selected instead of possibly running into an infinite
recursion.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
This makes it hard to do static analysis on the code and it's really not
needed here, so let's use lib.X directly.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far vim-css-color worked quite well for what I wanted, but after
talking to @devhell about possible alternatives, I stumbled upon
hexokinase and tried it a bit.
One of the gripes I had with things such as colorizer is that it
highlights colors regardless of the file types we're in, which in turn
will also highlight things where the hash character is not a hex value,
for example in Erlang's base notation for integers.
Hexokinase also highlights all file types but first of all, it only
highlights things separated by word boundary and also it's way less
obtrusive because the way I've configured it only the hash character is
highlighted, not the whole color value.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, the TERM environment variable has been set to xterm-256color,
but in reality newer XTerm versions already supported 24bit colors so
setting this to xterm-direct results in using the right terminfo entry
for our terminal.
To make sure this is really the case, let's explicitly set directColor
to true, because while it is enabled in nixpkgs by default it is however
a compile-time option and could possibly be disabled.
Additionally, Vim is now looking pretty gruesome because my colorscheme
so far has used colors for 16-color terminals and I don't particularly
like the GUI colors. I added a few fixups for the color scheme to
address that.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
I haven't used the alias since a long time as it is probably apparent
due to the hardcoded "14.04" version of NixOS and given that I didn't
update the alias also speaks volumes about how useful it is altogether.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been using vimdiff3 as the merge tool for a long time, but while it
has worked fine for most conflicts, using diff3 makes the original lines
visible which I always viewed in a separate shell rather than inline in
the editor.
Switching this to diff3 should hopefully make merge conflicts more
convenient to solve from now on.
Signed-off-by: aszlig <aszlig@nix.build>
|