2019-05-26

<clever> adisbladis: also of note, it can connect to $DISPLAY, and discover the socket via that
<clever> simukis_: if you run nix-build as root, it wont use the daemon, and will obey TMPDIR
<clever> talqu: strace the nginx process when doing a request
<clever> talqu: and depending on what your doing, you could force the etag to come from the storedir, if your exclusively sharing things from that dir
<clever> talqu: with a simple `etag off;` in the nginx cfg, you can just disable that entirely
<clever> talqu: so all caching is based on your file size!
<clever> talqu: nix then forces the lastmod to 1 second after unix epoch
<clever> talqu: nginx sets the etag based on the filesize and last-mod stamp
<clever> ZoomZoomZoom: is the bios booting from the right ESP? your using sde1, so there are another 4 drives in the machine...
<clever> ZoomZoomZoom: sounds like everything should just work
<clever> ZoomZoomZoom: and also `cat /etc/fstab` ?
<clever> ZoomZoomZoom: what does `mount` output?
<clever> ZoomZoomZoom: dont think so
<clever> ZoomZoomZoom: it will show a clear error when that happens, but it doesnt happen often
<clever> DigitalKiwi: it will auto-create well-known and configure nginx to share it
<clever> ZoomZoomZoom: that happens when you remove keys in configuration.nix and switch
<clever> ZoomZoomZoom: when nixos boots, it will also copy them over to /etc/ssh/
<clever> DigitalKiwi: that wont make things expire any faster
<clever> DigitalKiwi: looks like the A record is missing now
<clever> ZoomZoomZoom: ok, thats odd, its pointing to the latest generation, can you confirm that the ssh pubkeys are all present in /run/current-system/etc/ssh/ ?
<clever> HangoverGenius: so its identical to doing import ./thing.nix { mkDerivation = pkgs.haskellPackages.mkDerivation; base = pkgs.haskellPackages.base; .... }
<clever> HangoverGenius: callPackage will lookup any arguments it needs in haskellPackages
<clever> DigitalKiwi: this implies that either the firewall is blocking it, or the ip is wrong
<clever> DigitalKiwi: * connect to 206.189.253.184 port 80 failed: Connection timed out
<clever> ZoomZoomZoom: can you `ls -l /run/ /nix/var/nix/profiles/` and pastebin the output immediately after a reboot?
<clever> ZoomZoomZoom: that sounds more like you didnt configure /boot properly, so EVERYTHING is being undone at reboot
<clever> DigitalKiwi: the v4 from the error logs matches what i get, and you previously claimed the dns in the logs is right
<clever> DigitalKiwi: and they dont have their own firewall thing, right?
<clever> DigitalKiwi: is there a router in the way?
<clever> DigitalKiwi: you are also not responding over ipv4
<clever> DigitalKiwi nginx isnt listening on 443, something weird is going on
<clever> DigitalKiwi: `sudo netstat -anp | grep nginx`
<clever> DigitalKiwi: and `netstat -anp | grep 90` shows its running nginx?
<clever> DigitalKiwi: and they match the validationRecord in the logs?
<clever> marek: its a kernel level problem, if the #! is too long, the kernel ignores it entirely, then bash tries to be too smart and thinks its a bash script
<clever> DigitalKiwi: is that domain pointing to the nixos machine correctly?
<clever> DigitalKiwi: i think your returning status code 404, when its trying to query the .well-known addr
<clever> May 26 15:24:50 absurd-nixos in66lxxs1z3my4claslchxw6bgkwhm1v-unit-script-acme-myfriendshate.me-start[30148]: "status": 403
<clever> May 26 15:24:50 absurd-nixos in66lxxs1z3my4claslchxw6bgkwhm1v-unit-script-acme-myfriendshate.me-start[30148]: "detail": "Invalid response from http://myfriendshate.me/.well-known/acme-challenge/6iJ2SThXX7lFlsfZKOzASrqiD7AIM-Y5Fbl8LxsYBsQ [2604:a880:400:d1::6c3:3001]: \"\u003chtml\u003e\\r\\n\u003chead\u003e\u003ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\\r\\n\u003cbody bgcolor=\\\"white\\\"\u003e\\r\\n\u003ccenter\u003e\u003ch1\u0
<clever> DigitalKiwi: oh, forgot, `-o cat` makes the journal a lot simpler to read
<clever> yes, thats weird
<clever> DigitalKiwi: enableSSL conflicts with enableACME (which enables ssl for you)
<clever> DigitalKiwi: the errors are cut short, you need to `journalctl -f -u X -n 1000`
<clever> DigitalKiwi: what errors is it giving, and what config did you try?
<clever> yeah

