2018-07-16

<clever> tobiasBora: services.toxvpn = { enable = true; localip = "a.b.c.d"; };
<clever> tobiasBora: i also wrote my own vpn that is much simpler to manage
<clever> tobiasBora: also, tunning tcp over tcp is horrible for performance, so openvpn should never be used over tcp
<clever> it sounds like a bug within the nixos build of netcat
<clever> thats the ipv4 wildcard ip
<clever> tcp 0 0 0.0.0.0:1194 0.0.0.0:* LISTEN 28015/nc
<clever> yeah, the nc is listening only on ipv4
<clever> i prefer using socat now, since it can handle nearly every protocol
<clever> the GET request was typed by hand, and the server responded with 404
<clever> socat lets you clearly specify tcp4: or tcp6:, or just tcp: to auto-detect
<clever> HTTP/1.1 404 Not Found
<clever> [root@amd-nixos:~]# socat stdin tcp:127.0.0.1:80
<clever> GET / HTTP/1.0
<clever> maybe try socat?
<clever> and i cant see any clear reason why its doing that
<clever> so the nc your running, is connecting to that 2nd netcat, not the openvpn
<clever> tobiasBora: b: you have a 2nd instance of netcat that is listening on 1194 tcp
<clever> tobiasBora: a: openvpn is listening on udp, and netcat is tcp
<clever> tobiasBora: and also `netstat -anp | grep 1194`
<clever> tobiasBora: yeah
<clever> tobiasBora: what about `netcat 127.0.0.1 1194` ?
<clever> tobiasBora: need more of the output
<clever> tobiasBora: run it under strace
<clever> seafood: and an example of finding the direct deps of the coreutils from the gist: select path from ValidPaths where id in (select reference from Refs where referrer = 157219);
<clever> its safer if you copy db.sqlite and then poke around on the copy
<clever> seafood: just be careful when looking in that db, you can break the entire store and have to reinstall the system
<clever> and if you modify any file, it will know its corrupt
<clever> any file not listed in the db is deleted
<clever> when using the correct nix tools, it will register the path and hash of the contents
<clever> and if you just scp your own things in, nix wont treat them as valid, and will delete them
<clever> seafood: nix tracks all store files in a database, along with their dependencies
<clever> and run that copy on a machine with more ram
<clever> seafood: a second more extreme option, mount the target disk to /mnt/ (nfs?, rip it out and plug it in?), and then just --to local?root=/mnt/
<clever> but i'm not sure if it will help with memory usage any
<clever> you can then copy that to the remote machine, and reverse the copy with --from
<clever> seafood: that creates a new store at /tmp/fakeroot/nix/store/
<clever> seafood: one thing you could try: nix copy /nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29 --to local?root=/tmp/fakeroot/
<clever> think of nar as being like tar
<clever> no compression
<clever> which must hold it in a single std::string
<clever> seafood: it serializes the entire storepath as a NAR, held in a single std::string, which it then sends to the remote end
<clever> seafood: nix-copy-closure if you have ssh between them

2018-07-15

