2018-02-24

<clever> MichaelRaskin: but windows, it cant even handle 20 seconds of outage
<clever> MichaelRaskin: oops, ^
<clever> mfiano: linux can handle minutes of outage
<clever> MichaelRaskin: as long as it gets the same ip, all is good
<clever> mfiano: and the nixpkgs.config is just an opaque attr set, so the documentation doesnt know whats within
<clever> mfiano: a: its nixpkgs.config.allowUnfree, b: its listed under nixpkgs.config
<clever> MichaelRaskin: there is also the interface config, if the wan interface goes down, the iptable rules dont matter
<clever> and `nixops deploy` passes!
<clever> MichaelRaskin: as long as the new rules are compatible
<clever> MichaelRaskin: yep, and that happens all the time when i adjust rules and nixos-rebuild switch
<clever> gchristensen: oh, and there are un-spoken horrors in this machine, its running 16.03
<clever> gchristensen: now to give nixops actual control...
<clever> gchristensen: basically, i used nix-diff to compare a `deploy --build-only` drv against the old drv, and synced the config up
<clever> gchristensen: it restarted hydra, dbus, and polkit, the firewall service hasnt even changed, lo
<clever> gchristensen: pulling the switch....
<clever> thats a good sign
<clever> copying 19 missing paths (11.30 MiB) to ‘root@router’...
<clever> [clever@system76:~/nixops]$ nix-copy-closure --to root@router /nix/store/7mwnv7fqa7y89mpqris876nxc05v26vk-nixos-system-router-16.03pre76756.885acea
<clever> gchristensen: ok, now comes the fun part, i am attempting to switch my router from plain nixos, to nixops, without changing anything
<clever> MichaelRaskin: i already have expressions that can basically spread nixos within a LAN like a virus
<clever> MichaelRaskin: you will be assimilated
<clever> lol
<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> eacameron: one min
<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> samueldr: this is a haskell parser for NAR streams: https://github.com/taktoa/narfuse/blob/master/Main.hs#L201-L214
<clever> samueldr: also, do you have any haskell involved?
<clever> samueldr: you could download the nar, extract the share/man dir, then delete the rest
<clever> yeah
<clever> ixxie: nix tends to break if the thing your pointing to changes
<clever> try it with --list-generations as well
<clever> that just tells nix-env which profile to operate on, so you still need an operation like --rollback
<clever> day|flip: or nix-env -p /nix/var/nix/profiles/system
<clever> day|flip: those are nixos generations, you need to use nixos-rebuild rollback
<clever> and then the python module, that links to the 1st, and the right python version
<clever> and maybe split it into 2, the c library that doesnt care about python
<clever> catern: i think it would have to be under pythonPackages, so it can properly deal with the python2 vs python3 stuff
<clever> samueldr: some binary caches have it set to false
<clever> samueldr: thats what the want-mass-query field in `curl https://cache.nixos.org/nix-cache-info` tells you
<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: then query https://cache.nixos.org/HASH1.narinfo
<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> cmacrae: one min
<clever> is missing the output i added
<clever> Fare: oh, another one i wrote, one sec
<clever> Fare: maybe the systemd package?
<clever> nix-repl> systemd.outputs
<clever> [ "out" "lib" "man" "dev" ]
<clever> Fare: hello lacks libraries and headers, so it cant really make use of this feature
<clever> simpson: yeah, id change that to just be an alias for zlib.static
<clever> Fare: and nix can garbage collect, or not even download, the outputs you dont need
<clever> Fare: "${foo}" is the first output (dev in this case), "${foo.dev}" and "${foo.out}" refer to a specific output
<clever> Fare: you can then do derivation.dev and derivation.out to get paths to them
<clever> Fare: nix will then define $dev and $out to point to paths, and the derivation must create and populate those paths
<clever> Fare: basically, any derivation can define an outputs attribute, which is a list of strings, like outputs = [ "dev" "out" ];
<clever> MichaelRaskin: thats not proper multi-output
<clever> 11721 zlibStatic = lowPrio (appendToName "static" (callPackage ../development/libraries/zlib {
<clever> Fare: check the .outputs attribute of random things in nix-repl
<clever> MichaelRaskin: good point, lol
<clever> "/nix/store/7rk6ik1vxh2rvg3ny0rk6kkfdiqzbz5w-nixos-18.03pre125026.f607771d0f5/nixos/pkgs/development/libraries/glibc/default.nix:100"
<clever> nix-repl> glibc.meta.position
<clever> [ "out" "bin" "dev" "static" "debug" ]
<clever> nix-repl> glibc.outputs
<clever> Fare: glibc is a good one
<clever> Fare: let me see..
<clever> Fare: then you can refer to each output as an attribute on the resulting object
<clever> Fare: just set outputs = [ "dev" "lib" "out" "static" ]; and then copy things to $dev, $lib, $out, and $static
<clever> Fare: what you really want, is a derivation that makes static, dynamic, headers, and bin, all at once
<clever> Fare: i dont think makeStaticLibraries does what i said, i think it forces static-only
<clever> Fare: seperate, so it can just be ignored by users not wanting it
<clever> Fare: when adding them, try to add a static output, and put them in $static/lib/
<clever> Fare: pretty sure its manual
<clever> so just let nix take over :P
<clever> and then it becomes a pain in the ass to manage imperatively installed plugins
<clever> simpson: but they also have to be patched to find their deps in the store
<clever> robstr: mkdir fake-home ; export HOME=$(realpath fake-home), try adding this somewhere like preConfigure
<clever> robstr: do you care about anything its writing to $HOME?
<clever> robstr: nix builds arent supposed to store any state in $HOME
<clever> catern: but it might break the program, because the library init functions run much sooner then the code expects
<clever> catern: and also make the rpath simpler
<clever> yeah
<clever> catern: and just fell back to LD_LIBRARY_PATH
<clever> catern: the people who packaged them didnt know about shrink-rpath breaking things
<clever> and since patchelf is in the stdenv, that always gets sourced when things start up in the stdenv
<clever> catern: this is the script responsible for the shrink
<clever> genesis: ah, nope
<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
<clever> i'm not that good at writing docs
<clever> all of the docs are on github
<clever> ah, just fork nixpkgs, and edit it, then file a PR
<clever> yeah, that one looks best
<clever> the stub almost never requires an update
<clever> ive been anoyyed at the lack of a safe option as well, and i tend to just change it to "nodev" once its booting
<clever> lrwxrwxrwx 1 root root 9 Feb 13 05:54 /dev/disk/by-path/pci-0000:00:11.0-ata-1 -> ../../sda
<clever> nixer101: try by-path?
<clever> it has to be aimed at the root of the drive, like sda (or a symlink that points to sda)
<clever> boot.loader.grub.device most not be set to a partition
<clever> that will load it in
<clever> tnks: you can also :l <nixpkgs> after launching the repl
<clever> tnks: yeah, i think nix search replaces nox
<clever> i type that almost daily
<clever> tnks: nix-repl '<nixpkgs>'
<clever> day|flip: nox, nix-repl and tab completion
<clever> tnks: only been using it for about a week now, but havent noticed anything that major
<clever> tnks: i already use nixUnstable on my laptop, since before it was "released"
<clever> same
<clever> modify nixpkgs.nix to be 2.0
<clever> tnks: i believe 1.11.16 is compatible, so you can switch back
<clever> tnks: what about nixpkgs.nixUnstable?
<clever> step 2, dont disconnect from irc
<clever> step 1, wait for somebody to notice your question
<clever> yorick: the values within the a set wont be eval'ed, so it will still be mostly lazy
<clever> yorick: a set is basically just a list of key=value pairs, and it must know every key
<clever> yorick: i believe it has to partially eval a, to key the names of every key
<clever> ive only use nix-build and `nix repl` on 2.0 so far
<clever> maybe
<clever> jtojnar: ah, dont know then, maybe <nixpkgs> from NIX_PATH?
<clever> jtojnar: i'm guessing its the channel name from ~/.nix-defexpr/, same as nix-env
<clever> yorick: inside runCommand
<clever> yorick: you might even be able to just symlink $out to the path
<clever> taohansen: nix expects you to give a rev, not a branch, and that the versions of things dont change very often
<clever> Unode: if condition then a else (if condition2 then b else c)
<clever> nixops also has its own option to keep rollbacks at the deployment server
<clever> that root each version that has been deployed
<clever> but there are generations on the remote machine
<clever> so normal GC can eat it
<clever> by default, it doesnt root anything
<clever> did you GC your git repo?
<clever> that as well
<clever> lejonet: and reminds me, the nixos name tells you exactly which rev you want
<clever> lejonet: ah, that also helps
<clever> then see if you get the right drv by chance
<clever> lejonet: so you could try to nix-instantiate -A dhcpcd, against the nixos in each generation
<clever> lejonet: luckily, nix also keeps all copies of nixpkgs, in /nix/var/nix/profiles/per-user/root/channels*
<clever> lejonet: only way to get it back, is to nix-instantiate the old version from nixpkgs
<clever> lejonet: its possible that you just GC'd the .drv file that originally made it
<clever> lejonet: nix-store --query --deriver
<clever> just re-run whatever command you wanted to run
<clever> until the hash is right
<clever> so it will just re-download it every time
<clever> nix refuses to mark it as valid when the hash is wrong
<clever> no more captive portals
<clever> the last uni i visited had proper wpa auth, where every person had a unique name&pw, that went into the wpa config
<clever> you may need to tether then, to install something that can render the anoying login page
<clever> ah
<clever> systemctl start display-manager
<clever> i think it includes a gui browser
<clever> is lynx or links installed?, are you on the graphical iso?
<clever> but i assumed you had working internet, since you where on irc
<clever> thats what my first guess was, lol
<clever> login page?
<clever> 404?
<clever> what do the contents look like?
<clever> try running `less` on it
<clever> tab-completion will help a lot with that step
<clever> if you run ls -lh on that path, how big is the file?
<clever> on what url?
<clever> dimensionless: it should also give a full error log
<clever> lejonet: use this to compare the 2 dhcpcd's
<clever> lejonet: one of its dependencies changes then, one sec
<clever> sphalerite_: lol
<clever> it will list every root that depends on the given path
<clever> lejonet: you gave it a storepath, and it printed nothing?

2018-02-23

<clever> lejonet: a lot of commands do that
<clever> ive memorized far too much of the nix source, lol
<clever> lejonet: nix-store --query --roots
<clever> TonyTheLion: it should automatically give you the dev version when you put openssl into the buildInputs
<clever> pingveno: the full storepath for the oracle thing, which was probably printed when you ran nix-store --add-fixed
<clever> pingveno: i believe thats the right syntax to add a root
<clever> pingveno: nix-store -r /nix/store/foo --add-root rootname --indirect
<clever> yep
<clever> ah, yeah
<clever> aminb: and replace ${mirror} with mirror://kde
<clever> aminb: grab the src= for user-manager from here, and insert it into your user-manager.nix
<clever> aminb: i looked closer at the plasma stuff, and it deals with srcs in a bit of an odd way
<clever> aminb: oops, pkgs.plasma5.callPackage
<clever> aminb: and the you should be able to use pkgs.user-manager within configuration.nix
<clever> aminb: nixpkgs.config.packageOverrides = pkgs: { user-manager = plasma5.callPackage ./user-manager.nix {}; };
<clever> aminb: save a copy of user-manager.nix to your local system, then add this to configuration.nix
<clever> aminb: download its default.nix and add it as a package override
<clever> LnL: manualy test the 3 commits around it (one below, 2 above)
<clever> LnL: the problem might be caused by the combination of 2 other commits?, or a sloppy merge conflict fix?
<clever> M-bbigras: overlays
<clever> nodePackages_4_x nodePackages_8_x node_webkit_0_11 nodejs nodejs-6_x nodejs-9_x nodejs-slim-4_x nodejs-slim-8_x
<clever> brachiel: node<tab><tab> in nix-repl
<clever> brachiel: i generally just tab-complete things inside `nix-repl '<nixpkgs>'`
<clever> M-bbigras: this
<clever> 2018-02-23 15:46:46 < LnL> like this? :) https://gist.github.com/LnL7/570349866bb69467d0caf5cb175faa74
<clever> extra wobbly
<clever> gchristensen: my router is meant to be on a rack, but its on a set of plastic shelving units, lol
<clever> gchristensen: i put most of that kind of hardware in the spare bedroom
<clever> i need to try those in my NAS, its been performing pretty poorly
<clever> gchristensen: i found a pair of 8gig sticks, still in their original packaging
<clever> then it should just be working fine
<clever> elvishjerricco: and does the host also have at least 8gig?