2018-05-07

<clever> timestamp on that file?
<clever> jD91mZM2: is xorg actually working?
<clever> jD91mZM2: you need to check the logs for Xorg to see which drivers it used: sudo journalctl -u display-manager -b 0
<clever> jD91mZM2: the vesa drivers will be available even if your not using them
<clever> jD91mZM2: nix-store -qR /run/current-system | grep packagename
<clever> warnings can usually be ignored
<clever> or is it another warning?
<clever> is it actually having an error?
<clever> your already root
<clever> you dont need sudo on that 2nd one
<clever> and your user hasnt used nix-channel
<clever> its probably just using the NIX_PATH from your normal user when ran directly with sudo
<clever> Izorkin: looks entirely normal, what if you do `sudo -i` then `nixos-rebuild switch` ?
<clever> Izorkin: sudo ls -lah /root/.nix-defexpr/channels/
<clever> also, that was not an error either, that was another warning
<clever> Izorkin: what does nix-channel --list say when ran as root?
<clever> Izorkin: what was the error?
<clever> nix should also normally setup that dir on the first login
<clever> Izorkin: thats a warning, and it happens if you have never ran nix-channel
<clever> you could also set the sha256 directly, if you add another larger nix file into the mix, but then <nixpkgs> entries in nixpkgs (which is a bug) would fail
<clever> so if 2 URL's give binary-identical .tar.gz files, it can reuse the -unpacked variant
<clever> which is based on a hash of the .tar.gz the url gave
<clever> and if things are unpacked, there is also a hvm7h0ydc68hqa9x5657f5h8lh8437cr-4975378b2139f24b1368f44e9e3d44e34c3e48ad.tar.gz-unpacked symlink
<clever> and based on the metadata in the .info, it will know how old the -file is, and if it should check again, and what cache-control magic is at play
<clever> 0lmg3b0f50wmfbh3fgbfz80g2lhzjy04cps1mm2ziyxmafkiqlmp.info and 0lmg3b0f50wmfbh3fgbfz80g2lhzjy04cps1mm2ziyxmafkiqlmp-file are based on a hash of the URL, and contain metadata on it
<clever> achambe: nix uses this directory to cache the results of fetching such things
<clever> [clever@amd-nixos:~]$ ls -ltrh ~/.cache/nix/tarballs/
<clever> achambe: but as long as github isnt cheating, it will return the exact same thing every time
<clever> achambe: when using a URL like that, it is technically impure, nix will check for updates if it has been over an hour since you last used it
<clever> -I nixpkgs=https://github.com/nixos/nixpkgs/archive/${gitrev}.tar.gz
<clever> but you coudl give it a url including a git rev
<clever> yeah
<clever> NIX_PATH= nixos-rebuild build -I nixos-config=./configuration.nix -I nixpkgs=/home/clever/apps/nixpkgs
<clever> as a way of doing things in a more pure manner
<clever> so only configuration.nix and nixpkgs themselves are loaded from NIX_PATH
<clever> those values must instead be defined in the configuration.nix
<clever> achambe: of note, nixos already forces nixpkgs to use nixpkgs.config and nixpkgs.overlays for the config and overlays, so the users config.nix and overlays wont apply
<clever> hmmm, actually, where is the xmonad binary?, it doesnt exactly obey nix generations
<clever> you can also manually run the older xmonad without rebooting
<clever> jD91mZM2: what happens if you restart xmonad after turning on the monitor?
<clever> jD91mZM2: i'm guessing that xmonad isnt aware of the screen changing size?
<clever> > pkgs.pkgs.pkgs.pkgs.pkgs
<clever> > pkgs.pkgs.pkgs.pkgs.pkgs
<clever> so it needs to know the attribute names for every config value, before it can compute pkgs
<clever> and the pkgs and lib args for all modules depends on config._modules.args
<clever> and an mkIf would isolate it some
<clever> though config can depend on options
<clever> i suspect that imports cant depend on options either
<clever> johnw: hydra does support building PR's and posting status to github
<clever> johnw: and hydra does the same job as travis, so why even use travis at that point?
<clever> johnw: you have to manually configure nix.conf to use a hydra server you have building it elsewhere
<clever> then it will be in PATH for you
<clever> iqubic: systemd.services.foo.path = [ pkgs.git ];
<clever> iqubic: there is a .path option on the service itself
<clever> tnks: what happens if you dont use -i?
<clever> id say its a typo in cabal2nix
<clever> or cabal2nix is refering to something that never existed
<clever> it might be in nix-prefetch-scripts
<clever> mightybyte: you need to provide nix-prefetch-zip in $PATH before you run cabal2nix
<clever> so it fails, rather then silently using the wrong nixpkgs
<clever> thats also why i always test things like this after `unset NIX_PATH`
<clever> that makes it fairly difficult to pin the nixpkgs version
<clever> yeah, i would also call that a bug
<clever> and wrap it with ( and ) because it was in a list
<clever> you want nixPkgs + "/nixos/modules/virtualisation/google-compute-image.nix"
<clever> achambe: it uses the pinned nixpkgs for everything, except google-compute-image.nix
<clever> achambe: oh wait, slight correction
<clever> achambe: that should use the pinned copy
<clever> the same way
<clever> iqubic: cd will normally go into $HOME if you dont give it a path
<clever> yeah
<clever> nix will preserve the newlines
<clever> /home/clever/foo.nix expects it in my home
<clever> ../foo.nix expects it one dir up
<clever> imports = [ ./foo.nix ]; expects it in the current dir
<clever> put that file into imports
<clever> iqubic: that looks good at a glance
<clever> and you need to delete the generation first with a nix-env command
<clever> some paths may still be in use by other generations, ignore the warning when it complains about those
<clever> sir_guy_carleton: run nix-store -qR on the system profile, and then run nix-store --delete on each path in it
<clever> concatime: you give ia a yarn.lock and a package.json, and it does everything for you
<clever> concatime: you want to use yarn2nix
<clever> concatime: why does it need access to the internet?
<clever> zybell: at that point, you might as well just make a bash while true; loop, and sleep 3600 inside it
<clever> nix1 didnt have a seperate fetchTarball originally
<clever> oh, the default actions may have changed between nix1 and nix2
<clever> so import is trying to parse the .gz
<clever> fetchurl doesnt unpack it
<clever> jtojnar: you want fetchTarball
<clever> and confusingly, a rollback would put you back on 45
<clever> so the rebuild would switch you from 44 to 46
<clever> yeah
<clever> and also the current nixpkgs
<clever> which will upgrade things again
<clever> sir_guy_carleton: it would build a new one based on the current configuration.nix
<clever> codygman: make it fixed-output, by telling nix what the hash of the result is
<clever> codygman: you need to use .overrideAttrs
<clever> which is why i mentioned needing 2 service entries
<clever> maybe
<clever> that tells systemd that it exits when its done "starting", and is then "running" without any process open
<clever> .serviceConfig.Type = "oneshot";