<clever> rec prevents any changes
<clever> it allows you to refer to other attributes in the same set, but also insert a function that can mutate things before you refer to them
<clever> nixpkgs.overlays = [ (self: super: { lighttpd = (import <nixpkgs-unstable> {}).lighttpd; }) ];
<clever> rk: which is what my example above does
<clever> rk: after you nix-channel --update, you can refer to it as <nixpkgs.unstable>
<clever> gchristensen: i have gotten it to work before a few years ago, but i dont remember where i left the config right now
<clever> rk: the nixpkgs manual
<clever> rk: nixpkgs.overlays = [ (self: super: { lighttpd = (import <nixpkgs-unstable> {}).lighttpd; }) ];
<clever> thats what id do too
<clever> not sure then
<clever> manveru: or `blkid /dev/md126`
<clever> manveru: what does `blkid /dev/sdg1` say?
<clever> its probably something M$ custom
<clever> manveru: M$ may have decided to use their own shit for it
<clever> manveru: are you sure its actually GPT?
<clever> manveru: and lsblk
<clever> manveru: does fdisk -l show the device size correctly?
<clever> betaboon: note that continous deployment would just break if the devs add a new package and you lack the nix expressions
<clever> teach the devs how to deploy their changes?
<clever> and if you auto-deploy to staging constantly, you risk causing permanent damage to it
<clever> some bugs only happen if the cluster has several months worth of state
<clever> and wiping it and starting over makes it not match up
<clever> it can also be important that the staging infra matches the production one
<clever> betaboon: i try to avoid continous deployment, it tends to break things
<clever> betaboon: i prefer just using nixops directly
<clever> this sub-command spits out a pair of nix files that deal with the args for you
<clever> srk: the problem is redoing all of the quotations on the args
<clever> srk: which then let you eval the cluster with normal nix tools, and skip the python
<clever> srk: this adds a custom dump command to nixos, to generate 2 .nix files
<clever> iqubic: NIX_PATH is also described in the nix-build man page
<clever> Add a path to the Nix expression search path. This option may be given multiple times. See the NIX_PATH environment variable for information on the semantics of the Nix search path. Paths added through -I take precedence over NIX_PATH.
<clever> -I path
<clever> iqubic: its exactly the same as <nixpkgs> within nix expressions
<clever> If no paths are specified, then nix-build will use default.nix in the current directory, if it exists.
<clever> if you dont specify a file, then it reads default.nix from the current dir
<clever> iqubic: that tells it to load nixpkgs from $NIX_PATH
<clever> read the man pages
<clever> to just build&install what `nix-build default.nix -A whatever` would have built
<clever> you can also nix-env -f default.nix -iA whatever
<clever> i think you can
<clever> it lets you ./result/bin/foo to test things without installing them
<clever> iqubic: that is a symlink
<clever> iqubic: if you want it in your nix-env profile, then run nix-env -i /nix/store/path
<clever> iqubic: nix-build always adds it to the store
<clever> release.nix would have to be modified to correctly set crossSystem when generating the tarball
<clever> crossSystem is an argument for import <nixpkgs> { crossSystem = ... ; }
<clever> M-liberdiko: if any element of -A foo.bar.baz winds up being a function, it will be auto-called, using the args listed with --arg
<clever> M-liberdiko: --arg doesnt work with -E
<clever> nothing special
<clever> non-root users can use any port between 1024 and 65535
<clever> 8081
<clever> Enzime: nix-shell --pure will closely emulate that context
<clever> tobiasBora: .script instead of .serviceConfig.ExecStart
<clever> tobiasBora: activation scripts run both on bootup (before network is online, before systemd has even ran), and also when you nixos-rebuild switch
<clever> its very easy for an activation script to break and stop the entire machine from booting
<clever> create your own systemd service that will do the job, and flag it to run before openvpn
<clever> oh, and id avoid using an activation script for that kind of task
<clever> systemd.services.hydra-evaluator.path = [ pkgs.jq ];
<clever> tobiasBora: you must put easyrsa in the .path for the service
<clever> tobiasBora: systemPackages are not in PATH for systemd services
<clever> ${pkgs.openvpn}/share/
<clever> 7 Failed to connect to host.
<clever> nice
<clever> i should get my nas into the same deployment
<clever> tobiasBora: the router is fairly slow and can take 5-10mins just to nixos-rebuild
<clever> i plan to add more systems to it, but havent gotten around to that yet
<clever> tobiasBora: i run it on my laptop to manage 1 system, my router
<clever> roderick: nixpkgs, under the nixos subdir
<clever> tobiasBora: yes
<clever> what would you be rsync'ing?
<clever> id keep a dir in home
<clever> tobiasBora: that would probably work

2018-07-14

