<clever>
srid: does 'xev' show anything when you plug in a monitor?
<clever>
trevorcook: try again with .profile
<clever>
srid: it may need to ask xorg to send them first via some api
<clever>
trevorcook: add an echo to ~/.bashrc, then try `ssh user@host nix-store --version` and see if it both prints that echo, and finds nix
<clever>
also, auto-config doesnt work so well on my desktop, my monitors are laid out in the 1,3,2 order
<clever>
and depending on the api, auto-detect&switch
<clever>
srid: so you could trivially add an xmonad binding that activates hard-coded xrandr profiles
<clever>
srid: ah, sounds like its at least using the same module i linked
<clever>
srid: you may also want to look into the xmonad source and figure out what library it uses to hook into X to begin with, so you can stay compatible with that
<clever>
srid: but you could add code to the xmonad config file to manage this!
<clever>
srid: i use xfce and it just auto-detects that without any fuss
<clever>
or you could just "$@" at the end of line 11, passing all flags to the server, and then allow the haskell to accept 2 -p's, so the later ones override
<clever>
you could parse $* within that bash script, and accept flags to override the port
<clever>
which costs you a bit of ram and a pid
<clever>
without exec, the shell on line 10 hangs around waiting for the server to quit
<clever>
Myrl-saki: only improvement i can say, is to add exec on line 11
<clever>
Myrl-saki: 404
<clever>
ive not really been using any cheap ones, i either go AWS, OVH, or just throw another desktop into the storage room
<clever>
kolb: a: hydra wont really work when installed with nix-env enless you want to do a lot of configuring by hand, b: the build was recently broken on nixos-unstable, you may need to update your channel
<clever>
sure
<clever>
the script in that paste, looks better suited to runCommand "name" {} ''
<clever>
so it wont do what your thinking
<clever>
also, all it does, is write the string to $out/bin/<name>
<clever>
so `writeScriptBin "foo"` is a function that takes 1 more
<clever>
writeScriptBin is a function that takes 2 arguments
<clever>
Myrl-saki: it needs a name for the script
<clever>
Myrl-saki: writeScriptBin is a derivation
<clever>
Myrl-saki: you could use just writeScriptBin and nothing else
<clever>
rawtaz: when you least expect it :P
<clever>
but for release, it just bundles
<clever>
so at dev time, it builds faster
<clever>
you could also do both, have a boolean flag to switch between them
<clever>
but it doesnt have to copy the binary, just call it with the right params at runtime
<clever>
yeah
<clever>
so changes to the client dont needlessly recompile the server
<clever>
and then make a 3rd derivation, that just generates a bash script to run it with the right args
<clever>
in theory, you could make a the server accept those paths via cli args or env vars
<clever>
i also just now hard another idea, an optimization
<clever>
layus: recursive nix would allow that to work
<clever>
layus: yeah
<clever>
Myrl-saki: it probably never existed to begin with
<clever>
layus: the gcc search path works by having scripts in the stdenv iterate over everything in $buildInputs (a bash variable) and adding the include subdirs to the -I path via a gcc wrapper
<clever>
layus: that will likely break the gcc include path for most things
<clever>
layus: nix-shell --pure already does that
<clever>
layus: what exactly are you trying to do?
<clever>
ottidmes: yep
<clever>
ottidmes: for a build slave to do that, you must copy over ALL systemPackages to the slave, 2-3gig of files
<clever>
ottidmes: for example, the system-path derivation, is just scanning to see what files exist, and making a symlink tree, quick&easy
<clever>
ottidmes: ive found that the trivial ones are often slower with slaves
<clever>
ottidmes: maxJobs = 1; may allow that, but yeah, its a bit of a pain
<clever>
ottidmes: ah, if you set something like nix.maxJobs = 0; then it just never builds locally
<clever>
ottidmes: why do you want to build it there?
<clever>
ottidmes: though in your case, if the one slave you dedicated to the job happens to be busy with anything
<clever>
ottidmes: ive also found nix to be rather eager to offload things to slaves, and it only builds locally if all the slaves are busy
<clever>
ottidmes: i think requiredSystemFeatures is ignored when building locally
<clever>
bryanRobson: go into the hardware-configuration.nix and remove the extra swap and it should be good
<clever>
bryanRobson: what does fstab say about it? can you paste that line here
<clever>
bryanRobson: is that uuid listed in /etc/fstab ?
<clever>
as long as lpr itself is in PATH
<clever>
silver_hook: yep
<clever>
nice
<clever>
silver_hook: and does that path exist?
<clever>
silver_hook: what does "${pkgs.cups-filters}/share/cups/data/testprint" eval to inside `nix-repl '<nixpkgs>'`
<clever>
silver_hook: i think you just want pkgs.cups-filters
<clever>
the nix expressions are used to generate the .drv files
<clever>
the raw directions telling nix-daemon how to build something
<clever>
nix-store -qR on the .drv would give you ALL the build-time things, including stuff it no longer needs (like the gcc source!)
<clever>
and there is no one magic tool to list off everything you currently have that can be copied to a remote machine to speed up its building
<clever>
Myrl-saki: the issue, is that the deps in the default.nix may themselves not be built yet
<clever>
Myrl-saki: nix-copy-closure already gets the closure, its in the name
<clever>
but once imported, it is bound to that hostid, and you need force to change that
<clever>
so it sounds like the rule is, an exported pool can be imported by anybody
<clever>
infinisil: done
<clever>
or clang in your case
<clever>
nix-shell and the stdenv handle it all for you, so `nix-shell -p libtasn1` adds it to the search path for gcc
<clever>
nix can garbage collect the .dev output after your done building
<clever>
you only need the header at compile time
<clever>
split outputs
<clever>
and look in result-dev
<clever>
mpickering: try -A libtasn1.dev
<clever>
mpickering: how did you get the path to those files?
<clever>
infinisil: so if you disable forceImport, then you must cleanly export the pool when changing hostId's (from installer to main os)
<clever>
MichaelRaskin: it does contain it, acording to nix-locate
<clever>
libtasn1.dev 12,759 x /nix/store/81pmcrfl1i5hpz58sm4p88d4pw9hf49c-libtasn1-4.10-dev/include/libtasn1.h
<clever>
infinisil: this time, all i did was `shutdown -h now` and then boot it back up, its just spamming .....'s at the initrd
<clever>
disk wiped, doing a second install
<clever>
infinisil: it boots just fine, possible because i did a full `zpool export tank` before shutting down the installer
<clever>
so it would just cause a rebuild with $version set to a value at build-time, which has zero impact on the build
<clever>
sean__: it probably wont even change the name
<clever>
sean__: more that changing the version wont change the url inside the src, due to how nix works
<clever>
infinisil: got distracted, but the nixos-install was running last i checked it
<clever>
and how many your trying to delete
<clever>
MichaelRaskin: i think it would depend on the inode count
<clever>
and you can tune the inode count to be higher and go monthly
<clever>
mkfs is always faster then rm -rf
<clever>
similar to LnL's idea
<clever>
gchristensen: and use it as a cache
<clever>
gchristensen: though you could have a disk image on a file, that you format once a week, rather then rm -rf
<clever>
MichaelRaskin: my hydra has gc-keep-derivations and gc-keep-outputs set
<clever>
we need a repl for the daemon unix socket
<clever>
so whatever you do, performance is going to suck
<clever>
MichaelRaskin: and every invocation has a massive amount of initialization
<clever>
MichaelRaskin: if `nix-store --delete` is given multiple files, it will stop at the first in-use one, and not delete further files
<clever>
but invalid paths come first
<clever>
gchristensen: i think by default, nix will shuffle all garbage, and then delete until it hits the --max-freed quota
<clever>
infinisil: and now i can tell qemu to justdoit!
<clever>
infinisil: yeah
<clever>
infinisil: testing some things out in my kexec env to see what happens...
<clever>
that list appears to suffer from the 3rd problem :P
<clever>
and properly hand-off full control of it
<clever>
so you need to export the pool and flush the write caches, then flush the read caches and import the pool
<clever>
infinisil: your read cache may wind up claiming something that is false, because your un-aware of writes another machine did
<clever>
infinisil: which may confuse and crash the reading kernel
<clever>
infinisil: even reads are unsafe, because the other machine may change things your not expecting
<clever>
gchristensen: thats why zfs wont import the pool if the hostId is wrong
<clever>
infinisil: i was once booting my laptop over that
<clever>
infinisil: iscsi is basically sata over tcp
<clever>
gchristensen: in the past, i have used nbd (a relative of iscsi) to jurry-rig an lvm array together across 2 machines, so i could replace one of the drives with a bigger one
<clever>
gchristensen: iscsi
<clever>
ghostyy: nixos will append that list to the existing one, and add it to the PATH env for the service
<clever>
instantepiphany: you can also append -I nixpkgs=whatever to it
<clever>
instantepiphany: yeah
<clever>
ottidmes: there is also nix-instantiate --find-file nixpkgs
<clever>
instantepiphany: also, you shouldnt really be using nix-env inside nix-shell, its installing things into your user, that will persist even after you leave the shell
<clever>
instantepiphany: but if you `nix-env -iA nixos.hello` it will check the nixos channel on the host system
<clever>
instantepiphany: yes and no, if you `nix-env -f '<nixpkgs>' then it will search for a `nixpkgs` inside the `output` directory
<clever>
instantepiphany: nix-env will only obey that if you do something like `nix-env -f nixpkgs.nix -iA hello`
<clever>
bgamari-: you can limit what packages obey the modified glibc, but the entire closure of you program would still have to be rebuilt
<clever>
tommyangelo: using query, delete, and du, you can figure out why the large paths are still around, and delete them
<clever>
tommyangelo: `nix-store --query --roots /nix/store/12725jwvrfjqkmpd58h9wnvpwl1zmscg-ghc-8.2.2` will tell you why a given ghc is still around, and `nix-store --delete /nix/store/12725jwvrfjqkmpd58h9wnvpwl1zmscg-ghc-8.2.2` will delete it (dont force it)
<clever>
tommyangelo: can you start with this command and tell me the output? `du -h --max=1 /nix/store | sort -h`
<clever>
tommyangelo: `nix-collect-garbage` should have gotten rid of it
<clever>
pjan: you can also install screen/tmux, and run a curses based irc client like irssi
<clever>
pjan: it will appear on your gist.github.com page, from any device
<clever>
pjan: `nix-env -iA nixos.gist` then `gist --login` and `gist -p logfile.txt`
<clever>
pjan: what is the full output of nixos-install?
<clever>
thought you where talking about the pool not being closed properly at shutdown
<clever>
ahh
<clever>
hyper_ch2: offline just stops writes, which can lead to the pieces of the mirror getting out of sync with eachother