<clever>
hyphon81: i have also looked into using ipfs as a binary cache, and the issue is how do you map /nix/store/jl72gxms9rg3czv3wj1rskw6n0h3k6gm-hello-2.10 to an IPFS hash?
<clever>
hyphon81: you cant just forward the nixos.org signature and proove it is un-modified
<clever>
hyphon81: one issue right now with running binary caches, is that they have to re-sign the data, and then users need to trust your keypair
<clever>
Svarog: or use nix-store --delete to get rid of something, then copy --from it again
<clever>
Svarog: try finding something you dont have yet
<clever>
yeah, now try using nix-copy-closure --from nix-ssh@server -sign /nix/store/something
<clever>
Svarog: it sounds like those 2 keys are working
<clever>
Svarog: ok, now try ssh nix-ssh@server "nix-store --serve"
<clever>
hyphon81: what else do you want to do with it?
<clever>
nice
<clever>
and then look at the error
<clever>
ssh nix-ssh@server
<clever>
you can test 2 of the keys by just trying to ssh into the box
<clever>
and all parties need to trust the public of the other party
<clever>
and for the sshServe case, the server has 2 keys, and the client has 1 key
<clever>
you will either have 1 (nix-serve over http), 2 (nix-serve over https), or 3 (sshServe over sshd)
<clever>
nope
<clever>
one for the https, and one for the pre-signed data on-disk, that it serves
<clever>
but nix-serve behind an nginx reverse-proxy with https:// may add another keypair into the mix
<clever>
nix-serve just skips the 1st and 2nd pair, and runs purely on the 3rd pair alone
<clever>
the 3rd keypair, is the nix signing keys, the secret must go into nix.extraOptions, secret-key-files on the server, and the public must go into binary-cache-public-keys on the client
<clever>
the 2nd keypair to come into play, is the ssh auth keys (from ssh-keygen, and ~/.ssh/id_rsa), the public must go into nix.sshServe.keys to let you login on sshd
<clever>
the first key to come into play, is the ssh server pair, the public lands in ~/.ssh/known-hosts and this pair prevents mitm (so you dont connect to a fake server)
<clever>
there are 3 different keypairs at play here
<clever>
that is what my last gist does
<clever>
the client also needs some nix PUBLIC keys, to trust what is signed
<clever>
nix.sshServe.keys is the SSH PUBLIC to let them to get in
<clever>
nix.extraConfig = '' secret something''; is the private keys
<clever>
oh wait no
<clever>
you also need to configure the PUBLIC key on the client
<clever>
nix.sshServe.keys is for the PRIVATE key on the server
<clever>
Svarog: either configure it to use sshServe as a binary cache, or copy/paste the list from "echo /nix/store/*/" into the nix-copy-closure commandline
<clever>
Svarog: yeah, if you copy package a, and it depends on b, both a&b will get copied
<clever>
Svarog: i think its NIX_OTHER_STORES
<clever>
joko: you may also need to increase the body size in nginx
<clever>
Svarog: and if you configure nix correctly, it will copy things on-demand
<clever>
Svarog: any built derivation or .drv file, and it will get the entire closure automatically
<clever>
joko: is there a reverse proxy in the mix?
<clever>
thats all it does
<clever>
if you try to download a .nar.bz2, it will literally just pipe "nix-store --dump $foo | bzip2" out the http port
<clever>
and nix-copy-closure already uses that exact command
<clever>
adding attributes like .env wont have any impact on nix-build
<clever>
nix-repl> hello.type
<clever>
"derivation"
<clever>
a derivation is just an attrset with a special type flag
<clever>
steveeJ: does that help?
<clever>
let foo = stdenv.mkDerivation { ... }; bar = stdenv.mkDerivation { something = foo.drvPath; } in foo // { env = bar; }
<clever>
you may need to // it on afterwards
<clever>
steveeJ: it will need to be passthru it not affect the hash of its parent, but it may still trigger recusion, not sure
<clever>
steveeJ: it might be possible to set passthru.env = stdenv.mkDerivation { something = parent_deriv.drvPath; };
<clever>
what are you thinking of?
<clever>
i dont think it is
<clever>
Isorkin: you probably dont need the new nix, that was stuff for sphalerite
<clever>
but if you use the new nix globally, it will keep working
<clever>
sphalerite: its less that it breaks the db, and more that it may be too new to be compatible with the old nix
<clever>
sphalerite: you could also just nix.package = pkgs.nixUnstable in configuration.nix
<clever>
yeah, a vm is also an option
<clever>
sphalerite: if you dont gc after the backup, then restoring will just cause nix to delete anything made after the backup
<clever>
sphalerite: one option, you can just make a backup copy of /nix/var/nix/db/db.sqlite
<clever>
Isorkin: try just using php = mypkgs.php56-libressl.php56; first
<clever>
Isorkin: that may explain why the files you gave me dont make sense with the data you gave me
<clever>
Isorkin: i see you also have 2 different php56 files, pkgs/development/php/default_php56.nix and pkgs/development/php56/default.nix
<clever>
Isorkin: you probably need this in services.nix: php = mypkgs.php56-libressl.php56;
<clever>
Isorkin: yeah, i think i see the problem
<clever>
Isorkin: ok, and what if you run "nix-repl mypkgs/default.nix" then type in php56-libressl, what does it return?
<clever>
johnramsden: i cant see anything obviously wrong, so lets try just appending :${xorg.libxkbfile.out}/lib/ to the rpath
<clever>
johnramsden: what if you run ldd on the file after it has been patched?
<clever>
Isorkin: and also, what is the contents of pkgs/development/php/default_php56.nix?
<clever>
Isorkin: what if you try to nix-build -A php56-libressl mypkgs/default.nix
<clever>
Isorkin: it may help to common out things in the systemPackages list and try "nixos-rebuild dry-run" and try to narrow down which one is the cause
<clever>
Isorkin: something you added to systemPackages is a set
<clever>
Svarog: i had to dig thru the nix source for that
<clever>
Svarog: you will need this entry on the server to allow it to sign things, i believe
<clever>
Svarog: yeah, you can just turn nix-serve off in the configuration.nix
<clever>
Isorkin: the nixos module only allows a single php-fpm package, so you would need to make your own service to run the 2nd php-fpm on a different port/unix socket
<clever>
Svarog: so its just a more locked down user, that allows things like nix-copy-closure and remote nix builds
<clever>
Svarog: sshServe just configures an ssh user to only allow somebody to run nix-store --serve
<clever>
that makes it harder to find mistakes
<clever>
you also dont need ... in the arguments of a package
<clever>
johnramsden: you should generaly also remove the pkgs. on lines 20-36, and add them to the arguments
<clever>
for every value you use, you must receive that as an argument, or create it somewhere nearby
<clever>
johnramsden: if you put ${bash} into an expression, you need to add bash to the arguments on line 1
<clever>
schoppenhauer: and if you let the fixupPhase run, it will trim extras that dont belong automatically
<clever>
gchristensen: same reply the bot gave a month ago
<clever>
nstead of builtins.lessThan x y. The comparison operators also work on strings.’.
<clever>
gchristensen: 2017-01-03 10:33:05< kmicu> gchristensen: ah, that chapter is not updated since 1.6 with ‘Nix now has proper integer arithmetic operators. For instance, you can write x + y instead of builtins.add x y, or x < y i
<clever>
MichaelRaskin: yeah, it would need to also run the built-in tests, if they exist
<clever>
MichaelRaskin: it at least makes it easy to use any haskell package on hackage, without having to package half a dozen deps every week
<clever>
bennofs: yeah, and it will then unpack the tar inside $NIX_BUILD_TOP, creating a 2nd dir, named after the root dir of the tar
<clever>
bennofs: the current dir will usualy be a sub-dir of $NIX_BUILD_TOP, named similiarly to the package, and private to that instance of the build
<clever>
bennofs: id just make it in the current directory
<clever>
infinisil: runCommand could be used to optimize it more
<clever>
IITaudio_: got distracted waiting for the nix-build, 7 steps left, covering 133 commits
<clever>
infinisil: script2 is in the global path, and all it does is run script1 as root via sudo, so script1 has root and doesnt need anything special
<clever>
MichaelRaskin: yeah, for tee its stdin, i was thinking about the echo case
<clever>
infinisil: but then you try to use sudo again inside brightness-up, and you have nothing to force it to be ran with sudo
<clever>
infinisil: you have sudoers configured to allow running brightness-up as root without a password
<clever>
infinisil: oh, i see part of your confusion
<clever>
ah, that could work though
<clever>
MichaelRaskin: ah, but he wants to raise and lower the brightness, so now he needs ~10 entries
<clever>
infinisil: so your back to needing 2 scripts like in my original example
<clever>
infinisil: at which point, an attacker can write to any file in the system
<clever>
infinisil: which is why i mentioned this a while back: sudo "echo foo > /sys/bar"
<clever>
IITaudio_: cleverca22@gmail.com
<clever>
infinisil: i get a bit OCD about knowing how things work, so i just devoured all of the source in nixpkgs and nix
<clever>
lol
<clever>
i have paypal and bitcoin if you want
<clever>
it wont say why nixo works, but it will probably say why the rest are broken
<clever>
which does break on the demo user
<clever>
with one of my basic configs
<clever>
IITaudio_: and now i'm just re-doing build-vm for each commit it picks
<clever>
IITaudio_: https://pastebin.com/pD8Sa5xS i flagged the bad one as bad, then just went back 1000 commits, it worked, so i hit good
<clever>
and theres a bit too much to just go over it all, so i'll give the bisect some more attention
<clever>
probably should just "grep -r import" the whole thing, i found another instance in notmuch
<clever>
and overrides from aother user may take effect in weird places
<clever>
so overrides you apply may not work fully
<clever>
but everything else will obey nixpkgs.config within configuration.nix
<clever>
IITaudio_: another side effect of the way you did it, i3tmp.nix will obey /root/.nixpkgs/config.nix
<clever>
that will reuse the existing nixpkgs and make it build much faster
<clever>
IITaudio_: what you want to do is put { rxvt_unicode, xfce, xdotool }: into i3tmp.nix, and then do pkgs.callPackage ./nixopts/configs/i3tmp.nix {}
<clever>
IITaudio_: i think your loading 8 extra copies of <nixpkgs> here
<clever>
infinisil: and you might as well just allow a shell at that point
<clever>
infinisil: but if you use sudo "echo foo > /sys", you need to allow echo without a password
<clever>
writeScriptBin will put it in bin/ so you can install the "package", while writeScript will just put the script bare in /nix/store, so its easyer to reference from other scripts
<clever>
elasticdog: and if i download the default.nix in the gist, and run nix-shell on it, it does begin downloading things
<clever>
elasticdog: it should just work with the value in the gist
<clever>
nixo_: cant see anything wrong with that, i would expect it to just work
<clever>
elasticdog: you would need a different file if you wanted to use it as an overlay, depend on what your doing, and i also just noticed, you have stdenv in the buildInputs, but thats not required
<clever>
nixo_: how are you enabling i3?, would you be able to switch to another wm for testing?
<clever>
elasticdog: one thing thats probably wrong, your re-importing a 2nd nixpkgs, which just ruins the whole point of overlays
<clever>
infinisil: you can also put "secrets = import ./secrets.nix;" into the let block near the top, and then just have an attrset of more private things
<clever>
infinisil: yeah, i see even less of an issue with domains that are easily found anyways