| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Small tool which takes a block of nix options that should produce a
script to run, and then calls the script with the rest of argv
e nix-run { -A foobar } a b c
calls `nix-build -A foobar && ./result a b c`.
|
|
|
|
| |
Improvements to filterSourceGitignore were made.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not familiar with the "easy-dhall-nix" project, but the repository
is imported into Vuizvui via import-from-derivation. While this by
itself is not a big issue (apart from contributing hugely to evaluation
time, we're already at around an hour), the "dhall-nix" derivation is in
turn imported again via importDhall, so whenever something breaks with
dhall-nix, our evaluation will break as well.
Unfortunately, something is broken right now:
building '/nix/store/c363947v9qk287d07qj2kpj60rmzwalj-dhall-nix-1.1.14-x86_64-linux.tar.bz2.drv'...
trying https://github.com/dhall-lang/dhall-haskell/releases/download/1.32.0/dhall-nix-1.1.14-x86_64-linux.tar.bz2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 648 100 648 0 0 2592 0 --:--:-- --:--:-- --:--:-- 2581
100 2255k 100 2255k 0 0 1639k 0 0:00:01 0:00:01 --:--:-- 6287k
hash mismatch in fixed-output derivation '/nix/store/yhls1ffnvp1nbjsm0xr3l1z6j6x4waqh-dhall-nix-1.1.14-x86_64-linux.tar.bz2':
wanted: sha256:1j32jf0is0kikfw7h9w3n8ikw70bargr32d1cyasqgmb7s7mvs1c
got: sha256:1qs5p05qfk5xs1ajwyhn27m0bzs96lnlf3b4gnkffajhaq7hiqll
cannot build derivation '/nix/store/aj5ag721b9gm4an6yxh2ljg19ixg4alv-dhall-nix-simple.drv': 1 dependencies couldn't be built
The reason why this happens is because GitHub's tarballs are not
deterministic and whenever GitHub changes something in the way these are
generated, we get a hash mismatch.
For exactly that reason, the fetchFromGitHub wrapper in nixpkgs uses
fetchzip instead of fetchurl, so that file ordering in the archive
doesn't matter.
Unfortunately, the upstream project still uses fetchurl, but since the
URLs and hashes have changed due to a bump to Dhall version 1.33.1, I've
choosen to switch to latest master instead of monkeypatching via
extraPostFetch.
With this bandaid, we shouldn't run into a hash collision until either
the next GC or until the upstream project has switched to either
fetchFromGitHub or fetchzip.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch, @justinwoo
|
| |
|
|
|
|
|
|
|
|
|
| |
I want to be able to open http(s) links that are e.g. images directly
in the right application. Aka web urls should be transparent, instead
of always opening everthing in the browser.
This adds some silly ways of connecting to the server and parsing
out the headers, in order to fetch the content-type.
|
|
|
|
|
|
|
|
| |
It’s a lot simpler to just export the parsed attribute as envvars.
Remove the substitute stuff (it already went into the el_substitute
lib anyway) and replace the xpathexec0 code with the function from the
el_exec lib.
|
|
|
|
|
| |
A small parser for http/https URLs.
Substitutes host/port/path in argv.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
el_exec: wraps the various execve wrappers in skalib that are useful
for writing execline-like utils. currently only `xpathexec0` is
supported, which execs into the argv you give it or errors with the
right error if file not found.
el_substitute: execline argv substitution! Wraps the execline
function, so it will behave exactly the same as the existing execline
utils, like `importas`.
|
|
|
|
|
| |
We can define a more or less complete generator in less than 50 lines
of nix. Nice.
|
| |
|
|
|
|
|
| |
Less generic, has the spirit of “netstrings, but extended to a
structured encoding format”.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Like a normal `import`, but for dhall files. `importDhall2` can
additionally handle dependencies and additional source files, though
the interface is not stable yet.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Filesystem sandbox around zoom-us.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The haskellPackages attribute is actually part of the package scope
inside pkgs.profpatsch and thus the evaluation fails with the following
error:
attribute 'vuizvui' missing, at .../pkgs/profpatsch/default.nix:176:20
Referencing the attribute directly from within the recursive attribute
set fixes the evaluation error and building dhall-flycheck also
succeeds.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch
|
| |
|
|
|
|
|
| |
It’s the easiest way to get recent statically compiled dhall
executables.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This has been upstreamed to nixpkgs proper, as a C wrapper script, in
https://github.com/NixOS/nixpkgs/pull/71357
So we don’t even need bash to run execline anymore :P
|
|
|
|
|
| |
It previously copied nixpkgs to the store, because a `toString` was
missing.
|
| |
|
|
|
|
|
|
|
| |
`runCommandLocal` was added to nixpkgs in
https://github.com/NixOS/nixpkgs/pull/74642
to speed up trivial `runCommand` derivations by always building them
locally. We have a few places where that’s good to use.
|
| |
|
|
|
|
|
|
| |
Small sandboxing utility, which unshares the filesystem via
user-namespaces and can optionally bind-mount existing paths into the
sandbox.
|
| |
|
|
|
|
|
| |
Minimal PoC of a small application which can download and convert a
youtube video with youtube-dl and then serve it via HTTP.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduced in commit e9975c9a39cb4e654d9132de4b952f51174a0926.
The write-execline.nix file is inside the execline/ directory but the
import doesn't reflect that, so since there isn't any write-execline.nix
in other locations, I assume that this is what the author actually
intended.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch
|
|
|
|
|
| |
similar to writeScript, but writes an execline instead. Should be
upstreams to `lib.writers` sometimes.
|
|
|
|
|
| |
A simple way to reference binary paths in an attribute set without
string interpolations everywhere.
|
|
|
|
|
|
|
| |
Earlier, it would just append the execline bin path on every
invocation, which would clobber the path on nested invocations.
We (ab)use the fact that nix paths have a known hash to check whether
it was already added before.
|
|
|
|
|
|
|
|
| |
It’s conventional that these tools have the form
tool name options data
so we should adhere to that.
|
|
|
|
|
| |
We can auto-escape execlines correctly if we model them as nix-style
lists, so we shoud certainly do so. It also helps abstraction.
|
| |
|
| |
|