<clever> YegorTimoshenko[: i think you can run it with --dry-run to get that info
<clever> you can also set buildCommand to replace all phases, or just use runCommand
<clever> Orbstheorem: unpackPhase = ":";
<clever> that one best matches nix-prefetch-url
<clever> Orbstheorem: nix-hash --type sha256 --base32 --flat
<clever> Orbstheorem: or use the right args to nix-hash i believe
<clever> !tofu
<clever> ghc is probably a dependency of a lot of ghc libs
<clever> __monty__: the toposort has priority
<clever> and it probably appears random, because that alphabetical is sorting by hash
<clever> __monty__: all dependencies of a path must exist before the path itself can be copied
<clever> sphalerite: id grep the KConfig files in the source to see where it appears
<clever> sphalerite: ah
<clever> sphalerite: and if you set it to n ?
<clever> ambro718: installPhase can just be a string, it doesnt have to be a file
<clever> iqubic: line 4-7 of the file i linked
<clever> illegalprime[m]: ah
<clever> ambro718: mkForce, one sec
<clever> ah
<clever> or that*
<clever> oh that
<clever> ambro718: set .enable = false;
<clever> illegalprime[m]: not sure if it has any way to change the policy files, but you could use a packageOverride on makeDBusConf, to customize it
<clever> /home/clever/apps/nixpkgs/pkgs/top-level/all-packages.nix- callPackage ../development/libraries/dbus/make-dbus-conf.nix {
<clever> /home/clever/apps/nixpkgs/pkgs/top-level/all-packages.nix: makeDBusConf = { suidHelper, serviceDirectories }:
<clever> illegalprime[m]: then we ned to check the source of makeDBusConf
<clever> illegalprime[m]: it has to be in share/dbus-1/services/ca.desrt.dconf.service
<clever> mupf: nix-index and nix-locate
<clever> mupf: yeah, those should be perfectly safe to remove
<clever> mupf: nix-env -e stdenv ; nix-env -e ertes-dev
<clever> mupf: why is the stdenv and a -dev package installed?, those shouldnt be there
<clever> mupf: what does nix-env -q say?
<clever> mupf: youve installed 2 versions of the package
<clever> flexw: this is how i customize the firewall: https://github.com/cleverca22/nixos-configs/blob/master/router.nat.nix#L19-L36
<clever> illegalprime[m]: /nix/store/d7vyx94x2alqq027v5f2d0ipyn7hnjh6-dconf-0.28.0/share/dbus-1/services/ca.desrt.dconf.service
<clever> illegalprime[m]: probably, and i think it should be in a subdir of share, like it would be on other distros
<clever> illegalprime[m]: it looks like you can only impact it by setting .packages, and then line 13 will generate the config
<clever> ambro718: into the config section
<clever> ambro718: buildUsers will always be big enough to support maxJobs
<clever> ambro718: yes
<clever> ambro718: disabledModules = [ "services/networking/ntpd.nix" ];
<clever> ambro718: yes
<clever> on .source itself i think
<clever> gchristensen: it may need an mkForce
<clever> tenten8401: you have to set .source, check gchristensen's example again
<clever> sphalerite: i think there was a related bug, where it restarts something like dbus, which causes your session to crash
<clever> tenten8401: thats how all derivations work
<clever> tenten8401: wrap it in "${....}"; to convert it to a string
<clever> gchristensen: fortune is designed to produce a random quote from a DB
<clever> gchristensen: the issue, is that the contents have to be different every time you login
<clever> tenten8401: you can then put a copy of it into imports, and freely edit that copy
<clever> tenten8401: if you put something like this into configuration.nix, the entire ntpd.nix stops working
<clever> disabledModules = [ "services/networking/ntpd.nix" ];
<clever> tenten8401: or disable the entire module
<clever> tenten8401: i believe you have to override it, .serviceConfig = mkForce { ExecStart = ...; };
<clever> tenten8401: setting .script will try to set ExecStart to a string, and 71 already sets it to a list
<clever> tenten8401: oh wait, line 71! its a list
<clever> i'm not sure how it works at all
<clever> tenten8401: something within the nixos modules has set an invalid option on that
<clever> tenten8401: i also get that error, even without your config
<clever> tenten8401: can you gist your configuration.nix file and the exact error?
<clever> i have thought of doing it with github archive tars before
<clever> i believe that will load the default.nix in that file
<clever> this is also why i avoid nix-collect-garbage -d
<clever> the roots in profiles can just be made with ln
<clever> ambro718: correct
<clever> kalbasit: and once you find the attr path, nix-build nixpkgs/pkgs/top-level/release.nix -A tests.cc-wrapper.x86_64-linux
<clever> kalbasit: `nix repl nixpkgs/pkgs/top-level/release.nix` and then eval tests
<clever> iqubic: you need to build it with nix, and then install it with nix-env
<clever> iqubic: nix doesnt know about those executables, and will GC away the deps, and break them
<clever> kalbasit: that sounds more like a nixpkgs test, rather then a nixos test, so it should be in the pkgs/top-level/release.nix i think, and the derivation should just fail if the test fails
<clever> infinisil: id expect it to break when you GC

2018-07-13

<clever> kalbasit: run `nix repl nixos/release.nix` and then type in `tests`
<clever> iqubic: services.xserver.displayManager.sessionCommands
<clever> iqubic: xserver sessionCommands
<clever> kalbasit: run nix repl on that file and eval tests to poke around
<clever> kalbasit: they are attributes on nixos/release.nix
<clever> it can also be done with a --option flag, but i havent used that one much
<clever> tobiasBora: that is a user@host, the arches it supports, the path to an unencrypted ssh private key, and then how many parallel builds it can support, the relative speed, and features
<clever> builder@192.168.2.126 armv6l-linux,armv7l-linux /etc/nixos/keys/distro 1 1 big-parallel
<clever> tobiasBora: you need to create a /etc/nix/machines file with a line like this:
<clever> tobiasBora: is this on debian or nixos?
<clever> tobiasBora: now you need to setup a build slave
<clever> tobiasBora: what about if you do nix-store --optimize ?
<clever> tobiasBora: ah, and 2gig isnt much, i think you just need more free space
<clever> tobiasBora: only 10?
<clever> tobiasBora: and nix-store --query --roots /nix/store/ypb81gsazzicrb004k06xr75vkf9q1wc-rustc-1.26.2
<clever> tobiasBora: what is the output of the above du command?
<clever> Lisanna++
<clever> tobiasBora: there may also be a lot of wasted space in /nix from old nixos builds, can you pastebin du --max=1 -hc /nix/store/ | sort -h
<clever> tobiasBora: the real error is above that
<clever> it will also cache reads, so the read side is less of an issue
<clever> and after a nix channel update, it has to replace everything
<clever> it will stop affecting all future writes
<clever> and nix wont let you delete things that are inuse, or write to them again
<clever> it will only update if you re-write the data to disk
<clever> it will leave it compressed
<clever> nope
<clever> i just noticed that my /nix/ had compression off, so all of my recent downloads have been uncompressed
<clever> just keep in mind that it only effects the writes that occur when enabled
<clever> tenten8401: so if you dont like the cost, just turn it back off
<clever> tenten8401: you can freely turn compression on and off without reinstalling
<clever> infinisil: and in this summer weather, the cpu load from steam downloading a game managed to put me into thermal shutdown, lol
<clever> tenten8401: but no other program does that, they seem to all do single-threaded writes
<clever> tenten8401: then steam does a multi-threaded disk write to download a game, it cripples my machine :P
<clever> and some of my volumes are halved by the compression
<clever> amd/vbox 1.98x 31.4G 58.7G
<clever> NAME RATIO USED LUSED
<clever> so i actually have 72gig of data in /nix/
<clever> i also have zfs compression enabled
<clever> amd/nix compressratio 1.21x -
<clever> then youll fall in love with it
<clever> you just need to accept that your /nix directory is going to be 60gig :P
<clever> tobiasBora: optimizing the store also deduplicates it, nix-store --optimize
<clever> tobiasBora: it can still garbage collect the extra one
<clever> tobiasBora: correct, it will only impact nixops
<clever> that forces nixops to always use that revision of nixpkgs
<clever> # nixops modify -d router -I nixpkgs=https://github.com/nixos/nixpkgs/archive/ce0d9d638de.tar.gz deployments/router_deployment.nix
<clever> thats why i pin the nixpkgs in the deployment config
<clever> yeah
<clever> also of note, if your nixpkgs rev is different, then it will be upgrading the rpi, so it has to download everything anyways
<clever> yeah
<clever> nixpkgs.localSystem.system = "aarch64-linux"; i think
<clever> if you have set the arch to arm, yeah
<clever> and then it will crosscompile EVERYTHING
<clever> it will only crosscompile if you configure nixops to crosscompile
<clever> or you can try the cross-compiling stuff, which is a bit more untested
<clever> yes
<clever> tobiasBora: no mater what, it must build at least a few of the files
<clever> tobiasBora: it must still build config files like /etc/hosts
<clever> tobiasBora: nixops is also specialized a bit more around the machine running nixops being able to do builds, but it can also use build slaves in the case where you cant
<clever> tobiasBora: if you are deploying to 2 raspberry pi's, the laptop will download it once, then copy it to both pi's
<clever> if you dont enable rollback support, then it can be GC'd
<clever> yeah
<clever> the machine running nixops will usually also be caching everything, so it only has to happen once
<clever> thats just the way nix and nixops work
<clever> tobiasBora: nixops builds it locally (or on a build slave), after evaling it locally
<clever> tobiasBora: and this includes config files, which must be built on an arm device
<clever> so when building something like the system-path directory, it must have a copy of every program in system-path
<clever> when building any derivation, all of its inputs must exist
<clever> which may be faster if your internet modem is the bottleneck
<clever> it would download from the rpi->laptop
<clever> tobiasBora: if you set the rpi up as a binary cache, it can
<clever> tobiasBora: if you can paste the storepath of one of the programs it downloads, i can check its arch
<clever> tobiasBora: if youve set the arch right in nixops
<clever> tobiasBora: yeah
<clever> tobiasBora: and all dependencies must exist before it can create something that depends on them
<clever> tobiasBora: it doesnt know what the pi needs until after it has recreated the entire os
<clever> iqubic: probably
<clever> i always enable it
<clever> pure xfce
<clever> grp: echo $buildInputs or echo $nativeBuildInputs
<clever> so if i spin up a second machine with slightly different boot config, it cant conflict
<clever> manveru: i keep the bare minimum required to boot in configuration.nix, and put the rest into what you have named kappa.nix
<clever> manveru: yeah, i do things like that
<clever> logzet: a git repo at /etc/nixos/nixcfg/
<clever> yeah, for that, you would need an activation script or a systemd unit
<clever> d1rewolf: you generally configure all the users from configuration.nix
<clever> yeah
<clever> ive not tried aarch64 yet
<clever> tenten8401: qemu-user lets an x86 machine run arm binaries
<clever> tenten8401: yeah, and with qemu-user, you can do it without emulating the kernel
<clever> tenten8401: yeah, but there is no binary cache support, so it takes a lot fo compiling
<clever> d1rewolf: i now have nixos on my desktop, 2 laptops, NAS, router, and a raspberry pi
<clever> :D
<clever> you may need the target version to compile against, and the host for the build scripts
<clever> samueldr: yeah, perl and python are examples of that
<clever> not sure how the automated patching handles things like #!/usr/bin/env
<clever> i think if you want it at runtime you need to embed ${pkgs.perl}/bin/perl somewhere
<clever> samueldr: yeah
<clever> tenten8401: when cross-compiling, it will get the buildInputs from the target device and use the host for nativeBuildInputs

2018-07-12

<clever> logzet: its in /topic
<clever> logzet: what changed?
<clever> infinisil: yep