2018-02-25

<clever> Acou_Bass: what is in your config.nix?
<clever> hask_bee_3: if you generate a .service file with nix, then the version will be locked in until you re-generate it, and the files will remain cached
<clever> hask_bee_3: the version of postgress may change without warning, and its just slower
<clever> mfiano: weird
<clever> mfiano: and if you run env from the same place?
<clever> mfiano: what is launching nix-shell?
<clever> mfiano: try without --pure?
<clever> ottidmes: also, grub works with both legacy and efi, while systemd-boot is efi only
<clever> mfiano: so its getting set at a later point, probably when the shell goes interactive and chooses to source more config files
<clever> mfiano: what about running env in that same script that did the echo?
<clever> ottidmes: and it would just be less work to fix 1 thing in grub, then 5 things in systemd-boot
<clever> ottidmes: yeah, but there are other things its also missing
<clever> ottidmes: systemd-boot just lacks that option
<clever> ottidmes: also, in nixos, there is an option to configure how many generations go into the grub config, so your /boot doesnt get bloated
<clever> hask_bee_3: the .runner script isnt documented in any of the manuals
<clever> hask_bee_3: it reuses the nixos startup scripts, in a portable way, so it works on any os
<clever> ottidmes: and i know grub inside and out
<clever> ottidmes: systemd-boot dosnt seem to have very many options, and ive always been anti-systemd :P
<clever> ottidmes: nice
<clever> lejonet: pass -curses to the bash script nix generated, or set virtualisation.graphics = false;
<clever> gchristensen: do you still have that gist link handy?
<clever> hask_bee_3: gchristensen actually did something just like that about 3 days ago
<clever> ottidmes: ah, that sounds like something that should be fixed, grub is far better then systemd-boot
<clever> lejonet: also, try using --fast, its likely a small bug that is misleading you
<clever> lejonet: extraDisks is a bash variable, not a nix one
<clever> lejonet: and on line 101, it passes all params to that script, directly to qemu
<clever> lejonet: it runs a map function over everything you give in the emptyDiskImages option
<clever> ottidmes: the only special things i can think of right now are toString, import, and readFile
<clever> ottidmes: yeah
<clever> ottidmes: and next time you eval, it will read it again
<clever> ottidmes: some nix functions like import can just read it without copying it into the store
<clever> ottidmes: and inside a string, you need to "do ${./this}" to make it at the nix level
<clever> ottidmes: but if you /dont/quote/it at the nix level, it gets copied into the store, and replaced with a storepath
<clever> ottidmes: if you "/quote/a/path" it wont be copied, its just a string that gets passed to the program
<clever> pie__: there is also the <nixpkgs> vs <unstable> difference
<clever> lejonet: the build-vm variant lacks that backdoor
<clever> lejonet: mostly, nixos adds a root shell on a special serial port, to backdoor the vm
<clever> Mic92: and it detects such re-launching, and drops into a shell, rather then trying to re-test itself
<clever> Mic92: i think the vm leaves a special script in its build dir, and if you -K the build, you can nix-shell into it or something, and re-launch the vm
<clever> pie__: oops, i missed an import before <nixpkgs>
<clever> mfiano: you want bashInteractive
<clever> mfiano: 'bash' is that simpler bash
<clever> mfiano: nix-shell uses a more light-weight build of bash that lacks a lot of options
<clever> Guanin: its nearly 6pm, and i have slept since we last spoke
<clever> src is just passed down, so it works on either
<clever> pie__: generic-builder.nix then calls stdenv.mkDerivation, where overrideAttrs can inject its own changes
<clever> pie__: overrideCabal changes the params passed to generic-builder.nix, so it can change haskell level things
<clever> pie__: ah, overrideAttrs vs overrideCabal, i think the difference is which level it overrides at
<clever> pie__: the fetchgit
<clever> pie__: but if you just unpack it locally, you can use src = ./.; and then freely edit anything
<clever> Guanin: yeah
<clever> pie__: you would have to edit the rev and hash after every edit
<clever> pie__: yep, but now you cant modify the src as easily
<clever> mfiano: nix-shell --pure disables all of those things
<clever> pie__: nix-build -E 'with <nixpkgs> {}; haskell.lib.overrideCabal haskellPackages.shake (drv: { src = ./.; })'
<clever> pie__: ah, thats much simpler
<clever> pie__: oh wait, do you want to replace all of haskellPackages, or just one package?
<clever> mfiano: you could also try running `env > /tmp/rofi` via rofi, and then `env > /tmp/bash` from a normal shell, then diff the 2 files
<clever> mfiano: since dmenu inherits the parent env
<clever> mfiano: you can also query the parent that was launching dmenu
<clever> mfiano: and compare it to what `env` says in a shell
<clever> mfiano: check what the demnu process has for an env, its probably missing something key
<clever> mfiano: if you run strings /proc/PID/environ you can peek at the env vars of any process
<clever> mfiano: when you open a terminal, the shell reads the interactive init stuff, and then the right env vars are setup
<clever> mfiano: bash sources an interactive init file when opening shells, but if you run things directly from the WM, that doesnt get sourced
<clever> pie__: yeah
<clever> pie__: but stack2nix can generate similar things with a stack.yaml file
<clever> pie__: that was generated via https://github.com/NixOS/cabal2nix/tree/master/hackage2nix
<clever> M1k3y: then use that to find the paths you want, and add a cp command to put them somewhere under $out
<clever> as a start
<clever> '';
<clever> ls -ltrh
<clever> M1k3y: id add postInstall = ''
<clever> that generates a vi script that will land in $PATH, so sudo can find it
<clever> ''
<clever> exec vim "$@"
<clever> #!/bin/sh
<clever> disasm: so you will want to do something like installing writeScriptBin "vi" ''
<clever> disasm: aliases are handled by bash, and `sudo vi` doesnt check aliases
<clever> M1k3y: ah, then the installPhase has to copy those files somewhere under $out, and it has to be patched to know where to look
<clever> mfiano: i just started with vi over a decade ago, and now its just hard-wired into my brain
<clever> mfiano: i never bothered learning the difference :P
<clever> mfiano: i aliased vi to vim, even shorter!
<clever> disasm: and in terms of vim plugins gaining root, root controls them fully, via vim.nix
<clever> disasm: yeah, that can be fun
<clever> M1k3y: set fetchSubmodules=true; inside the fetchFromGitHub
<clever> alexteves: what is the difference between ghc and runghc?
<clever> ~/.vimrc just doesnt exist
<clever> disasm: so i just sudo -i and run vim directly as root
<clever> disasm: i use the vim.nix i linked above, so vim just always has the right config
<clever> mfiano: ive heard that emacs also has special plugins, where it will internally call sudo on its own, to gain write access to things, maybe vim has such things?
<clever> the quit requirement is a bit anoying, but the editor runs as the correct user
<clever> mfiano: and when the editor QUITS, sudo will copy the file back
<clever> mfiano: when you run "sudoedit /root/foo", sudo will copy the file to /tmp, then run $EDITOR without root
<clever> mfiano: ah, you could just symlink those 2 nvim directories then, simple
<clever> mfiano: maybe just make a simple .virmc that does #include /home/clever/.vimrc, and configure that 2nd one to be relative to itself, to find its neighbors?
<clever> mfiano: are they mostly in a single directory?
<clever> mfiano: you could also symlink the /root/.vimrc to the other one
<clever> mfiano: oh, and there is also sudoedit
<clever> mfiano: you can just drop that file into /etc/nixos/ and then add ./vim.nix to the imports list
<clever> mfiano: this embeds the vim config into the vim binary
<clever> mfiano: nixos lets you do that by just not using ~/.vimrc
<clever> mfiano: its probably in the options then
<clever> mfiano: when it asks on startup, there is an option to stop checking
<clever> mfiano: set it as default, then just tell it to stop checking
<clever> mfiano: the bash script is set as the wrapper, but chromium checks for its own binary i think
<clever> mfiano: thats a bug due to how chrome is wrapped with a bash script
<clever> hask_bee_3: nix will check for files actually in use (in env vars, running, open files)
<clever> hyper_ch: good, lol
<clever> hask_bee_3: good
<clever> hask_bee_3: stack2nix lets you use a stack.yaml file with nix
<clever> hask_bee_3: if you switch over to nix-build, then the problem wont happen
<clever> hask_bee_3: it cant really be fixed, its just a side-effect of how nix and nix-shell work
<clever> and the above symlink for short-term changes where i dont want to make a commit for every single edit i do
<clever> git for long-term saving and sync'ing to other computers
<clever> null_: that saves a snapshot of whatever directory its file is within, to the nixos build
<clever> null_: i use git and this trick: system.extraSystemBuilderCmds = "ln -sv ${./.} $out/nixcfg";
<clever> null_: by default, no
<clever> hask_bee_3: if you want the cache to last long-term, you must use nix-build, and probably stack2nix
<clever> hask_bee_3: all that does is run the builds under nix-shell, but the binaries nix-shell produces arent meant to survive a garbage collection
<clever> null_: hardware.opengl.driSupport32Bit = true;
<clever> null_: one min
<clever> hask_bee_3: more that binaries built that way when using nix arent meant to last
<clever> hask_bee_3: if things are instead built using nix (stack2nix is an option), then nix knows when things are in use, and wont break it
<clever> hask_bee_3: nix has no way to track that those files are in use, and deletes them, so you have to wipe your ~/.stack/setup-exec-cache/
<clever> hask_bee_3: that happens when you garbage collect while using stack the "wrong way"
<clever> hyper_ch: yes, lol
<clever> mfiano: and then after a reboot, gpg will ask for that passphrase to decrypt it, and you never have to ssh-add again
<clever> mfiano: any time you do `ssh-add`, gpg will ask you for a passphrase to encrypt the ssh key with
<clever> mfiano: with this, gpg will run as an ssh agent
<clever> mfiano: but the nixos option to enable gpg is dumb, and screws up horibly if you ssh into that system
<clever> mfiano: yeah, thats anoying, and why i switched to gpg-agent
<clever> sphalerite_: it wasnt even nixops managed to begin with either!
<clever> sphalerite_: also, i just used `nixops deploy` to upgrade a nixos 16.03 (from nixos-unstable) machine to nixos 17.09, and it experienced minimal downtime
<clever> sphalerite_: i saw similar in virtualbox
<clever> sphalerite_: nice, ive never seen that on real hardware
<clever> and the tweak i did above is now in place, my router has postgress again
<clever> Feb 25 08:01:35 router systemd[1]: Started PostgreSQL Server.
<clever> mfiano: this allows you to access toe nightly, beta, and stable channels
<clever> yep
<clever> mfiano: there is a rust overlay that has those things
<clever> i just add a 94 to line 79, and its now forced to use version 9.4
<clever> 79 postgresql.package = pkgs.postgresql94;
<clever> 78 postgresql.enable = true;
<clever> nix-repl> postgresql94
<clever> «derivation /nix/store/p91w916iyanllx3yw78bny065p9vrx17-postgresql-9.4.15.drv»
<clever> also, nix makes it trivial to fix problems like this
<clever> Feb 25 07:48:44 router postgresql-start[8288]: DETAIL: The data directory was initialized by PostgreSQL version 9.4, which is not compatible with this version 9.6.6.
<clever> forgot that small detail
<clever> in configuration.nix, it needs to be ${pkgs.rustc}
<clever> and nix-shell -p haskell.packages.ghc822.ghc gives me 8.2.2
<clever> as an example, nix-shell -p haskell.packages.ghc802.ghc gives me the 8.0.2 version
<clever> nix-shell
<clever> nope
<clever> only programs installed via nix will work
<clever> also, any ELF file you download will just break, /lib/ld-linux.so doesnt exist
<clever> if [ -x ~/.bin/rustc ]; then
<clever> then you would need to check for it
<clever> ahh
<clever> what did you put in your nix file?
<clever> LD_LIBRARY_PATH=$(${rustc}/bin/rustc --print sysroot)/lib:$LD_LIBRARY_PATH
<clever> nix will automatically download rustc if you use what i gave above
<clever> mfiano: but anywhere else, its just an unset bash variable
<clever> mfiano: ${rustc} will expand to the full path of the rustc files, if placed in a nix file
<clever> mfiano: then the string i gave wasnt in a nix config file
<clever> and the router survived a switch from 16.03 to 17.09!
<clever> !tofu
<clever> oh god, lol
<clever> router> restarting systemd...
<clever> mfiano: ${rustc}/bin/rustc will be the path to the binary, even if its not installed
<clever> its currently running a copy of nixpkgs from 2016
<clever> let me find a monitor for recovery...
<clever> i should test my router upgrade, and then get to bed
<clever> yep
<clever> and most are append, rather then prepend
<clever> the other methods dont always offer full control over the order of things
<clever> export PATH=~/.bin/:~/.cargo/bin:$PATH
<clever> you probably want to use shellInit them
<clever> thats how /run/current-system/sw/bin winds up in PATH
<clever> mfiano: ah, this generates everything from PATH to LIBEXEC_PATH, relative to everything on lines 27-29
<clever> let me see where PATH comes from...
<clever> not sure about the other 2
<clever> ~/bin gets added automatically if it exists
<clever> what do you want to add to PATH?
<clever> ''you can escape such things like ''${this} in a multi-line''
<clever> but ${nixexpansion} can still happen
<clever> and since its going thru .text, there is zero shell-level expansion
<clever> and then uses its own shellInit to generate /etc/profile
<clever> bash then sets its own shellInit config, to contain a copy of the global environment.shellInit
<clever> this defines the option itself, but does nothing with it
<clever> let me find the source
<clever> its probably going to be a literal $HOME
<clever> it strips the indent that makes the nix config pretty, keeping the output pretty as well
<clever> thats the point of ''double single'' strings
<clever> so if every line is indented by 4 spaces, the resulting string has no indentation at all
<clever> but ''these ones'' will strip out any common spaces between each line
<clever> both "strings" and ''strings'' accept multiple lines
<clever> mfiano: use a ''mult-line string''
<clever> Havvy: hydra.nixos.org
<clever> https://app.cacher.io/ is how i search them
<clever> it says i have 715 gists....
<clever> i have so many gists that i had to find a dedicated service that deals with finding your own gists, lol
<clever> and /etc/profile sources set-environment
<clever> environment.variables.A = "1"; deals with escaping and directly handling variables, and environment.extraInit bypasses that and just does raw strings again, both go into a special set-environment script
<clever> and environment.loginShellInit
<clever> programs.bash.shellInit also goes into /etc/profile
<clever> environment.shellInit inserts raw strings into /etc/profile
<clever> environment.interactiveShellInit just inserts raw strings into /etc/bashrc
<clever> there are half a dozen ways of setting env variables in nixos
<clever> one sec
<clever> line 122 inserts that config into the generated script
<clever> and you wont need to remember a random file in $HOME anymore
<clever> if you add these 4 lines to configuration.nix, then it will be baked into the nixos config
<clever> '';
<clever> [[ -e $XDG_CONFIG_HOME/xorg/xresources ]] && xrdb -merge $XDG_CONFIG_HOME/xorg/xresources
<clever> [[ -e $XDG_CONFIG_HOME/xorg/xmodmap ]] && xmodmap $XDG_CONFIG_HOME/xorg/xmodmap
<clever> services.xserver.displayManager.sessionCommands = ''
<clever> oh, and also
<clever> nixos will also auto-load ~/.Xresources if it exists
<clever> try renaming it to .xprofile
<clever> if .xsession is executable, it gets directly ran, and assumes full control, the WM does not get run for you
<clever> .xprofile is sourced, if it exists, and will then continue on to the chosen WM
<clever> mfiano: i think nixos only obeys .xprofile and .xsession
<clever> mfiano: one sec
<clever> this should show what version its currently using
<clever> nix-store -qR /run/current-system | grep --color nvidia
<clever> and this warning means that the path it downloaded could just disapear the next time you do a garbage collection
<clever> 2018-02-25 02:18:32 < mfiano> warning: you did not specify ‘--add-root’; the result might be removed by the garbage collector
<clever> it just sits in a cache
<clever> `nix-store -r` also does not "install" anything
<clever> nix-env -q will list what was installed
<clever> so there is no need to remove it
<clever> all the nix-shell stuff isnt really installed
<clever> then youll want to edit the file i pointed at, to specify an arbitrary version
<clever> then use this to apply the modified nixpkgs to the system
<clever> nixos-rebuild switch -I nixpkgs=/home/clever/nixpkgs/
<clever> then edit this to change the version
<clever> mfiano: clone nixpkgs, and checkout that revision
<clever> mfiano: near the end of the version is a short hex string, that is a git revision from nixpkgs
<clever> mfiano: nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion
<clever> mfiano: next...
<clever> mfiano: put one of those 5 strings into services.xserver.videoDrivers, then rebuild switch, and reboot
<clever> mfiano: simplest thing to do is to try the 5 versions in here: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/hardware/video/nvidia.nix#L14-L25
<clever> mfiano: rollbacks only really work for something you have installed via nixos, so you will need an override instead, one min
<clever> mfiano: its over here
<clever> [clever@amd-nixos:~]$ ls /nix/store/2j0anj185jb0w7zxpp5q3q6cqib956ib-chromium-62.0.3202.62/libexec/chromium/chromium
<clever> mfiano: oh, one sc
<clever> mfiano: and here is version 60 if you want to go another 2 steps older
<clever> /nix/store/20di7bfxaljl4vky7dwm6g2rr499i6sp-chromium-60.0.3112.90
<clever> mfiano: then run /nix/store/2j0anj185jb0w7zxpp5q3q6cqib956ib-chromium-62.0.3202.62/bin/chromium
<clever> mfiano: nix-store -r /nix/store/2j0anj185jb0w7zxpp5q3q6cqib956ib-chromium-62.0.3202.62
<clever> pikajude: thats what made hackage-packages.nix to begin with
<clever> mfiano: one min
<clever> mfiano: we can also try older copies of chrome
<clever> i suspect xterm was trying to v-sync on every single character
<clever> yet every other program was fine
<clever> xterm required abnormally high amounts of cpu, just to bloody scroll
<clever> i have had the oposite problem in the past
<clever> simpson: https://imgur.com/a/yPJe6 is what i get
<clever> lopsided98: even without hw accel, i can play youtube videos with only ~20% cpu usage
<clever> it might have a different name
<clever> mfiano: run ls on the chrome path it downloaded, and check the bin directory
<clever> pikajude: there is a hackage2nix program, that you could probably use
<clever> just throw all the debug flags at it! lol
<clever> mfiano: try this one?
<clever> LIBGL_DEBUG=verbose chromium --enable-gpu-debugging --enable-gpu-driver-debug-logging --enable-gpu-benchmarking --enable-gpu-client-logging
<clever> mfiano: ok, lets see...
<clever> mfiano: does that make any difference?
<clever> mfiano: try closing chrome fully, then run chromium --disable-gpu
<clever> mfiano: one min
<clever> mfiano: definitely sounds like the gpu drivers arent , or that
<clever> simpson: but 60 fps means you have v-sync working, and the gpu is probably doing its job
<clever> simpson: having 200 fps means you lack v-sync, and the cpu is going nuts rendering a simple thing crazy-fast
<clever> simpson: yeah, and i typicaly expect lower FPS numbers to be better with glxgears
<clever> mfiano: what kind of fps does this get?
<clever> mfiano: nix-shell -p glxinfo --run glxgears
<clever> nix-shell changes dont persist
<clever> mfiano: nix-shell -p xfce.xfce4-screenshooter --run xfce4-screenshooter
<clever> mfiano: nix-env -iA nixos.xfce.xfce4-screenshooter
<clever> mfiano: i usually install xfce4-screenshooter and bind it to the printscreen key
<clever> samueldr: grub flagged the rescue shell with noreturn, so you cant return control to the efi shell
<clever> mfiano: ?
<clever> and you can just edit hardware-configuration, just be aware that it gets overwritten, if you run nixos-generate-config by mistake
<clever> but your free to just never use that again, and manage it all yourself
<clever> mfiano: the only real point i see with hardware-configuration, is to make it easy to re-generate the basic mount stuff with nixos-generate-config
<clever> mfiano: its mostly personal preference