<clever>
tywkeene: what url is it showing as 404'ing?
<clever>
heh, yeah that works
<clever>
domenkozar: and i dont have the exact url for the luks page memorized
<clever>
domenkozar: though search engines cant index the archive
<clever>
domenkozar: that could work
<clever>
gchristensen: yeah, but having any kind of access to the archive, that new users cant stumble upon, would allow moving the data to better docs
<clever>
last i looked, the zfs and luks pages where still accurate
<clever>
any backup or archive of the wiki that somebody could dig info out of?
<clever>
:)
<clever>
ah
<clever>
simpson: trying to enforce sandboxing outside of the builds sorta?
<clever>
simpson: signing can do the same thing, verify who the sender is, but not hide the content of the message from others
<clever>
gchristensen: are we talking about signing or full encryption of things in the store?
<clever>
Svarog: i think the customized vim is just a vim shell-script that runs the real vim, so everything else in $out/bin/ is missing
<clever>
why is that part of vim!?
<clever>
uhhh, what? lol
<clever>
i'm used to redirects forcing ssl
<clever>
ah
<clever>
yeah, i can load things without ssl
<clever>
i think it just lacks a redirect entirely now
<clever>
domenkozar: yeah, nixUnstable.perl-bindings on nixpkgs master is correct
<clever>
domenkozar: but setting NIX_STORE_DIR in the env hydra runs under should temporarily fix it
<clever>
domenkozar: the default in here is broken: /nix/store/lpa61xrasw7xvv72s46k3zlw26crfvv9-nix-perl-1.12pre5308_2f21d522/lib/perl5/site_perl/5.22.3/x86_64-linux-thread-multi/Nix/Config.pm
<clever>
$storeDir = $ENV{"NIX_STORE_DIR"} || "";
<clever>
domenkozar: yeah
<clever>
domenkozar: the code says the error should contain /nix/store/, but it doesnt!
<clever>
269 gone($c, "Path " . $path . " is no longer available.") unless isValidPath($path);
<clever>
and this works even if you mess with the string via builtins.substring
<clever>
nh2: and if that string winds up as the input to stdenv.mkDerivation, the newly made derivation will "magically" depend on hello being built
<clever>
nh2: so the string "/nix/store/rkvwvi007k7w8lp4cc0n10yhlz5xjfmk-hello-2.10" has some invisible state, that says it depends on the hello derivation
<clever>
or output paths i think
<clever>
nh2: every string in nix, has a list of .drv paths behind it, what that string depends on
<clever>
nh2: have you seen how context works on strings in nix?
<clever>
never touched the stuff :P
<clever>
i saw an open PR for it
<clever>
and why i get horid performance when i do input = ./5gig-file.pdf;
<clever>
which is also why it warns about things over 256mb in size
<clever>
domenkozar: and uses that hash as a string to embed into the .drv
<clever>
domenkozar: it loads the entire path into ram, serializing it into a NAR bytestring, then hashes it, and unpacks it to /nix/store
<clever>
domenkozar: i'm pretty sure nix-instantiate does the copy
<clever>
so it is pure, after the copy is done, and depends on the hash(file contents), rather then what value it happens to have when the build reads it
<clever>
and next time you start a build, it copies it again, and gets a different storepath, which causes all the things depending on it to change paths
<clever>
so if the contents of the file changes mid-way thru a build, it keeps using the old version
<clever>
nh2: "${./foo}" copying files around, is to lock them in at a given value
<clever>
Unode: nix will ignore timestamps when hashing, but .nfs files could probably mess with things
<clever>
so the substring stuff on line 1653 right below, will copy to the store
<clever>
yeah, then just config={}; and it should lock it down
<clever>
from before the PR had been accepted
<clever>
there was a callPackage override in my config.nix, that entirely replaced it
<clever>
i have run into problems before where i was trying to debug a package in nixpkgs, and nothing i changed had any effect
<clever>
domenkozar: depends, setting config={}; will make it a lot more stable and reproducable, but also cause overrides to not work for people that dont notice it
<clever>
bb4kk3r: lib.platforms has a bunch of templates you can use
<clever>
bb4kk3r: meta.platforms
<clever>
domenkozar: the config argument for nixpkgs isnt being set, so this will load ~/.nixpkgs/config.nix and behave differently for every developer
<clever>
dont think thats the area i'm thinking of
<clever>
let me see where that went
<clever>
domenkozar: hmmm, i think we would need to look at how nixos options are generated
<clever>
jophish: then a process like nix-serve wont have read access to the secret key
<clever>
jophish: another extension to the idea i had, is for nix-daemon to sign things at build time, rather then when nix-serve is trying to serve them
<clever>
gchristensen: second, you could verify that paths in /nix/store where signed by cache.nixos.org, without having to re-download things, and exclude 95% of the storepaths that you may want to audit
<clever>
gchristensen: a few things, first, nix-serve/nix-copy-closure would be able to reuse the original cache.nixos.org-1 signatures
<clever>
gchristensen: what do you think of keeping the signatures after downloading from the cache?
<clever>
gchristensen: modifying nix to keep the signatures in the db.sqlite after downloading from the binary cache
<clever>
gchristensen: that reminds me, there is an idea ive been wanting to make a PR for
<clever>
so the lib variant works on older copies of nix as well
<clever>
that calls the builtin for you
<clever>
the one in lib is turned into an if statement
<clever>
but then its later found to be a performance bottleneck, so it gets moved to a builtin
<clever>
ertes-w: some stuff is initialy added in lib, written purely in nix
<clever>
in theory, you could run luksipc from the install cd, mount the luks'd root, then fix the configuration.nix and re-run nixos-install (which is just a script to nixos-rebuild under a chroot)
<clever>
tommyangelo: there is http://johannes-bauer.com/linux/luksipc/ but ive never used it, and getting it to boot afterwards with nixos in the mix may be tricky