2019-05-25

<clever> and then point open_basedir to that
<clever> it sounds like you want to use pkgs.runCommand to create a single directory, that has all involved files in it
<clever> yep :)
<clever> yeah, nix.sandboxPaths are required, to sneak the qemu binary into the sandbox
<clever> but if you use a pure arm nixpkgs, via `import <nixpkgs> { system = "armv7l-linux"; }` it will be the arm ldd
<clever> so its running the x86 ld.so against things
<clever> behind the scenes, ldd just runs ld.so on the target file
<clever> are you using the arm ldd?
<clever> somebody else gave it to me, but it looks like i forgot to tie it in
<clever> das_j: looks like it, heh
<clever> das_j: *looks*
<clever> das_j: thats to deal with argv[0] issues
<clever> so when you use arm ldd, on an arm binary, the dynamic qemu prints its deps out!
<clever> the problem is that ldd functions by setting env vars, and then ld.so will print the deps, rather then execute a thing
<clever> it 90% works with a dynamic qemu
<clever> and line 38 will setup binfmt-misc
<clever> line 45 will configure nix, so that it believes you can run those things natively
<clever> line 36 will add qemu binaries to make it all work
<clever> just add the path of that to your imports list, and then flip on an enable from lines 24-26
<clever> das_j: yes
<clever> das_j: .overrideAttrs (drv: { doCheck = false; })
<clever> pie_: a lot of QT things dont play well with nix run/nix-shell, and expect things to be installed into your profile
<clever> then i just install manymans instead
<clever> cf6b88f: i use this to merge 4 manpage packages together, and silence warnings about collisions
<clever> cf6b88f: yeah
<clever> ,pr greenerworld[m]
<clever> cf6b88f: nix-shell doesnt setup MANPATH
<clever> `nix run -f ~/.nix-defexpr/channels/unstable drawpile` ?
<clever> what about `nix-instantiate --find-file unstable` ?
<clever> nix-channel then adds things to that dir
<clever> yeah, thats how non-root channels get in
<clever> root's channels are already in your search path
<clever> just add the channel to root :P
<clever> compare $NIX_PATH before and after
<clever> pie_: `bash -l` may also work
<clever> infinisil: i think `nix run` operates entirely on NIX_PATH, which is why you need nixpkgs.foo, not nixos.foo
<clever> probably
<clever> its simpler to just put all channels on root
<clever> pie_: its not in NIX_PATH if you have no channels at login
<clever> pie_: oh, and the first time you add a non-root channel, i think you have to relaunch the shell
<clever> which can be both good and bad
<clever> that will re-download the whole channel at random times, so you wont always get the same version you had yesterday
<clever> did you also --update?
<clever> if you dont want to develop with it, you can likely also use `nix run unstable.drawpile`
<clever> pie_: nix-instantiate --find-file unstable, to find it
<clever> pie_: -p only ever uses <nixpkgs> but you can use -I nixpkgs=something to remap it
<clever> if you have console access...
<clever> ambro718: if the 64bit stuff is still in grub, you can just reboot and select an older version
<clever> so it ignores the #! line
<clever> ambro718: i just manually ran the 32bit perl against the 64bit activation script
<clever> ambro718: ah, ive solved that before
<clever> ambro718: why do you want to do that?
<clever> jlv: also make sure you are on the alsa device, not the pulse device, f6 to select the card
<clever> i have options like front-mic-boost, and auto-mute-mode
<clever> jlv: if you scroll thru alsamixer, you may find the preamp option in there
<clever> jlv: run alsamixer in a terminal and poke about

2019-05-23

<clever> `nix-collect-garbage --max-freed 1g` will limit how much it deletes, so valid (but un-rooted) things can survive
<clever> and if one is in the way at the start of a build, its cleaned up first
<clever> any lingering $out's will be marked as invalid, and nix-collect-garbage will delete them first
<clever> dminuoso: the above error isnt the installPhase
<clever> dminuoso: it may be a bug in the nix-env buildenv stuff, its no longer allowed to point to things that dont exist
<clever> ahh
<clever> i'm probably mixing it up with something else
<clever> pie_: you must still have outputHash if you want network
<clever> pie_: i think __impure is for things like current date/time, so it wont cache
<clever> dminuoso: when nix-env is ran?
<clever> (at build time)
<clever> dminuoso: you can symlink $out/tmp to /tmp, without having access to the real /tmp
<clever> nh2: callCabal2nix cant get internet access, your just giving it a storepath with everything it needed
<clever> i just run ssh-agent

2019-05-22

