| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The isHydraChannel meta attribute is needed in order to tell Hydra that
the derivation in question should be a channel tarball. However in
Nixpkgs the meta attribute is not used, so checkMeta doesn't recognise
it as a valid attribute which leads to an evaluation error.
Recently[1] a commit got merged, which enables shallow type checking for
meta attributes by default. This led to an evaluation error for our
Hydra machine channels for the reason mentioned above.
I opted to work around that issue by adding meta.isHydraChannel after
mkDerivation, because adding isHydraChannel as a valid meta attribute to
Nixpkgs doesn't feel right to me since it's only relevant for Hydra and
its apparently deprecated[2] channel feature.
[1]: https://github.com/NixOS/nixpkgs/commit/6762de9a28e248f46bd0810e03c
[2]: https://github.com/NixOS/hydra/blob/53335323ae79ca1a42643f58e520b376898ce641/doc/manual/src/jobs.md#meta-fields
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
| |
Contains adjustments for recent alias removals in nixpkgs.
|
| |
|
|
|
|
| |
The Qr-code was done with a strange format that only allowed ASCII.
|
|
|
|
|
|
|
|
|
|
|
| |
This attribute has been renamed a while ago[1] but recently even the
alias was removed[2], which now triggers an evaluation error in Vuizvui.
[1]: https://github.com/NixOS/nixpkgs/commit/bc49a0815ae860010b4d593b02f
[2]: https://github.com/NixOS/nixpkgs/commit/ba3319568df2c6675dbe36478fb
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found this thanks to @fpletz starring the repository and since I
constantly use f/F and t/T when navigating, I decided to give it a try.
Usually when trying things, I'd just add the Vim version with the plugin
to my local Nix profile, but since I'm already irritated when other
things than the cursor are highlighted in the current line, I decided to
do something completely irrational and just add it to all my machines.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some personal history on this:
I started to get used to AT&T syntax because it's the default in GDB and
used that ever since until I one day starting to do some more reverse
engineering using radare, which defaults to Intel syntax.
Ever since then probably my most used command in GDB was "set
disassembly-flavor intel" (because I was to lazy to add it to the
config) because I constantly got confused by the source/destination
operand swaps. This even happened during live reverse engineering at rC3
where I was confused about some function logic only to find out that I
was viewing in AT&T syntax.
Fast-forward to today: I'm debugging some application using WINE and
winedbg uses AT&T syntax, which I didn't like at first. After reflecting
on this for a while, I thought it would probably be better to get used
to AT&T syntax again and switch everything to use AT&T for the following
reasons:
* Operands are more natural to read, since most libraries/APIs in
higher level languages do it like this (well, except memcpy, strcpy,
etc... maybe I now get confused by libc functions...)
* AT&T syntax feels less verbose, for example "mov ecx, dword [eax]"
is just "movl (%eax), %ecx"
This very commit makes sure that radare2 now defaults to AT&T syntax
instead of eg. ensuring that GDB uses Intel syntax by default.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using NIX_SANDBOX_DEBUG_INJECT_FILES (which we now call
NIX_SANDBOX_DEBUG_INJECT_DIRS, because it's more accurate), I usually
used it to provide fake /dev or /sys directories.
I turned out, that today I was trying to use this functionality again
(who'd have known) and it also turned out that I forgot to create the
target directory, which wasn't needed back then for /dev or /sys because
they were already existing.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
With my new laptop, a font size of 12pt is rather large and given that
hidpi displays usually have a quite large resolution (the name might
hint at that), we don't necessarily need to use embedded bitmaps anymore
which was one of the reasons why I used a point size of 12.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We only want to highlight #aabbcc-style hex colors and not every damn
hex value that happens to be 3 or 4 bytes, which is very annoying when
you're doing a lot of bit manipulation.
Additionally, I currently have a code base where "gold" is something a
player can have, so one doesn't need much imagination on how irritating
that is.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
The config we're baking in by default relies on Nightly features, so it
only makes sense to actually use a rustfmt version that supports it.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
| |
Seems like something got more strict about setup hook execution and the
relevant env vars for gi weren't set in checkPhase.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We no longer need to use extraPostFetch in order to append stuff to
the postFetch phase of fetchzip. Since this got fixed[1], we now get
appropriate warnings during evaluation:
warning: use 'postFetch' instead of 'extraPostFetch' with 'fetchzip'
and 'fetchFromGitHub'.
Neither do we like warnings nor do we like to use workarounds from the
past that got fixed, so let's fix it on our side as well :-)
[1]: https://github.com/NixOS/nixpkgs/pull/173430
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
I don’t know how I missed this, but my deploy script didn’t actually
set up a system profile, so rebooting would lead to (very) old
generations being activated again.
Thanks to @sternenseemann for the nix-env trick (via
https://code.tvl.fyi/tree/ops/nixos.nix#n55 )
|
|
|
|
| |
idk why/how this works and tbh I don’t even want to know.
|
|
|
|
| |
thx to @sternenseemann
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I know, I know, people don't like the color scheme I use, but I got so
used to it and with the new version generated via ColorTemplates it
messes with me being used to elflord with 16 terminal colors instead of
the GUI colors.
So this patches elflord in such a way that it's consistent with what I
want but still uses the new ColorTemplates version, which for example
comes with nicer colors for vimdiff.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Nope, never mind, maple is still not building, therefore vim-clap can't
build.
This reverts commit 4d4f07ef82d8a19587cc450b6d0a198e16acb48f.
|
|
|
|
| |
Apparently this builds again according to `hydra-check`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch file was relative to the rustfmt crate within the rustc source
tree, so I added "-d src/tools/rustfmt" as patchFlags to apply the patch
against that subdirectory.
Unfortunately, patchFlags also applies to other patches as well and I
didn't account for that. With current rustfmt from rustc 1.59.0 we have
a patch in nixpkgs, which now fails to apply because of this:
applying patch /nix/store/...-rustfmt-fix-self-tests.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- a/src/tools/rustfmt/src/ignore_path.rs
|+++ b/src/tools/rustfmt/src/ignore_path.rs
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
To fix this, I changed the paths in config.patch to be relative to the
rustc tree rather than just the rustfmt crate, so the patch should now
apply regardless of whether there are other patches.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
| |
*sigh*
|
|
|
|
|
|
| |
* plumb/plumber for mouse 3
* rc for mouse 2
* win for terminal feature
|
| |
|
|
|
|
|
|
|
| |
The patch no longer applies because some of the imports got changed in
the context of the diff.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The version from 2021 certainly is way too old for my desire to crave
new bugs, so let's update it for no particular reason other than gut
feeling.
Oh, well and of course I saw a bunch of OMEMO plugin fixes, so maybe if
you search hard enough you'll find compelling reasons... :-D
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
nix_2_3 is an alias for nixVersions.nix_2_3 upstream now and the test
infrastructure from nixpkgs seems to default to allowAliases = false;
when evaluating (which is actually quite concerning for downstream
usage).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
depot is a nix-based monorepo which contains some great nix utilities
like yants (a nix type system), runTestsuite, mergePatch and so on, a
few interesting pure nix builders like buildLisp and buildGo and a few
packages maintained by @Profpatsch and myself.
This change exposes tvl completely as pkgs.tvl, but prevents hydra from
building it using dontRecurseIntoAttrs as depot pins its own version of
nixpkgs which is not easily overrideable, contains some expensive to
build system configurations we are not interested in and even some
notoriously indeterministic packages.
Additionally it is possible to override pkgs.tvl to use a different or
local version of depot:
pkgs.tvl.override { tvlSrc = /home/lukas/src/depot; }
To keep with @Profpatsch's previous solution, we pass in vuizvui's
nixpkgs version to depot via nixpkgsBisectPath which may break packages
in depot occasionally if nixpkgs causes breakage in TVL and depot isn't
updated accordingly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Patch plan9port most notably including a patch that fixes the
interpretation of X11 key events. This resolves the problem that using
the shift key of the neo layout would cause acme to start interpreting
left mouse button as right mouse button.
* Add a wrapper derivation that puts acme and all executables it
absolutely requires in PATH. The full Plan 9 userland can still be
accessed via the 9 executable, but this allows executing just acme and
access e.g. the GNU coreutils from inside of it — in case you do want
to use cat -v.
machines/sternenseemann/wolfgang: install acme
|
| |
|
| |
|
|
|
|
|
| |
There are some issues with building `mkdx`, but I'm also not really
happy with the way it does markdown.
|
| |
|
|
|
|
|
|
| |
pkgs.vuizvui is made available via an overlay that only affects a system
configuration with the base vuizvui module included. When importing the
pkgs tree directly, normal rules apply.
|
|
|
|
|
|
|
| |
This is the alacritty wrapper that is added from `~/bin`.
This is a bit badly set up atm, but might change once I move things
together into one repo.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It’s hard-coded as the default case in our script already, this was
breaking that functionality.
|
|
|
|
|
|
|
|
|
| |
The way store paths are queried has changed significantly in Nix 2.4, so
we need to completely refactor nix-query.cc. However, I currently have a
lot of other things to do and the store protocol is compatible so let's
pin Nix to version 2.3 for the sandbox implementation for now.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since I do have a lot of projects where I use rustfmt, it gets pretty
tedious to manually run "cargo fmt". Using g:rustfmt_autosave should
make this less tedious but it might annoy me in the future, let's see.
In addition to setting rustfmt I also added a default path for rustc,
which is used whenever there is no rustc in path. This is because I
usually switch between several projects which use different Rust
versions and this way it will use the rustc version that is in PATH
during "nix develop".
For the rustfmt part I also added a small default configuration which
represents my opinion on how I think Rust code should be formatted. The
file is used whenever a project doesn't have a "rustfmt.toml" or
".rustfmt.toml".
Unfortunately, RustFmt is broken in Vim right now[1], so I'm using the
upstream project until the issue has been resolved.
[1]: https://github.com/rust-lang/rust.vim/issues/446
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
| |
I'm using org mode for these kinds of things now.
|
|
|
|
|
|
| |
If you want to use multiple binaries (e.g. via `pkgs.symlinkJoin`),
this will work via PATH instead of magically tranforming the first
argument instead.
|