<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>
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>
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>
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>
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>
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