<clever> ,locate wireguard.ko
<clever> and you also need a way to tell ssh multiple keys you can use
<clever> so some wont obey that
<clever> but, every backend handles ssh keys differently (see ec2 above)
<clever> gchristensen: i think the safest way to do that, is to generate a new keypair, but keep the old pair, and deploy the new nixops config
<clever> so they forever have root, on everything
<clever> and you can never revoke those keys (with current nixops)
<clever> they have a copy of every single ssh private key
<clever> gchristensen: for example, if somebody is upset over being fired, and has a copy of ~/.nixops/deployments.nixops
<clever> gchristensen: another thing id like to see, is a way to SAFELY rotate ssh keys
<clever> so you cant enforce it being 100% declarative!
<clever> the other problem there, is that if you disable ~/.ssh/authorized_keys, you lock nixops out!
<clever> but it wont delete the private, so if you undo the rename, it can regain access
<clever> and then lock itself out
<clever> also, the ec2 backend remembers the name of the keypair you used, and if you rename it, nixops will notice the name is "wrong" and choose to use no keys!
<clever> but the ec2 backend relies ENTIRELY on the /root/.ssh/authorized_keys that was made on first-boot
<clever> the none backend gets into the machine "somehow" (password usually), then generates its own key and lets itself in via the deployed config
<clever> gchristensen: and ec2 can easily "forget" keys
<clever> gchristensen: ive noticed the none and ec2 backends handle it very differently

2019-05-21

<clever> elvishjerricco: refer to the example i linked, it maps 8080 to 80
<clever> virtualisation.graphics=false switched the console, and the qemu cfg at the same time
<clever> thats what lets you see ttyS0
<clever> but if you specify -nographic to qemu, it will remap the stdin/stdout to the serial port for you
<clever> the serial port is hidden by default
<clever> elvishjerricco: oh, i know why
<clever> elvishjerricco: you can also use code like this to simplify the commandline, i just `nix-build test-monitoring-locally.nix -A vm`, and thats it
<clever> can you pastebin your full nix file, and the nixpkgs rev your testing on?
<clever> i do see them when i run virtualisation.graphics = false;
<clever> yeah
<clever> elvishjerricco: this is what set it to that
<clever> /home/clever/apps/nixpkgs/nixos/modules/system/boot/kernel.nix: [ "loglevel=${toString config.boot.consoleLogLevel}" ] ++
<clever> elvishjerricco: because this chunk, which obeys boot.kernelParameters (which sets loglevel=4) was also lost
<clever> -append "$(cat /nix/store/s3sdac10pfvddml657vz3xkpkrxp1grm-nixos-system-nixos-19.09pre179307.bc94dcf5002/kernel-params) init
<clever> elvishjerricco: its quiet by default
<clever> it disables gfx, and enables serial console
<clever> elvishjerricco: virtualisation.graphics is also the option to do exactly what you want
<clever> so it fell back to a default of /init
<clever> elvishjerricco: you overwrote the -append that sets init=/nix/store/foo
<clever> elvishjerricco: use regular boot.kernelParameters to add kernel params
<clever> elvishjerricco: remove the append bit
<clever> camsbury: aws involved any?
<clever> camsbury: double-check that it is
<clever> camsbury: is the host in your ~/.ssh/known_hosts ?
<clever> v0id72[m]: check the error logs, `journalctl -u display-manager`
<clever> v0id72[m]: cant login, or after logging in, i3 crashes, and you get signed out?
<clever> v0id72[m]: environment.etc."i3status.conf".text = ''config goes here''; i think it was
<clever> ,locate bin/dig
<clever> ,libraries Orbstheorem

2019-05-20

