<clever>
i probably should get it setup sometime soon
<clever>
just never really bothered to ask for it
<clever>
MichaelRaskin: mostly just procrastinating so i didnt have to deal with a small documentation change :P
<clever>
eacameron: you could also run the 2nd sshd on a different port, and convince nix-copy-closure to use that port
<clever>
eacameron: and the flags arent documented as well
<clever>
eacameron: only with nix 2.0
<clever>
mfiano: that info is also in `man configuration.nix`
<clever>
eacameron: youll see one is listening on 22, kill that one
<clever>
eacameron: netstat -anp | grep sshd
<clever>
eacameron: ps -eH x, youll see one sshd is the parent of your shells, that one is important
<clever>
and other things
<clever>
eacameron: it depends on things the machine wont have, like the IP's of other machines in the clusters
<clever>
eacameron: all it pushes out is finished builds
<clever>
eacameron: nope, the config never leaves the central machine
<clever>
eacameron: and then run /nix/store/HASH-name/bin/switch-to-configuration boot, inside the chroot, to update the grub config, so the build runs on bootup
<clever>
eacameron: then use nix-copy-closure to push it over manually
<clever>
eacameron: once you have an sshd running inside the chroot, fix the deployment file, and `nixops deploy --build-only` to build the fix
<clever>
eacameron: of course, so you can always try again
<clever>
eacameron: and whatever you do, dont close that ssh, it will be difficult to re-open :P
<clever>
eacameron: then carefully kill the main sshd in the recovery (without killing the sshd your using), and start the nixos sshd inside the chroot
<clever>
eacameron: ok, now read /nix/var/nix/profiles/system/etc/systemd/system/sshd.service to find the args for launching sshd
<clever>
eacameron: does that give you a shell?
<clever>
eacameron: hmmm, first, lets get the chroot up, mount the rootfs and nix store to /mnt/ and then: cd /mnt ; chroot . bin/bash
<clever>
eacameron: ah, nixops complicates it a lot more
<clever>
eacameron: lol
<clever>
eacameron: if you can chroot into the install, add this module, and nixos-rebuild boot, it should be updated enough to fix itself
<clever>
ixxie: can you gist what youve changed and what you ran?
<clever>
ixxie: make an override that sets src = /home/clever/foo;
<clever>
sudoreboot[m]: yeah, src = ./.; will do things like that
<clever>
and the smaller is the .nar.xz
<clever>
yeah, the bigger is the raw nar
<clever>
NarSize: 10201352
<clever>
FileSize: 1890808
<clever>
samueldr: oh, the narinfo also reports the compressed and uncompressed size
<clever>
sudoreboot[m]: add "ls -lhd . openvr" to the preConfigure, and then look at the permissions
<clever>
so it never saves the junk to disk
<clever>
samueldr: but this would allow you to downloat the nar, uncompress it, stream it thru the parser, and just filter out the paths you dont care about
<clever>
samueldr: its compressed, so seeking isnt useful
<clever>
chisui: nixos-rebuild doesnt delete the garbage until it has finished copying in the new files
<clever>
chisui: yeah, you need to manually delete one or 2 initrd's
<clever>
yeah
<clever>
samueldr: but if you call toString on it, you can get a totally different string out of it
<clever>
samueldr: if you try to treat certain things as a string (deriations, paths, and special attrsets), it will automatically turn into a string for you
<clever>
samueldr: toString foo and "${foo}" behave very differently
<clever>
gchristensen: i think its something along the lines of download all the docs!
<clever>
no need to manually hash things
<clever>
samueldr: "${hello}" gives you the path
<clever>
so each output within a single drv, has a unique hash
<clever>
or "man" + serailize...
<clever>
which is basically the result of hash("out" + serialized_drv)
<clever>
yeah, the hash from its output path
<clever>
samueldr: download that file, uncompress, and pipe it into `nix-store --restore HASH1-foo`, and it will create a HASH1-foo in the current directory
<clever>
samueldr: you will see a URL field in there
<clever>
samueldr: take the hash from /nix/store/HASH1-foo
<clever>
samueldr: easily
<clever>
i tend to make mine 500mb to 1gig
<clever>
chisui: what about df -h /boot/
<clever>
samueldr: not all packages use split outputs fully
<clever>
samueldr: if the man pages are in the .man output, and it depends on nothing, then you can cheaply download just all the .man's
<clever>
samueldr: thats where split outputs come in handy
<clever>
samueldr: s/just/nix/
<clever>
samueldr: just refuses to allow a storepath to exist without its dependencies
<clever>
chisui_: what does "df -h /" and "df -i /" report?
<clever>
chisui_: it should work with the open source amd drivers as well
<clever>
chisui_: looks like the package is broken
<clever>
yep
<clever>
cmacrae: as always, nix-build creates a result symlink pointing to the result
<clever>
chisui_: did you nixos-rebuild switch?
<clever>
cmacrae: this generates a tarball with a /kexec_nixos symlink pointing to the storepath of the kexec_script, and also includes that script, and the rest of its closure
<clever>
catern: either disable the shrink and be careful with closure size, or re-add the dlopen entry after the shrink
<clever>
catern: carefull rpath'ing would be best
<clever>
catern: so you have to use LD_LIBRARY_PATH or careful rpath'ing to ensure its in the search scope
<clever>
catern: but its not aware of dlopen based things, and breaks it
<clever>
catern: the stdenv runs patchelf --shrink-rpath, which basicaly checks ldd, and removes rpath entries you "dont need"
<clever>
catern: you can also use rpath, but you have to be careful
<clever>
i believe dlopen is also smart enough to find an already loaded library and return the existing handle
<clever>
if i forcibly inject a binary it will later dlopen()
<clever>
catern: patchelf can manipulate the DT_NEEDED field of an elf file...
<clever>
catern: that gives me an idea....
<clever>
lejonet: except, chromium/electron dlopen()'s a crap-ton of things on startup, including udev and opengl
<clever>
and re-running it did nothing
<clever>
and they unknownly fixed the proble, while trying to fix that bash script
<clever>
turns out, the bash script wasnt magic, installing curl was the solution :P
<clever>
i refused to accept that answer, and dug deeper
<clever>
after a lot of googling, i found many confused people, that discovered using the bash script as-is magically fixed the problem
<clever>
and firefox would promptly segfault
<clever>
so, i used wget
<clever>
catern: then i wanted flash, and the install script was just a dumb curl -> ~/.something/
<clever>
and firefox could be compiled without curl support (it removed error reporting)
<clever>
i was on gentoo, and had always used wget, so i made a point of purging curl from the system, lol
<clever>
catern: that reminds me of a fun problem i had with flash years ago
<clever>
nixy: let localpkgs = import /home/clever/apps/nixpkgs {}; in { ...
<clever>
robstr: ive noticed a lot of fixed-output derivations just disable certificate checking, since the hash of the product is checked anyways
<clever>
akr: what if you run "ldd /bin/bash", what does it report?
<clever>
hask_bee_3: its a mix of symlinks and hard-coding paths into binaries
<clever>
you still need a tar of the nix store to start using nix-user-chroot, i think
<clever>
maybe tomorrow i could try throwing something together where it will persist the store long-term, to fix that "i dont have root" issue forever, lol
<clever>
ive been messing with nix-bundle lately, and its namespacing stuff is pretty handy
<clever>
ah
<clever>
if your already using proot to fake the root
<clever>
that might be simpler then getting the redhat /bin/sh to work
<clever>
nixos symlinks /bin/sh to ${bash}/bin/sh, and then ensures the closure of bash is in scope
<clever>
nixer101: it only takes a minute or 2 to register on github, and i dont have push access