<clever>
__monty__: how are you running zsh for testing?
<clever>
__monty__: are you using startx?
<clever>
__monty__: and when you started zsh, it appended an entry
<clever>
__monty__: then NIX_PATH had already been set, before you ran zsh
<clever>
which is the same mechanic as nix-env -iA
<clever>
achambe: nix-shell only accepts the attribute path, not the .name
<clever>
unset and set to empty behave very differently
<clever>
run bash first then
<clever>
__monty__: unset NIX_PATH ; zsh then echo $NIX_PATH
<clever>
__monty__: unset
<clever>
__monty__: what if you manualy clear NIX_PATH, then just run zsh normally, what is the end-result?
<clever>
if nix_path was empty, it would become NIX_PATH=:nixpkgs=...
<clever>
__monty__: if it doesnt have a value, it just sets it
<clever>
__monty__: if nix_path has a value, it will append to it with a : as a separator
<clever>
__monty__: add an echo to both bashprofile and zshrc
<clever>
try clearing NIX_PATH, then manually source it once, and echo
<clever>
__monty__: it sounds like your sourcing the script twice
2017-11-02
<clever>
kkini: so every single time you eval the nix, it has to redownload the source (with a 1h cache)
<clever>
kkini: builtins.fetchurl happens at eval time, before it computes $out
<clever>
the one under pkgs needs a hash
<clever>
kkini: builtins.fetchurl will re-download every hour
<clever>
my irc client only alerts me if my name is at the start of a msg
<clever>
oh, lol
<clever>
cement: ?
2017-11-01
<clever>
bbl
<clever>
universalpackage: most things use LD_LIBRARY_PATH to do that
<clever>
universalpackage: why?
<clever>
universalpackage: what are you trying to do?
<clever>
universalpackage: are you using the nixpkgs gcc or the host gcc?
<clever>
universalpackage: what about -L. -lc ?
<clever>
universalpackage: try -l./libc-2.25.so?
<clever>
ldlework: the nix install script on darwin asks if you want single or multi-user when you run it
2017-10-31
<clever>
ldlework: you may need to unset NIX_REMOTE and ensure the nix-daemon has stopped
<clever>
then you need to manually configure linux build slaves
<clever>
so the automation just gives up and shuts off
<clever>
but if nix-daemon is in use, it has to be setup in /etc/nix/machines, and only root can write to that
<clever>
ldlework: so nixops can auto-configure nix-build to use the target machine as a build slave
<clever>
ldlework: if nix is running without nix-daemon, then the env variables of the nix-build process control the build slaves
<clever>
and nixops can only do its automation if NIX_REMOTE is unset, which requires +w to /nix/store/
<clever>
ldlework: as long as you have +w to the store, it will work without the daemon, so you just have to stop the daemon from making root-only things
<clever>
ldlework: i think you could do it by, stopping the nix-daemon service from running, and chown -R /nix/store
<clever>
c: reinstall nix in single-user mode
<clever>
b: run nixops as root on darwin with NIX_REMOTE unset
<clever>
a: manualy add a linux slave to /etc/nix/machines
<clever>
ldlework: so you need to either
<clever>
ldlework: the multi-user install breaks the code in nixops that deals with that automatically
2017-10-27
<clever>
yeah
<clever>
Dezgeg: then how did the emacs one get symlinked?
<clever>
unknown
<clever>
ldlework: and ls that
<clever>
ldlework: check the nix-build output and find the path for hammerspoon, when it re-built it with the new script
<clever>
ldlework: but only 1 thing provides Applications, so the whole thing is linked
<clever>
ldlework: so buildenv has to make a bin directory, then symlink each item within
<clever>
ldlework: in the case of bin, lib, and share, there are multiple things providing those directories
<clever>
ldlework: thats just how buildEnv works, let me see
<clever>
ldlework: just use runCommand, not builder
<clever>
nix-serve is dynamic, and will look in /nix/store/ for every request, and generate the NAR on the fly
<clever>
nix-push will generate nar's of the given paths, and make a directory suitable for a static website, just upload it anywhere
<clever>
kiloreux_: it will dynamicaly generate the NAR on-demand, compressing up the storepaths your using normally
<clever>
kiloreux_: nix-serve just serves everything in /nix/store/
<clever>
and several others
<clever>
it is a bit confusing, there is also a writeTextFile, with a different api
<clever>
its writeText
<clever>
if you could provide a staticly linked shell, and you put that builder in a normal file and did ./builder.sh, this derivation can run entirely without nixpkgs
<clever>
but the derivation itself, makes no use of the stdenv
<clever>
this uses some of nixpkgs to setup the derivation
<clever>
infinisil: and it has variants line writeScript (+x's the file) and writeScriptBin (puts it in $out/bin/), that have the same API
<clever>
ldlework: writeText accepts 2 strings, a name, and the text to be written
<clever>
ldlework: but writeText can do files within $out, it can +x things, and it can depend on things
<clever>
ldlework: writeText is just a wrapper around "echo ${foo} > $out", so it runs in a sandbox, and the $out hash depends on what build of echo you use
<clever>
ldlework: toFile cant have any dependencies, and it works at a nix level during the eval so its platform independant
<clever>
ldlework: pkgs.writeText
<clever>
then it will be less confusing
<clever>
ldlework: you can add a name = "..."; attribute inside fetchzip, to rename what it will unpack to
<clever>
ldlework: ah, so its a directory that ends in .zip?
<clever>
ldlework: is it actually a zip?
<clever>
ldlework: run ls -l on that path
<clever>
you just run it on a file you want to find
<clever>
ncurses5.out 0 s /nix/store/28bbln4vwh7jhfiq4nbmv4dq12d9gl05-ncurses-5.9/lib/libncursesw.so.5
<clever>
riclima: -p will dynamicaly generate a derivation, in the form of
<clever>
the nixos and nixpkgs manuals
<clever>
so half of the nixos-rebuild job is done on a central box
<clever>
then just activate the pre-built nixos
<clever>
and then copy it over with nix-copy-closure
<clever>
it will build it on the machine running nixops
<clever>
and they need a unique ip within the VPN
<clever>
gutsoo: but there is pre-existing differences in the filesystem layout, that i havent bothered to fix yet, so i encoded that in the deployment.nix
<clever>
gutsoo: in the example i linked, eeepc.nix contains the common setup between 2 netbooks, so i can just grab whichever has a charged battery
<clever>
TweyII: stdenv.mkDerivation will unpack it at the unpackPhase, so if its the source for your own thing, you can just refer to it in the local directory
<clever>
this one is for bios boot, which you only need if you want to boot with legacy