<clever> [root@system76:~]# nix eval nixpkgs.lib.version
<clever> "19.09pre177651.aeb464dfd37"
<clever> cizra: but my laptop does not
<clever> cizra: my desktop has libGL in /run/opengl-drivers
<clever> cizra: that will depend on if the gpu drivers have it or not
<clever> pie_: and "prebuild" the wrong one
<clever> pie_: but if you can predict what root is going to nixos-rebuild to next, you could beat them to it
<clever> pie_: so you could maliciously provide a trojaned copy of sudo, but you cant make root run it
<clever> pie_: nearly, you can basically just unpack whatever NAR you want to /nix/store/
<clever> ondrejsl: so you can either `nix-copy-closure --to root@something` or `sudo nix-copy-closure --from notroot@something`
<clever> ondrejsl: if the recieving end is a trusted user in nix.conf (root is by default), it wont check signatures
<clever> ondrejsl: or if you would rather ignore stack.yaml and get help from cache.nixos.org!
<clever> ondrejsl: so now you should have 2 ways of building it, with either cabal or stack2nix, and need to decide if obeying stack.yaml is worth the build time
<clever> ondrejsl: so -lc and -lgmp failed
<clever> ondrejsl: ah, so you forced it to be fully static, and it couldnt find libgmp.a and libc.a
<clever> ondrejsl: can you pastebin the cabal file?
<clever> ondrejsl: yeah, thats one reason i avoid stack2nix when possible
<clever> ondrejsl: https://gist.github.com/cleverca22/5918f7d6a10b66ea2d38ef09e769a676 is a very basic example, that just loads proposal-ui.cabal from . and builds it, start with that, and see how far you get
<clever> ondrejsl: i'm thinking you can just ignore stack2nix, and use normal cabal2nix
<clever> ondrejsl: looks like regular stack2nix, is the haskell source online publicly?
<clever> ondrejsl: are you doing anything weird like forcing static or cross-compiling?
<clever> ondrejsl: it cant even find -lc, something is wrong with the entire compiler
<clever> ondrejsl: why do you need to add things like pthread and gmp?
<clever> ondrejsl: the extend function takes a single overlay, and returns a new package set, that also has its own .extend
<clever> > haskellPackages.extend
<clever> ondrejsl: you can use .extend to add more overlays to things
<clever> johnw: nix-store -r /nix/store/foo -vvvvv, and then read the logs
<clever> devalot: -I can work with files and directories

2019-05-19

<clever> v0id72[m]: possibly
<clever> v0id72[m]: line 227, its commented out, and the value should be a string, not a call to callPackage
<clever> v0id72[m]: can you pastebin your configuration.nix?
<clever> v0id72[m]: what happens when you try that method?
<clever> v0id72[m]: environment.etc should be the simplest way, that will just create a file in /etc/
<clever> v0id72[m]: environment.etc."i3status.conf".text = ''config goes here''; i believe
<clever> ondrejs: and you can still get (single-cabal level) incremental building with nix
<clever> ondrejs: you can auto-generate the nix code from the stack.yaml file
<clever> only something you can build with nix-build will be portable to other nix machines
<clever> ondrejs: that still doesnt put the binary into the nix store, so it has the same problems
<clever> ondrejs: any binary you build with bare stack will break when copied to another machine, and can even break if you simply run a garbage collection
<clever> ondrejs: if you are dealing with nix on both ends, then you can just use nix-copy-closure, to copy the binary, and everything it depends on
<clever> ondrejs: i used https://github.com/nh2/static-haskell-nix as an example, it may have more info on doing it via cabal
<clever> ondrejs: here is a very stripped down (non-cabal) example of static linking on nix, https://github.com/cleverca22/nix-tests/blob/master/haskell-init/default.nix#L3-L13
<clever> talqu: nix ignores the new thing
<clever> talqu: it may be differences between your .cabl file, and whatever new-repl reads
<clever> v0id72[m]: its in the nixpkgs docs
<clever> the error mentions it looking in 4 places
<clever> Unable to find the configuration file (looked at ~/.i3status.conf, $XDG_CONFIG_HOME/i3status/config, /etc/i3status.conf and $XDG_CONFIG_DIRS/i3status/config)
<clever> i3status = super.i3status.overrideDerivation (drv: { postInstall = "cp ${./input.txt} $out/etc/i3status.conf"; });
<clever> it looks like its currently in the same package as the binary, so you need a override against the i3status package
<clever> v0id72[m]: what part do you want to change?
<clever> i just zfs for every filesystem on the box :P
<clever> ah
<clever> ekleog: ive found that its always too small for nixos, due to how /nix/store/ behaves
<clever> ekleog: thats what i initially thought it was
<clever> alexarice[m]: what are the contents of /etc/resolv.conf before&after?
<clever> dmesg?
<clever> ekleog: id say you should hit up some btrfs experts in maybe #btrfs, or switch to zfs :P
<clever> ekleog: it sounds like the host btrfs is "full" so it cant expand the disk image for the ubuntu vm
<clever> xok: https://nixos.org/nixos/packages.html is also an option
<clever> cant think of anything else to check
<clever> ekleog: does that somehow have any special permissions like quotas?
<clever> ekleog: i think /var/lib/docker/btrfs/subvolumes/648592fdb43c4df55d71f9592c2d4202d9b83dc027c10d6b5158cda8d0d4aacf is a btrfs subvolume, that it is then using as the rootfs for the docker container
<clever> ekleog: maybe just search for `mount(` in all logs, only one thing should be doing it
<clever> ekleog: this process may be inside a docker container, find the chain of ancestors (where clone() returned its pid), and then see if any of them did clone() with weird namespace related flags, or called mount
<clever> ottidmes: so you could just use deployment.keys directly
<clever> ottidmes: i have plans to add the kexec stuff into nixops
<clever> ottidmes: most of the time, i would just scp them over, or use nixops deployment.keys
<clever> ottidmes: but i can see how you cant verify the identify of the system you initially ssh into after a kexec, and it could be a malicious vm
<clever> ottidmes: for ssh private keys, i usually just let the server auto-generate random ones
<clever> ekleog: you can also do `strace -o logfiles -ff -p <something>` against the pid of the daemon
<clever> ekleog: perhaps starting with `grep ENOSPC logfile.*`
<clever> and then analyze the log to see what failed
<clever> ekleog: all i can think of then is `strace -o logfile -ff docker-compose up`
<clever> ekleog: what about the btrfs metadata stuff?
<clever> ekleog: what about `watch -d "df -h ; df -i"` while docker-compose is running
<clever> ekleog: what does `df -i` report?
<clever> marek: this will show the differences between the current system, and the current configuration.nix
<clever> 22:39 <clever> [root@amd-nixos:~]$ nix-diff $(nix-store --query --deriver /run/current-system) $(nix-instantiate '<nixos/nixos>' -A system)
<clever> marek: run nix-store --query --deriver
<clever> marek: dont need to do the full rebuild, nixos-rebuild dry-run is enough
<clever> marek: nix-diff can be used to compare 2 .drv files and see what is changing
<clever> worldofpeace: but you can add a name= to the fetchurl call to change it
<clever> worldofpeace: the default name of the derivation is based on the filename of the thing your downloading

