2019-02-10

<clever> simpson: yep
<clever> das_j: on newer versions of nix, its /build/
<clever> das_j: yeah, builds have their own private `lo` they can listen on, so you dont have to do anything special
<clever> das_j: they only see `lo` with the normal 127.0.0.1
<clever> das_j: normal builds are, fixed-output are not
<clever> Thra11: i use `runhaskell Setup.hs configure` and then `runhaskell Setup.hs repl`
<clever> s/@/!/
<clever> sondr3: something neat you can do that most others cant, you have a working machine to compare against, or even swap hdd's between@
<clever> yep
<clever> sondr3: `alsamixer -c 0`, on the capture tab,lets you select the capture source, but yeah, it could also be a wiring fault
<clever> sondr3: and plugging something in, triggers a input event (like a keyboard or joystick(
<clever> Event: time 1549806247.693860, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 1
<clever> on my machine, i see 2 mic input sources
<clever> /dev/input/event5: HDA ATI SB Rear Mic
<clever> /dev/input/event4: HDA ATI SB Front Mic
<clever> sondr3: run this
<clever> nix run nixpkgs.evtest -c evtest
<clever> sondr3: one min
<clever> that is odd
<clever> sondr3: and on nixos, does `lsmod | grep snd_hda_intel` list it?
<clever> sondr3: lspci -k tells you what driver it is
<clever> sondr3: also, see what driver arch is using, and try to modprobe it on nixos
<clever> sondr3: check the profiles on the configuration tab, in pavucontrol
<clever> ive found that kde has a lot of bloat, it installs a crap-ton of things when enabled
<clever> fuzzy-id: i use xfce for all of my systems
<clever> ew! :D
<clever> ah
<clever> gchristensen: how does it fail?
<clever> dunk: nix disables all network access during the build, something must be wrong for it to want to download a file

2019-02-09

<clever> bpye: samba is also an (ugly) solution, just map the remote disk to the windows box
<clever> bpye: ive also made a vim.nix that includes all of my standard config and plugins, so i just `nix-build vim.nix -o vim` and `./vim/bin/vi` and it works 100% like the local one
<clever> bpye: i always use vim, so i just run vim under ssh
<clever> bpye: i have a central dedicated machine i always run nixops on, and ssh to that
<clever> mobile_c: yeah
<clever> bpye: nixops works on any linux distro, and darwin, just install nix

2019-02-08

<clever> super.callHackageDirect { pkg = "derive"; ver = "2.6.5"; sha256 = "0000000000000000000000000000000000000000000000000000"; } {};
<clever> and i think it may also need another {} at the end, like all callpackage based things
<clever> the error will then tell you the right hash
<clever> NemesisD: so i would start with super.callHackageDirect { pkg = "derive"; ver = "2.6.5"; sha256 = "0000000000000000000000000000000000000000000000000000"; };
<clever> ,tofu
<clever> NemesisD: yeah
<clever> rodarmor: `man systemd.service` for more info on it
<clever> rodarmor: PermissionsStartOnly makes the User= only apply to ExecStart, so pre-start runs as root
<clever> rodarmor: but there is an extra flag to make prestart run as root instead
<clever> rodarmor: normally, the User= you specified in your unit
<clever> rodarmor: anything done with a derivation becomes world-readable, since all of /nix/store can be read
<clever> rodarmor: that also lets you fully control who can read the secret, by just using chmod and chown correctly
<clever> rodarmor: you could have a preStart script on its systemd unit, that will generate the random token, if it doesnt exist yet
<clever> infinisil: oh, nice, thats perfect
<clever> NemesisD: only goes up to 2.6.4 on my nixpkgs, what about yours?
<clever> NemesisD: nix-build '<nixpkgs>' -A all-cabal-hashes -o all-cabal-hashes.tar.gz && tar -tvf all-cabal-hashes.tar.gz | grep derive
<clever> NemesisD: so you must run cabal2nix on it manually, and load the result with callPackage
<clever> NemesisD: 2.6.5 isnt in the all-cabal-hashes.tar.gz file
<clever> rodarmor: but if it needs to be constant for the life of the machine, just ask the user to fill it in on the config, or things will randomly "break"
<clever> rodarmor: you could use something like pkgs.runCommand, and just hexdump /dev/random
<clever> mobile_c: try doing that
<clever> mobile_c: did you try copying the squashfs to the main fs, like i said?
<clever> NemesisD: also, (./deps/gogol + "core") is identical to ./deps/gogolcore, you need a / inside the string
<clever> NemesisD: when you use + to combine a path and a string, the new value is also a path
<clever> in general, i try to keep it as a path type as long as possible, so just (./deps + "/gogol/core")
<clever> but those outer quotes are just to force it to copy, for demo purposes
<clever> if that | was a +
<clever> "${./deps | "/gogol/core"}" will copy just core
<clever> "${./deps}/gogol/core" will copy all of deps
<clever> unquoted paths are a special type, and it will copy the smallest subtree it can, when you treat it as a string
<clever> ./deps + "/gogol/core"
<clever> including the outer quotes
<clever> NemesisD: open up `nix repl` and then try to evaluate: "${./deps/gogol/core}"
<clever> ah, but the bot has too many safeties
<clever> > "${ ./. }"
<clever> quoting paths disables all of the magic that makes them work
<clever> and then the path just doesnt exist at build time
<clever> so nix didnt copy the path into the sandbox
<clever> i think the problem, is that you gave it a string with no context
<clever> paths like that, are relative to the file the path is within
<clever> self.callCabal2nix "gogol-core" ./deps/gogol/core {};
<clever> nix can handle relative paths on its own
<clever> NemesisD: just use ./deps/gogol/core
<clever> sicklorkin: adjust your configuration.nix so it expects /nix to be at the new place, and nixos-rebuild boot, so it doesnt break after you move it
<clever> sicklorkin: after that, its just a matter of pre-doing `nixos-rebuild boot` with new cfg that expects /nix to have been moved, then rebooting, and moving it
<clever> sicklorkin: basically, you just add ./rescue-boot.nix to your imports section, nixos-rebuild (and pray you have ~300mb free on /boot/), and then you can run the installer from grub at any time
<clever> i used that to move my /nix from / to its own dataset, on zfs
<clever> this allows me to boot into a secondary OS, that lives entirely in /boot/
<clever> symphorien: thats why i made rescue-boot.nix
<clever> dmj`: open release.nix in nix repl first, and look at the build attr
<clever> dmj`: yes
<clever> dmj`: just use the release.nix inside that commit
<clever> dmj`: src is an .overrideAttrs level arg
<clever> dmj`: because .override is only for callPackage level args
<clever> mobile_c: oops, its boot.shell_on_fail, not allow_shell
<clever> mobile_c: you must add boot.allow_shell to the kernel cmdline
<clever> copy it out of the iso
<clever> mobile_c: as i said, you must copy nix-store.squashfs to your usb stick
<clever> mobile_c: not a path
<clever> mobile_c: it must be a linux device, like /dev/sda1
<clever> dmj`: the version your pinning to might be too new
<clever> dmj`: it can, `nixops create -I nixpkgs=...` or `nixops modify -I nixpkgs=...`
<clever> mobile_c: no, the fs that is directly on the usb stick itself
<clever> mobile_c: the fs on the usb stick
<clever> mobile_c: the file i linked earlier generates one
<clever> mobile_c: the nixos initrd doesnt understand that, so you need to copy the squashfs out of the iso, and then give it the label of your real fs
<clever> mobile_c: it would be the uuid or label of the filesystem on the usb stick
<clever> dmj`: not that i'm aware of
<clever> dmj`: thats what the tests on hydra prevent
<clever> yeah
<clever> mobile_c: /dev/root is a symlink, based on the root= param passed to the kernel
<clever> dmj`: 18.09 was forked off a version of master, on 2018-09, and then has had fixes cherry-picked into it to make it more stable
<clever> mobile_c: maybe, but i suspect it to fail, because the initrd is expecting to find the squashfs on an iso9660 FS
<clever> the squashfs gets mounted to /nix/store/ by the initrd scripts
<clever> it has to start with /nix/store/
<clever> mobile_c: do you not have a spare USB stick you can put the original nixos ISO on, as the only thing?
<clever> not that i know of
<clever> mobile_c: the nix script will insert the right path as it builds the file
<clever> mobile_c: /nix/store/giantasslonghash-something/init
<clever> mobile_c: its not at /init, so that will fail
<clever> mobile_c: the init file is inside the squashfs on the iso
<clever> dmj`: but nixpkgs-unstable still updated, and people using it on nixos corrupted grub.cfg
<clever> dmj`: about a year ago, grub was broken, and nixos-unstable correctly stopped updating
<clever> dmj`: nixos-unstable has extra tests to make sure it wont brick a nixos machine
<clever> dmj`: both nixpkgs-unstable and nixos-unstable follow the latest commit from master to pass a certain set of tests
<clever> dmj`: correct
<clever> mobile_c: or just dd the entire iso directly to the USB stick
<clever> mobile_c: so you need to build the initrd correctly
<clever> mobile_c: the problem is inside the initrd, it expects a partition with a certain name, and certain files
<clever> mobile_c: you can install nix on any linux distro, or even darwin (though darwin cant build the file i linked)
<clever> dmj`: yes
<clever> mobile_c: `curl https://nixos.org/nix/install | sh` i think it was
<clever> mobile_c: the file i linked can be built on any linux distro that has nix installed
<clever> dmj`: you can use the latest nixos-unstable for both
<clever> and it will work when jammed into a random partition
<clever> it generates a kernel, initrd, and a fragment of your grub cfg
<clever> mobile_c, samueldr: thats what i wrote https://github.com/cleverca22/nixos-configs/blob/master/multi-boot-helper.nix for
<clever> dmj`: check the channels.nix.gsc.io link the bot just posted, that shows the history for every channel
<clever> dmj`: you must only use revs that the nixos channels have been pointing to
<clever> dmj`: it might have even been using nixpkgs-unstable, which can brick nixos machines sometimes
<clever> dmj`: you simply failed to pin nixpkgs, and travis has likely been upgrading the machine randomly, every time the channel updated
<clever> dmj`: nixops itself was pinned, but not nixpkgs
<clever> mobile_c: how did you copy the iso file to the usb stick?
<clever> NemesisD: the part starting at 6141 is the git rev
<clever> "19.03pre158246.6141939d6e0"
<clever> [clever@system76:~]$ nix eval nixpkgs.lib.version
<clever> NemesisD: i typically just pick whatever rev my system is currently on, and if it works, i stay on that
<clever> ,tofu NemesisD
<clever> dmj`: export NIX_PATH=nixpkgs=${pkgs.path}
<clever> dmj`: the nixpkgs its finding is too new
<clever> dmj`: nixops uses NIX_PATH to find nixpkgs
<clever> dmj`: thats your problem
<clever> dmj`: and do you update NIX_PATH?
<clever> 2019-02-08 14:38:10 < DHE> yeah, well, my company has a 1/2 petabyte (roughly) array... so there's that.
<clever> oops, wrong button
<clever> 2019-02-08 14:36:16 < malwar3hun73r> i have 2... lol
<clever> 2019-02-08 14:29:19 < DHE> the search thing is kinda important when your pool is made of 122 hard drives. :)
<clever> dmj`: can you gist that nix expression?
<clever> dmj`: how did you pin nixpkgs?
<clever> dmj`: is the pinned nixpkgs in NIX_PATH?
<clever> dmj`: your nixpkgs is too new
<clever> dmj`: nixpkgs isnt
<clever> tilpner: try mkAfter instead?
<clever> adding a second util-linux to systemPackages will just install both sets of files, and ignore collisions
<clever> tilpner: then you have 2 util, and one still gives rename
<clever> tilpner: if you override util-linux, it can mass-rebuild, because a lot of things use those utils at build time
<clever> you want to force it to come before the util-linux your not altering
<clever> tilpner: file-rename
<clever> either mkBefore, or mkAfter, will put your custom thing at a higher priority, and overwrite util-linux's
<clever> and then dont override util-linux at all
<clever> environment.systemPackages = lib.mkBefore [ ... ];
<clever> tilpner: try mkBefore on systemPackages
<clever> Edes: you can see the 3 options being defined in qemu.nix
<clever> Edes: as a module, and enable qemu-user.aarch64 = true;, or whichever arch you want
<clever> Edes: then, after booting the rpi again from that, you can just run `/nix/store/foo/bin/switch-to-configuration switch`, on the storepath it created
<clever> Edes: this will act on the FS mounted to /mnt/img/, update the system profile, to the result of building configuration.nix, for aarch64-linux (you may want to change it to armv6 or v7, depending on your OS
<clever> 2019-01-31 15:45:04< clever> NIX_REMOTE=local?root=/mnt/img/ nix-env --profile /mnt/img/nix/var/nix/profiles/system --set -f '<nixpkgs/nixos>' -A system -I nixos-config=/mnt/img/etc/nixos/configuration.nix --option system aarch64-linux
<clever> finding it...
<clever> you need a special command to build it for arm
<clever> then....
<clever> Edes: that will magically allow you to run arm binaries on an x86 kernel, without having to emulate an entire arm system
<clever> Edes: git clone this, then add /path/to/nixos-configs/qemu.nix to your imports list on an x86 nixos host
<clever> Edes: ive chroot'd into an rpi before
<clever> and `nix-store --restore ./path` will write the nar from stdin to path
<clever> yayforj: but you can also use it yourself if you want, `nix-store --dump ./path` will spit the path out stdout as a NAR
<clever> yayforj: yeah, its only used by the binary cache api, to store things on the cache and download them
<clever> yayforj: its like a tar, but without timestamps, uid, or write bits
<clever> it will refuse to even evaluate the expression
<clever> siers: just set meta.platforms correctly, examples should be in nixpkgs
<clever> Taneb: cant see any obvious reason for it to fail
<clever> into a pastebin
<clever> Taneb: stat /nix/store/.links/16ixs5l71x42vrsknxx9gbmhy783js34x736rxk5bqz94q047qzz
<clever> i think
<clever> same limitations exist within nix files
<clever> typetetris: it has to start with a normal attrset
<clever> typetetris: pkgs."a-b".meta
<clever> colemickens: the result link itself is a root, and switch/test will update /run/current-system, which is another root
<clever> colemickens: nix-store --query --roots

2019-02-07

<clever> infinee: i think direnv just automates changing env vars when you run `cd`
<clever> your going to have to brute-force the keypair if you want in :P
<clever> and disable password auth entirely
<clever> i just have an ssh key on all of my machines, that has root to all other machines
<clever> if you have a second private key to root, you can safely loose that
<clever> the only thing the state file has at that point, is the nixops private key
<clever> everything it needs to find the machine is in the nix files
<clever> yeah
<clever> similar to how you converted nixos to nixops
<clever> and re-deploy
<clever> as long as you have a way to get root on each box, you can just make a new deployment (with the same nix files) on any machine
<clever> if you are purely using the "none" backend, then you dont really need to keep the state file
<clever> because nixops could forget about machine, and then it just stay running, running up a bill
<clever> if your using anything cloud based in nixops, a merge conflict is likely to cost you massively
<clever> safer/simpler to just keep backups with something like tarsnap
<clever> suzu: i keep the state file on a single central machine, and dont copy it around any
<clever> suzu: can you pastebin the modified file?
<clever> so it will fail 100% of the time
<clever> but, we have an assert, that is hard-coded to false
<clever> yep
<clever> suzu: and `assert expr false; expr` will throw an exception and cause it to fail hard
<clever> suzu: they should be, but you need to parse this line of code to know if its a function or not
<clever> yeah
<clever> suzu: ive memorized a scary amount of it...
<clever> suzu: i get bored, and read all the files in nixpkgs
<clever> suzu: system.extraSystemBuilderCmds is an internal option in nixpkgs, that is involved in building what lands at /run/current-system/
<clever> your existing configuration.nix should also have an imports in it
<clever> yeah
<clever> sicklorkin: is there a shell.nix or default.nix in the same dir?
<clever> suzu: its a nixos module, that sets 2 nixos options, nix.nixPath and system.extraSystemBuilderCmds
<clever> sicklorkin: what args did you give it?
<clever> and it will remap <nixpkgs> on the target to match whatever nixops was using during the deploy
<clever> it will break nixos-rebuild with a clear error
<clever> like imports = [ ./nixops-managed.nix ];
<clever> suzu: add this to your imports list in the nixops config
<clever> suzu: one sec
<clever> and if you do nixos-rebuild by accident, it will undo whatever nixops was doing, and restore whatever configuration.nix says should exist
<clever> suzu: nixops ignores it entirely
<clever> suzu: correct
<clever> suzu: you can use declarative containers on nixos
<clever> suzu: ive used it to deploy 100's of servers in a single sitting
<clever> users.users.root = { ... };
<clever> same way, for root
<clever> yeah
<clever> suzu: after deploying, it will let itself in with its own ssh key
<clever> suzu: it will need root ssh to do the first deploy, either via a pw, or an ssh key in the ssh-agent
<clever> you can also just `import <nixpkgs> { system = "i686-linux"; }`
<clever> the pkgsi686Linux set forces 32bit builds using the native 32bit->32bit compiler chain
<clever> > pkgsi686Linux.hello
<clever> petersjt014: dont need the cross-compile flags
<clever> fresheyeball: compare line 57 and 90 of the file i linked
<clever> fresheyeball: oh, so it does, lol
<clever> and since its in a file, you dont have to deal with escaping
<clever> fresheyeball: passAsFile tells nix to put the entire string into a file, and give you xPath instead
<clever> fresheyeball: you want `{ x = ''....'; passAsFile = [ "x" ]; .... mv "$xPath" $out ; test $out .... }
<clever> `nixops create` also accepts `-I nixpkgs=` and will remember it the same way
<clever> so it will be remembered until you delete the deployment
<clever> suzu: the `nixops modify` command will save that into the nixops state file
<clever> suzu: -I nixpkgs... forces it to use a specific version, rather then what your system currently has
<clever> suzu: and your current nixpkgs is too new, causing it to break
<clever> fresheyeball: you may also want to look at how writeText works
<clever> fresheyeball: bash will treat that as multiple lines, and execute the 2nd line onward, so you need `echo "${x}"`
<clever> suzu: it needs a copy of nixpkgs to build nixos and deploy it
<clever> fresheyeball: yeah
<clever> suzu: prepends an entry to NIX_PATH, so when nixops looks for <nixpkgs>, it uses that url
<clever> fresheyeball: you could just convert it to runCommand
<clever> suzu: oh, i missed an archive in there
<clever> that will create a /nix/store/hash-nix.conf, then symlink nix.conf to it for testing
<clever> fresheyeball: line 68 mostly does what you want
<clever> suzu: does `nixops info` work now?
<clever> suzu: like that
<clever> nixops modify -d trivial trivial.nix -I nixpkgs=https://github.com/nixos/nixpkgs-channels/nixos-18.09.tar.gz
<clever> nixops modify -d trivial trivial.nix -I nixpkgs=URL-TO-NIXPKGS
<clever> suzu: youll either want to install nixops master, or use an older nixpkgs
<clever> suzu: ah, the fix was merged into nixops 8 hours ago, but thats not 1.6.1, its a pre-release for the next version
<clever> oh, got distracted, *looks*
<clever> suzu: can you pastebin that file, and the full output from `nixops info --show-trace`
<clever> fresheyeball: systemd is a package in nixpkgs
<clever> does it list the nix files?
<clever> oops, does it output anything else?
<clever> suzu: what does `nixops info` say?
<clever> so it can update faster, but you may need to compile some things
<clever> the channel can update before hydra has built every single package
<clever> and {^_^} just mentioned (about 30mins ago) that nixos-unstable-small had updated
<clever> this site lists how old each channel is
<clever> ,howold
<clever> suzu: try: `nix-channel --add https://nixos.org/channels/nixos-unstable-small nixos-small` and then `--update` and `nix-env -iA nixos-small.nixops`
<clever> suzu: did you recently do `nix-channel --update` ?
<clever> suzu: if you are on nixpkgs-unstable, it should just be a matter of nix-env -iA nixpkgs.nixops
<clever> > nixops.version
<clever> > "${systemd.out}/bin/systemctl"
<clever> yep
<clever> hence, the sandbox just doesnt work, when nix isnt built by nix

2019-02-06

<clever> you would need to add every binary that fails, and map them to something
<clever> it doesnt give you /bin/mkdir