2018-05-06

<clever> oh, and systemd expects the service to stay running, so if your script returns, systemd will try to restart it
<clever> it needs display-manager.serice and wantedBy = [ "multi-user.target" ]; also
<clever> i think before + wantedby will run it before X, and you can optionaly also use startat to run it at intervals
<clever> https://nixos.org/nixos/options.html#systemd.services.%3Cname%3E.wantedby
<clever> https://nixos.org/nixos/options.html#systemd.services.%3Cname%3E.before
<clever> iqubic: https://nixos.org/nixos/options.html#systemd.services.%3Cname%3E.startat
<clever> iqubic: one min
<clever> iqubic: nixos also has an option to define timer flags on the service alone
<clever> iqubic: having it in multi-user.target and flagged as before display-manager should do it
<clever> src*
<clever> codygman: you need to override both name and rc
<clever> only things that are part of multi-user.target are ran on bootup
<clever> ive not tried that specific combination before
<clever> you also need to make it part of multi-user.target, the same as anything else that runs on bootup
<clever> you can try that, but i'm not sure what systemd will do
<clever> and then both of them run the same cmd
<clever> only thing i can think of is to have a second service with before=["display-manager.service"] on it
<clever> iqubic: this is an example of how to run something hourly
<clever> iqubic: what do you want to do with the timer?
<clever> codygman: the package is called chromedriver, not chromeDriver, thats why nix cant find it
<clever> apps/nixpkgs/pkgs/top-level/all-packages.nix: chromedriver = callPackage ../development/tools/selenium/chromedriver { gconf = gnome2.GConf; };
<clever> codygman: where should chromeDriver come from?
<clever> cryp2nomicon: gcc will often re-order things, so with smaller code blocks, it can be pretty unpredictable
<clever> though that doesnt work in my setup, because i use screen heavily
<clever> then it will cause the local gpg instance to ask
<clever> elvishjerricco: if you instead use `ssh -A`, the local agent will be forwarded
<clever> cryp2nomicon: did you compile it with -Og ?
<clever> changing the expire timeout also helps
<clever> depending on which host the cmd ran on
<clever> so it mostly just acts like a 4 monitor setup, and gpg asks on one of 2 monitors
<clever> i also have synergy configured, and i treat the laptop like an extra monitor for the desktop
<clever> so the only anoyance is when i ssh into the laptop i left upstairs, and it asks in another room
<clever> yeah, ive configured it to always ask on :0 of xorg
<clever> elvishjerricco: dont know
<clever> to the pinentry runs on a random ssh session, and pops up on the wrong pc
<clever> that auto-runs a similar command every time you login over ssh
<clever> and the gpg service in nixos is disabled
<clever> elvishjerricco: i have `gpg-connect-agent /bye` in my `.xsession`
<clever> nix-env wont install headers
<clever> 2018-05-06 19:19:41 < {^_^}> Don't install libraries through nix-env or systemPackages. See https://nixos.wiki/wiki/FAQ/Libraries for details.
<clever> you are you using nix-shell?
<clever> which headers are missing and when?
<clever> and that
<clever> !library
<clever> ,library
<clever> split outputs and .dev, and nixpkgs mostly handles it automatically, so things just work
<clever> one per line
<clever> justanotheruser: it takes the form of <accessid> <accesssecret> <name>
<clever> i havent used nixops with ~/.aws/credentials
<clever> justanotheruser: and normally, it refers to a name from ~/.ec2-keys
<clever> justanotheruser: i think it defaults to that when unset
<clever> stephenjudkins: its an array containing either strings or attr sets
<clever> stephenjudkins: https://nixos.org/nixos/options.html#services.xserver.xrandrheads
<clever> > let foo = "bar"; in { ${foo} = 42; }
<clever> yeah, it only works on http and https
<clever> ambro718: transparent proxies do that all the time
<clever> ambro718: tor can then use the Host: header and SSL SNI to figure out what host to connect to
<clever> ambro718: ah, yeah, using iptables, you can force the browser to connect to the "wrong" ip
<clever> ah, it doesnt
<clever> > { ''key.with/funnychar'' = "value"; }
<clever> > { "key.with/funnychars" = "value"; }
<clever> zybell: yeah
<clever> zybell: an attrset must always be in the form of { key = value; }
<clever> ambro718: ive only messed with layer3 VPN in detail, so i'm not sure how to configure that tor stuff
<clever> ambro718: you could potentially access the wpa_supplicant unix socket between namespaces
<clever> ambro718: yep
<clever> ambro718: and in theory, you could maybe create such a router with virtualbox, or network namespacing in linux
<clever> ambro718: my rough idea, is what if i make a 2nd computer, with 2 interfaces, that will only apply the tor routing to packets coming in on eth1, and eth0 is the wan
<clever> ambro718: it would only force tor on things coming into a given interface, and not force tor on itself
<clever> ambro718: yeah, one option is to have a second network namespace (either a vm, namespace, or 2nd machine), that acts as a gateway
<clever> ambro718: openvpn and android vpn's get around the issue by specially routing the ip of the vpn server to not go thru the vpn, and relying on the server having 1 ip
<clever> MichaelRaskin: russia has banned a fairly massive chunk of the internet
<clever> [root@amd-nixos:~]# zfs destroy amd/root@zfs-auto-snap_daily-2018-05-05-00h00
<clever> iqubic: run zfs destroy on the full name including the timestamp
<clever> iqubic: replace that with a dataset whose snapshots your wanting to list
<clever> iqubic: yeah
<clever> and save them for later, they help to diagnose low disk space issues
<clever> yeah
<clever> the 2nd shows the snapshots for it
<clever> the first shows every filesystem, and how much it consumes in snapshots
<clever> these 2 commands are also handy
<clever> 2018-05-01 13:05:36 <@clever> zfs list -t snapshot -r -o name,used,refer,written naspool/root
<clever> 2018-05-01 13:05:27 <@clever> zfs list -t filesystem -o name,used,usedbysnapshots
<clever> and also check the timeframe variants to verify they dont eixst
<clever> iqubic: zfs get com.sun:auto-snapshot pool -t filesystem
<clever> iqubic: i would also add `-t filesystem` to that, the value of the snapshot param on snapshots doesnt matter
<clever> not off the top of my head
<clever> the nixos module framework may delete the null
<clever> inherit also has -r, to recursively apply it to all children
<clever> run inherit on those param names
<clever> yeah
<clever> `If the property is not defined in any parent dataset, it is removed entirely.`
<clever> iqubic: man page claims `Use the zfs inherit command to clear a user property.`
<clever> iqubic: i think that might disable all timeframes
<clever> tmplt: use mapAttrs or map to run a function over everything
<clever> i'm not sure how to unset those non-standard options
<clever> *doh*, `zfs get all amd/root -s local` saves you the grep
<clever> so if you grep for 'local' you should see everything that has been set and can be undone with inherit, up to the root node
<clever> dedup is inherited from the amd level, while compression is set locally on amd/root
<clever> amd/root compression gzip-9 local
<clever> amd/root dedup off inherited from amd
<clever> NAME PROPERTY VALUE SOURCE
<clever> [root@amd-nixos:~]# zfs get all amd/root
<clever> iqubic: check `zfs get all dataset` as well
<clever> iqubic: not sure
<clever> that will inherit the value from its parent in the dataset tree
<clever> `zfs inherit optionname dataset`
<clever> otherwise, it keeps backups of everything you try to garbage collect
<clever> id also recomend doing zfs set com.sun:auto-snapshot=false poolname/nix
<clever> then it does all of them
<clever> services.zfs.autoSnapshot.enable = true; and zfs set com.sun:auto-snapshot=true poolname
<clever> and the 15 min ones dont overlap with the hourly
<clever> nixos has a service to do all of those out of the box
<clever> never bothered to change the defaults, and the high rate ones expire faster, so they arent much of an issue
<clever> i have monthky, weekly, daily, hourly, and 15min snapshots
<clever> nh2[m]: so you can just take out the log device and see how much worse things get
<clever> nh2[m]: zfs is also a lot more flexible, you can add and remove the log device without reformating the system
<clever> nh2[m]: not sure i have any sizeable spinning rust disks that are unused
<clever> nh2[m]: i also have statsd utils that can monitor zfs and iostat, and confirm if something like an L2 cache or a log device are doing anything useful
<clever> nh2[m]: i use zfs on my NAS, laptops(2 of them), and my primary desktop
<clever> nh2[m]: and ive only seen one other nixos user having it fail, and he was having an NVME drive fail with unreadable sectors, and he had zero redundancy in his array config
<clever> nh2[m]: ive never had it fail on me
<clever> nh2[m]: zfs can already do that by setting the log device to an ssd
<clever> nh2[m]: external journal on an ssd?
<clever> ive got a fork where it just doesnt create a user namespace for root
<clever> currently, it starts a new user namespace, and that drops all capabilities, so even when ran as root, and having uid0 in the namespace, you cant mount anything or kexec
<clever> ive also recently been experimenting with nix-bundle, and getting it to work as root
<clever> nh2[m]: if your not limited to Anaconda, you can just pick another tool, and have nix generate its config, or just have nix generate a script that partitions things directly
<clever> tilpner: or b: delete /boot, shift / 200mb forwards (ouch!), make a new /boot at the start, then expand /
<clever> tilpner: i would have to either a: move /boot to the end of the bigger drive, and then resize the / before it
<clever> tilpner: i also try to avoid doing things like /boot after /, because then you can never resize the / partition
<clever> nh2[m]: and then have a derivation that can read the nix, and generate whatever you need, like an Anaconda Kickstart
<clever> nh2[m]: yeah
<clever> so it can eat whatever is left
<clever> tilpner: and also require that the size="remaining" one be last in priority
<clever> tmplt: nixpart.priority = 1; maybe
<clever> tmplt: all of the buildInput values come into play at bash time, not nix time, so you still need to pass the value in at the nix level
<clever> nh2[m]: then a script can extract the labels, types, and sizes, create them, and nixos will already know the labels and where to mount
<clever> nh2[m]: something else ive thought about before, what if we had a way to do: fileSystems = { "/" = { fsType = "ext4"; device = "LABEL=nixosroot"; nixpart.size = "remaining"; }; "/boot" = { fsType = "ext4"; device = "LABEL=nixosboot"; nixpart.size = "200m"; }; };
<clever> "/home/clever"
<clever> nix-repl> builtins.getEnv "HOME"
<clever> nh2[m]: and that tarball, once ran, would do the entire install, and leave you with root ssh to nixos
<clever> nh2[m]: i'm not sure how it would interact with the rescue system, but an extreme option you could do, is to just upload the kexec tarball, and run it with something a bit higher level then deployment.hetzner.partitioningScript
<clever> just needs an if around line 94-104
<clever> nh2[m]: currently, it only supports zfs, but it could be augmented to also support ext4
<clever> nh2[m]: that handles automated partitioning, formatting, and installing
<clever> nh2[m]: yep
<clever> ccache would be an impurity, nixpkgs needs a fairly heavy redesign to cache .o files properly in a pure manner
<clever> nh2[m]: have you seen my justdoit script?
<clever> you currently only have a single sink, number 0
<clever> iqubic: thats a list of every sink and source in your current pulseaudio daemon
<clever> i have 12 input sinks
<clever> try `pactl list`
<clever> and then scroll thru that
<clever> and it needs to translate to irc color codes
<clever> i think the error was truncated
<clever> hodapp: or just nuke all samples
<clever> hodapp: try running patchelf --shrink-rpath on it after you chmod +w
<clever> yeah, it must only ever be modified from inside a derivation
<clever> hodapp: the file your trying to open isnt writable
<clever> systemd should save stdout and stderr to the journal
<clever> samueldr: oh
<clever> or the journal for that unit
<clever> read the unit file nixos generated in /etc/systemd/system/
<clever> i ran into trouble with that initially
<clever> i think an xfce power util has to be running
<clever> oh
<clever> my laptop runs xfce, and the brightness control keys open a gui that shows the brightness as they adjust it
<clever> read its man page for the exit sequence
<clever> and be careful, xorg may not get any keys once started
<clever> there is also a program readkeys, ran as root, that intercepts things before xorg gets it
<clever> grep -r --color build /nix/store/87lnwkwz6h8738v68kza1dv887zp567i-draftsight-2018-SP2
<clever> hodapp: and you can do it purely with nix-build, the invalid output is left in /nix/store so you can grep it
<clever> hodapp: you need to grep the output path for /build, and match run patchelf --shrink-rpath on the binary
<clever> so genericBuild cant fail with that
<clever> hodapp: ah, nix checks that after the build has finished
<clever> how did it fail with nix-build?
<clever> genericBuild should try to run all the steps, and stop when it fails
<clever> or run nix-build directly so nix does it all for you
<clever> just running genericBuild, without root, should do it all
<clever> it may also be in the nixpkgs manual
<clever> the file i linked has an example of dealing with a .deb file
<clever> `phases="unpackPhase" genericBuild` runs the new one you define
<clever> also, unpackPhase in the shell runs the original, not the redefined one
<clever> you have to `switch` or `boot` for it to persist across a reboot
<clever> Ben_______: `nixos-rebuild test` wont persist after a reboot

2018-05-05

<clever> ixxie: oops, that was for infinisil
<clever> ixxie: then they are in your configuration.nix, and you need internet access to rebuild the config, to get internet access
<clever> ghostyy: it should be possible purely with nix scripting, no need to modify nix itself
<clever> then you can just boot into a customized env, that already has the secrets in the right spots, and just: cp /etc/wpa_supplicant.conf /mnt/etc/wpa_supplicant.conf
<clever> and you can just have a fully working nixos install on USB
<clever> also of note, you can aim nixos-install at a usb stick