2019-05-18

<clever> immae: see if something in that cycle is optional and can be disabled?
<clever> you could try undoing the change in quicklisp-to-nix-systems.txt, and then rebuild things and see what happens
<clever> they half removed it, and missed a file
<clever> so its actually the reverse
<clever> immae: it was removed, about a year ago
<clever> commit cd7bfa6f48295f361c691a7520fb122938bd2a68
<clever> lispPackages: drop pgloader that leads to a circular depedency
<clever> immae: checking `git log --patch`, i can see the following:
<clever> immae: looks like somebody forgot to add it to pkgs/development/lisp-modules/quicklisp-to-nix.nix
<clever> JustAnotherNixUs: also, double-check `nix show-config | grep substituters` to make sure its actually using 2
<clever> JustAnotherNixUs: if 2 caches have the same file, then it will use the priority of the cache to decide where to get it
<clever> Priority: 40
<clever> cizra: if something is purely a bandwidth task and has no computation to it, then its best to do on the client end, and not cache it
<clever> cizra: that will prevent hydra from ever building it
<clever> cizra: thats a case where i would set meta.hydraPlatforms = [];
<clever> some video drivers lack libGL for weird reasons
<clever> cizra: this is where libGL is usually found
<clever> $ echo $LD_LIBRARY_PATH
<clever> /run/opengl-driver/lib:/run/opengl-driver-32/lib
<clever> and then you have wrapProgram, which can replace a binary, with a bash script that exports vars, then runs the original binary
<clever> it may also obey the rpath on the ELF, but patchelf will shrink the rpath automatically, breaking that
<clever> cizra: whatever LD_LIBRARY_PATH is set to
<clever> > xlibs.libX11
<clever> you can tab-complete xlibs. in here, to see whats inside it
<clever> nix repl '<nixpkgs>'
<clever> including things like xf86-video-tga-1.2.2 that are flagged as broken
<clever> that will return every value on the set
<clever> cizra: [ things ] ++ (lib.attrValues xlibs);
<clever> cizra: you want an attribute of xlibs, so xlibs.something
<clever> cizra: and that is a set of all xorg packages
<clever> > xlibs
<clever> > xlib
<clever> sm: cant think of the cause then
<clever> sm: anything in /etc/nix/machines ?
<clever> sm: can you pastebin the whole content of `nix show-config` ?
<clever> sm: you can also run `nix show-config` to just print the result of reading the config
<clever> sm: /etc/nix/nix.conf
<clever> sm: do you have any ssh based binary caches in nix.conf?
<clever> neat
<clever> capnp: but something was (somehow) (indirectly) refering to it
<clever> capnp: qt, cairo, other misc things
<clever> capnp: which paths it deleted (that arent ffmpeg) would say what was to blame
<clever> infinisil: not if its in the closure of an unrelated path, that is in use
<clever> capnp: if you knew what process was to blame, you can just stop it
<clever> :D
<clever> capnp: update?
<clever> --query --roots would have to be modified to give more data