<clever>
you could then ssh into the nixos, format the drive, and install nixos as usual
<clever>
seccus: if you unpacked that tar to / and ran /kexec_nixos, then the current OS will improperly shutdown, and nixos will prompt start up, hijacking the entire CPU/RAM
<clever>
so you can just unpack that tar to / on any machine lacking nix, and the bash script just works (that setup will lack nix itself, so there is no easy way to manage the resulting /nix)
<clever>
seccus: and line 39 makes a tarball containing everything that the bash script depends on
<clever>
seccus: lines 12-33 generate a bash script that depends on the kernel&initrd
<clever>
seccus: lines 5-11 take the kernel and initrd from a nixos build, and copy them to a dedicated package (and that initrd contains the whole rootfs)
<clever>
seccus: you can even do insane things like have a bash script that refers to a tarball containing an entire nixos install
<clever>
seccus: yeah
<clever>
seccus: so your script can run any program it wants, without cluttering up what the user has or conflicting with the versions a user already has
<clever>
seccus: and if you do something like: export PATH=${firefox}/bin/:$PATH in the script, then it can just run firefox, but firefox wont be installed for the user
<clever>
pierre__: pkgs.fetchFromGitHub will clone it and return the path its been cloned to
<clever>
jluttine: i also see it in apacheHttpd
<clever>
apacheHttpd.out 22,480 x /nix/store/70pg800wr2gy9fnab0v3xn456sflkl64-apache-httpd-2.4.25/bin/htpasswd
<clever>
phg: it would have to be ran here, and write the cache somewhere under $out, and $out eventualy gets a symlink at /run/current-system/sw/
<clever>
Unode: you may need to nix-channel --update first
<clever>
fpletz: the most broken part, is that the X pinentry stops working the instant i make even 1 ssh session into the machine
<clever>
fpletz: and i always run screen over ssh, and they cant seem to share
<clever>
fpletz: it also tends to ask in a broken way on tty's, and displays a password prompt, but cant actually accept input, so i wind up running my password in bash!
<clever>
fpletz: i found that the gpg module in nixos is rather broken, if i ssh into the machine, that steals control of gpg, then it asks on the wrong tty when i try to make use of the agent
<clever>
Jackneillll: i only see 5.9 on master and staging
<clever>
Jackneillll: clone nixpkgs master and then run "nix-repl ." and try to tab-complete qt
<clever>
hodapp: i cant test it on this end because i lack the library behind the sign-in thing
<clever>
hodapp: have you tried it with: nix-shell -p '(python35Packages.python.withPackages (p: [ p.tensorflowWithCuda ]))'
<clever>
fusion809: you need to actually enable os probber
<clever>
boxofrox: it changed the base for the hash
<clever>
yegortimoshenko: and yeah, there is no way to override values within xfce_self, so your only option is to .override everything you want to impact
<clever>
yegortimoshenko: all of those packages use a new instance of callPackage, and will search within the deps // xfce_self set
<clever>
joko: it just always builds the channel tarball, but only if the tests pass will that be copied to the website
<clever>
joko: nixos handles that with an external script
<clever>
hydra only ever uses nix-build
<clever>
joko: running a command is easy, just pkgs.runCommand, but it will be in a sandbox and cant do too much "fun" stuff, and everything is pure, so it will never know the previous outcome
<clever>
pie_: nix-shell always runs bash on the inner shell
<clever>
so the emulated binaries can make full use of all of the host cores
<clever>
every thread in the guest process, becomes a thread on the host
<clever>
joko: which comes from lines 10&11 on default.nix
<clever>
and then either point the weak arm board at them, or point a hydra at them to pre-build
<clever>
you can turn every spare x86 machine into an arm build slave
<clever>
yeah
<clever>
joko: and then with the right nix.extraConfig, you can convince nix that the machine supports arm binaries (read the patch for the config name)
<clever>
joko: applying that nix override to the nix used by the host (via configuration.nix nix.package) will add support for a new nix.conf flag
<clever>
joko: then the system can just run any arm binary
<clever>
joko: to use the stuff in that github, you need to nix-build the qemu and run the register script in result/bin/
<clever>
joko: more cores and more machines will always help, i believe
<clever>
joko: its somewhat slower then a normal arm machine, but you have more cores, and can throw more x86 machines at it, which can balance out
<clever>
pie_: also keep in mind that setting it to an empty string, and unset have different mechanics
<clever>
pie_: make also has a "feature" where just -j with no number, runs infinite jobs!
<clever>
you might be able to set it before nix-shell is even ran
<clever>
but manually setting it happens after that startup
<clever>
pie_: setup.sh will turn 0 into a number based on your cores, during the startup
<clever>
mbrock: bin is the default output for "${lzma}" because its first
<clever>
joko: so its simpler to always do a "native" arm->arm build, but that could itself be done under emulation
<clever>
joko: the cross-compile stuff in nixpkgs was still a bit wonky last time i looked at it, and doesnt support enough to build a full NixOS, and has more issues down the road when using nix-env
<clever>
sounds like an issue that should be opened on nix
<clever>
i think the problem, is that the cores option is handled by nix-build/nix-daemon, and nix-shell and nix-instantiate arent dealing with it
<clever>
kuznero: which runs ldd, and deletes any rpath entires that appear unused
<clever>
kuznero: in the fixup phase is a call to patchelf --shrink-rpath
<clever>
sphalerite: if you wanted to get the hash over the entire file
<clever>
sphalerite: and random writes to part of the file would require rehashing the entire thing
<clever>
sphalerite: not all filesystems store the hash of the contents
<clever>
sphalerite: while a content-addressed FS doesnt know how long to wait
<clever>
sphalerite: the main difference between a content addressed FS, and auto-optimize, is that nix will wait until the build is done and becoming immutable to hash things
<clever>
sphalerite: yeah, the dedup is increasing the usage
<clever>
wont be a problem if your only working on linux
<clever>
and it always returns 32bit LINUX versions, even if you use pkgsi686Linux on a darwin machine
<clever>
but it returns 32bit linux versions of paths for you to use
<clever>
it wont force the whole system to change
<clever>
so installing something old like skype on darwin, gives you the 32bit linux binaries!
<clever>
only problem with pkgsi686Linux and callPackage_i686, they force 32bit linux, even if used on darwin
<clever>
and callPackage_i686
<clever>
pkgsi686Linux
<clever>
there is also a pkgsi686 atrribute
<clever>
or import the <nixpkgs> { system = "i686-linux"; } variant
<clever>
ah, nix-build if you just want the paths
<clever>
kuznero: nix-env -iA nixos.hello --argstr system i686-linux
<clever>
kuznero: yeah
<clever>
yep
<clever>
systemd has a flag like that, to repair things after pivot_root
<clever>
check the docs to see if a unix signal can make it reopen the socket?
<clever>
that sounds plausible
<clever>
check /proc/PID/fd/ on the other end, to see what its listening on, and also the lsof -p PID output
<clever>
unix socket?
<clever>
strace -ff -o logfiles
<clever>
oh, and strace on curses apps is messy
<clever>
and what its not finding
<clever>
sphalerite: what about stracing tmux, to see how it connects to the daemon
<clever>
screen can still type, but silently looses all output, leaving you blind and thinking it hung
<clever>
that magic symlink even works if the binary was deleted and replaced by an imperative package manager
<clever>
but /proc/PID/exe lets me run the old version
<clever>
sphalerite: ive sometimes seen screen break badly when it gets upgraded
<clever>
sphalerite: the screen client isnt compatible with the screen server
<clever>
yep
<clever>
the map should also be removed
<clever>
so just put this into imports, "${systemd-digitalocean}/module.nix"
<clever>
systemd-digitalocean is a variable pointing to the git clone
<clever>
yeah
<clever>
dhess: your adding this file to the imports list
<clever>
fearlessKim[m]: do you want it to be a read-only empty, or a writable empty?
<clever>
joko: yep
<clever>
joko: so it will rely on the VM system obeying the bootloader config in /boot/, and the guest having the right /boot partition mounted
<clever>
joko: nixops will update /boot/ every time it deploys
<clever>
fearlessKim[m]: /etc/kbd is doing exactly that as well
<clever>
joko: one special thing to keep in mind, is that nixops 100% ignores the remote /etc/nixos/ dir, so your deployment file must configure everything required to make it boot and get internet
<clever>
joko: this tells nixops to ssh into a random netbook, over my VPN, and deploy updates