2017-08-15

<clever> check the aws security groups for the ec2 instance
<clever> port 80 is either firewalled or nginx is down and the firewall is blocking "connection refused"
<clever> atis_: connection timed out
<clever> a few /dev entries get copied over, potentialy /dev/kvm, some /proc symlinks get setup, and a few /etc files
<clever> ixxie: and here is more of the chroot setup: https://github.com/NixOS/nix/blob/master/src/libstore/build.cc#L2382
<clever> atis_: is that a public ip?, i could test things faster if i knew the domain
<clever> ixxie: and that reminds me, it will even spoof a 32bit only kernel, if the build is targeting 32bit x86
<clever> ixxie: in this area of the code is where it does it all
<clever> what about the dns, router, nat, port fortwarding, and firewalls?
<clever> is port 80 on your domain pointing to the nginx?
<clever> what does "systemctl status nginx" say?
<clever> it should have auto-started
<clever> atis_: yes
<clever> ixxie: more about how the differences between the sandbox and normal env are making it less reproducable, in that the stable env lacks things that snmp expected every distro to have
<clever> atis_: nixos will create services to do it automatically, watch "journalctl -f"
<clever> nwuensche: i dont think it changes any file, it sets a variable within the xserver process
<clever> something creates a self-signed example.com cert to fill the gap
<clever> simpson: but you also cant make certs until nginx is up
<clever> letsencrypt needs the nginx to be up before it can create the certs
<clever> atis_: can you gist the output of "ps -eH x", that should say why its hung
<clever> and there was a haskell testcase i saw fail lastnight, where it tried to just "cd /home", and that also fails
<clever> but if built without sandboxing, it works fine
<clever> ixxie: nix sandboxes lack /etc/mtab, so snmp configures itself to open the literal file "unknown" when finding mounts
<clever> ixxie: i also discovered, snmp builds will peek around in /etc to see if you have a /etc/mtab file, and setup the build properly
<clever> including ~2 minutes after the initial rebuild-switch
<clever> yeah, nginx will need a restart after each renew
<clever> atis_: the nginx LE stuff is amazingly simple, just https://nixos.org/nixos/options.html#enableacme
<clever> phdoerfler: that should automaticaly pop it into /etc/ssl/certs and run the rehash for you
<clever> nwuensche: ps aux | grep xserver
<clever> kiloreux: you need to put the opencore derivation into the buildInputs of ffmpeg
<clever> and you configure the entries using efibootmgr, which writes to flash memory
<clever> i think efi supports multiple efi system partitions
<clever> Phillemann: i think efi has native support for that, but ive not messed with it
<clever> i clone it once from the installer, directly to /mnt/etc/nixos/
<clever> i leave nix-channel in control of that
<clever> and i keep all of that in a subdir of /etc/nixos/
<clever> same
<clever> so the stuff specific to the actual hardware isnt controlled, because it will change with every install
<clever> and then configuration.nix just contains the bare minimum to boot (where / and /boot are and such), along with imports = [ ./nixcfg/hostname.nix ];
<clever> i have a nixcfg folder with all of the configs, named after each host
<clever> yeah
<clever> i git clone from the install cd, so nixos-install does everything at once
<clever> selecting is faster then select, copy
<clever> i just always use the selection buffer
<clever> it pastes whatever you selected, not what you copied
<clever> thats the selection buffer
<clever> though some terminals like xterm just dont support the clipboard at all, and only work via the selection buffer
<clever> but ctrl+c is special in a terminal, so most of them rebind paste to ctrl+shift+c/v
<clever> and a normal clipboard (ctrl+c, ctrl+v)
<clever> a selection buffer (whatever you select, middle click to paste)
<clever> linux has 2 clipboards
<clever> adelbertc: try the last cmd dtzWill gave
<clever> yeah, so there should be a channel called nixos-unstable that nix-env can access
<clever> ls is weird like that when you use -l
<clever> with the extra / at the end
<clever> adelbertc: what does this say?
<clever> ls ~/.nix-defexpr/channels/ -lh
<clever> ah wait, i was checking an old nixos-unstable
<clever> alacritty doesnt exist in nixos-unstable
<clever> i checked, alacritty isnt an attribute in nixos-unstable
<clever> dod you nix-channel --update ?
<clever> nix-env -iA nixos-unstable.alacritty
<clever> after --add, you need to --update
<clever> that tells it to use the channel called nixos
<clever> if you do nix-env -iA nixos.hello
<clever> adelbertc: i usualy try to stick to one
<clever> rnhmjoj[m]: ah
<clever> which testing library is it?
<clever> if thats not possible, then just disable the tests
<clever> then we still get coverage and it works for everybody
<clever> like the directory its building in
<clever> if possible, id modify the tests to use a directory that is known to exist at build time
<clever> rnhmjoj[m]: hmmm, whats up with that random seed at the end?, why is there any rng in here?
<clever> rnhmjoj[m]: yeah, all builds on hydra are ran under a container, no /home folder and $HOME points to the /homeless-shelter
<clever> i wonder, if you do foo = ./symlink; and the symlink points into the store, it may just reuse the store path, since its already immutable
<clever> catern: dont think ive seen that anywhere
<clever> if the nix expressions are in the same dir as the source, you can src = ./foo;
<clever> only if you set the sandbox mode to relaxed, then you can opt-out on a per-derivation basis
<clever> so its on by default, and you can opt-out
<clever> where you can specify in the derivation that you want it off
<clever> oh, but there is a relaxed mode
<clever> and then it can be hard to figure out why
<clever> if sandboxing is off, you can do things the wrong way, and it will half work
<clever> your also trusting that packages havent been written poorly
<clever> the main hydra also has sandboxing enabled, so it wont get binary cache support from nixos
<clever> then git cant even clone
<clever> if sandboxing is enabled, a lack of a sha256 will disable the network
<clever> adisbladis: it has a fetchSubmodule option
<clever> and stores that into a file nix can load
<clever> the most you can do is create a script that pre-runs nix-prefetch-git over each hash
<clever> nix barely even understands how fetchurl works
<clever> and nix doesnt understand how git works
<clever> all network io needs a hash of the resulting output, so nix can know when things have changed and how to reproduce it
<clever> ah
<clever> ah
<clever> catern: submodules?
<clever> it sounds simpler to run the proper install script, then set the right env variables, then to build it from scratch
<clever> cbarrett: what files are present under /nix/var/nix/profiles/ ?
<clever> what was the main problem again, as to why you cant install nix normally?
<clever> powerpc64?
<clever> the install script gets around that bootstrap problem by just unpacking a pre-made nix tarball to /nix/store/
<clever> which will build nix (from nixpkgs) using nix, and add it to the profile
<clever> nix-env -f '<nixpkgs>' -A nix -i
<clever> cbarrett: it comes from having the nix package installed with nix-env
<clever> lrwxr-xr-x 1 root wheel 69B Dec 31 1969 /nix/var/nix/profiles/default/etc/profile.d -> /nix/store/gs2z548x41ah2h8fqnbn87syzazrlsb8-nix-1.11.12/etc/profile.d
<clever> cbarrett: if you run ls -lh on that, what does it say?
<clever> the signing stuff is tricky to get working and doesnt always work in obvious ways
<clever> when root is on the receiving side, it doesnt check signatures
<clever> Fare: try running it without --sign, as root
<clever> Fare: what args did you give to nix-copy-closure?
<clever> Fare: what error does it fail with?

2017-08-14

<clever> you would need to fetch the same nixpkgs hydra/channel has
<clever> yeah
<clever> it can also optionaly GC root each drv it creates
<clever> and it will populate the host store with those drv's
<clever> bennofs: this requires no special config on the host, and will spit out a json mapping job names to drv files
<clever> bennofs: simplest thing i can think of is to just repeat the eval locally, run hydra-eval-jobs on the same release.nix
<clever> was going to bring up nix-index, then i remembered the github url, lol
<clever> yeah
<clever> but that wont help with build-time only deps
<clever> bennofs: and once you have that from either source, you can query each narinfo on the binary cache, to form the runtime dep trees
<clever> bennofs: it returns a json list of every storepath in the eval
<clever> bennofs: curl https://hydra.nixos.org/eval/1384033/store-paths -v -H 'Accept: application/json'
<clever> one min
<clever> the programs.sqlite util used that
<clever> there is an api url in hydra that spits out the storepath for every job in an eval
<clever> srhb: i think you would need root on hydra to find it easily
<clever> the nix source tarball also depends on shellcheck, which pulls in a decent amount of haskell (unknown ghc version)
<clever> if lens was a dep of something
<clever> only a subset, lens, and the deps of lens
<clever> the jobset for peti's branch
<clever> ah
<clever> bennofs: the chain is 3 or 4 ghc's long
<clever> bennofs: also, half of the ghc compilers depend on eachother, just for bootstraping
<clever> ah
<clever> which firewall?
<clever> frankpf: run the ssh client with -vvvv and then pastebin the output
<clever> srhb: nixos automatically opens the ports that ssh is configured to
<clever> but it turns out we where both wrong, because its broken
<clever> the topic had come up lastnight
<clever> yeah
<clever> sphalerite: something of note, nixos-install --chroot doesnt work on nixos-unstable right now
<clever> ip -6 route
<clever> sphalerite: but you can always do the copy in the reverse direction once your in, if the other end is under your control and more open
<clever> sphalerite: not sure, ive only used it for ssh
<clever> sphalerite: its basicaly teamviewer for ssh
<clever> sphalerite: https://tmate.io/
<clever> they can even run before you have a /etc or /home directory
<clever> the activation scripts may run before the users have even been created
<clever> M1k3y: i think a systemd unit would be better for that, set the type to one-shot
<clever> ive seen somebody break the system so hard it couldnt even find systemd, because he tried to do networking in the activation script
<clever> M1k3y: why are you trying to unpack a tar so early in the boot?
<clever> this sounds like a bug in the rename module not allowing overrides
<clever> frankpf: try setting services.openssh rather then services.sshd
<clever> frankpf: and what is the exact error?
<clever> frankpf: what did you put into configuration.nix?
<clever> michalrus: what are you trying to do with the activation script? those run extremely early in the boot
<clever> frankpf: add lib to the arguments on line 1 of the file
<clever> nwuensche: https://nixos.org/nixos/options.html#hardware.pulseaudio
<clever> Infinisil, michalrus: manualy editing things in the nix store will break a lot of things
<clever> even a .swp file by vim will make it rebuild everything
<clever> any change to the nix files makes it rebuild everything
<clever> the source depends on the nix files
<clever> do you have a src of ./. ?
<clever> import always does default.nix
<clever> copy-closure can take a list
<clever> let alias = x; in
<clever> nope, but you could maybe do it with a let block
<clever> ive memorized an unually large chunk of nixpkgs
<clever> rodarmor: nix-shell -p gnumake
<clever> you will need to manualy paste the old preStart into your override
<clever> so your new preStart has to create and fix the owner
<clever> rodarmor: you can use mkForce to override it, but that will entirely replace
<clever> rodarmor: preStart on the proper systemd unit
<clever> depends on if it makes a link for each output or not
<clever> buildEnv
<clever> so there is no real point in trying
<clever> nixpkgs will just ignore it when you try to pass those in
<clever> stack could build it, but nix couldnt
<clever> i ran into the same problem a week ago, somebody increased the required version of containers
<clever> base and containers cant have their versions overriden
<clever> base is null, its part of ghc
<clever> when generic-builder was called?
<clever> Myrl-saki: what are the deps being passed into your package?
<clever> containers?
<clever> what was the null?'
<clever> stepcut: that might work
<clever> that will fix the --chroot flag
<clever> stepcut: and then update NIX_PATH and re-build the tarball
<clever> stepcut: its still right on nixos 17.03, so if you clone this branch in virtualbox: nixos-17.03 from https://github.com/NixOS/nixpkgs-channels
<clever> stepcut: yeah, the --chroot flag is broken
<clever> stepcut: one minute
<clever> stepcut: i checked the source, and i think i see a problem
<clever> stepcut: what are the contents of /mnt//nix/var/nix/profiles
<clever> stepcut: its safe to ctrl+c
<clever> stepcut: and your sure you used just --chroot?
<clever> Lisanna: all networking is disabled during builds
<clever> what packages?
<clever> yep
<clever> the command you gave will run --root as a shell in --chroot
<clever> also, the --chroot arg parsing is rather dumb
<clever> that will become the authorized_keys file
<clever> you will also want to populate /ssh_pubkey before you /kexec_nixos
<clever> ah
<clever> if you can enable an sshd in the vbox, you can use agent forwarding to hop around
<clever> :S
<clever> which isnt valid
<clever> so it will try to make a darwin build of the linux kernel
<clever> nothing in the expression forces it to be a linux build
<clever> *looks*
<clever> yeah
<clever> stepcut: so it will be running a fully nixos based system, from ram
<clever> stepcut: kexec will mount a nixos filesystem that was inside the tarball
<clever> stepcut: have a look at the session.md file
<clever> stepcut: its designed to be built into a tar on another nix machine, uploaded, then unpacked and ran
<clever> Myrl-saki: maybe
<clever> nixos-install handles all of it
<clever> there are some directories and env vars that nixos needs set when using chroot
<clever> correct
<clever> stepcut: then you can use "nixos-install --chroot" to chroot into it properly
<clever> stepcut: i think you could run this kexec trick inside the rescue shell, then you will have nixos running from ram
<clever> havent looked into the code of how that controls things
<clever> sure
<clever> and it will be checked even if build slaves are off
<clever> so it gets checked sooner
<clever> Myrl-saki: nix-serve is one option, that runs a binary cache
<clever> it will discover it was already done
<clever> only if B tries to build it on A
<clever> nixos-rebuild will restore it
<clever> just delete /etc/nix/machines
<clever> another option in that case
<clever> that should also work
<clever> it will internally do the same things as nix-daemon
<clever> but if you run nix-build as root, you can safely unset NIX_REMOTE
<clever> if NIX_REMOTE is set to daemon, then its nix-daemons hook that matters
<clever> i'm guessing its users trying to just nix-env all deps or just blindly using pip as always
<clever> trustedUsers = [ "builder" ];
<clever> nix = {
<clever> Myrl-saki: you need to add the build user to the trusted-users list in the slaves nix.conf file
<clever> Myrl-saki: make sure you quote the private key path, or it lands in /nix/store/
<clever> yeah
<clever> it also adds a .override function to let you change those arguments
<clever> nope
<clever> donbright: and you can use a command like: nix-build ~/nixpkgs -A hello, to test it
<clever> donbright: copy the nixpkgs version to your home folder and edit the copy
<clever> donbright: /nix/store is supposed to be read-only, it must never be modified by hand
<clever> donbright: you may also need to set the env var NIX_PATH=nixpkgs=/path/to/nixpkgs
<clever> donbright: this outputs a backtrace to the source of the problem, even if you run it on an x86 machine
<clever> nix-instantiate -E 'with import <nixpkgs> { system = "powerpc64-linux"; }; hello' --show-trace
<clever> donbright: what does this print? nix-instantiate --eval -E 'builtins.currentSystem'
<clever> donbright: and the expressions within nixpkgs need to know how to build a gcc for the current platform
<clever> Myrl-saki: yeah
<clever> donbright: nix-env will automatically create .nix-profile
<clever> donbright: the correct url is https://nixos.org/channels/nixpkgs-unstable
<clever> Myrl-saki: yeah, i try to always use a builder user for this
<clever> donbright: nix-defexpr is usually managed by nix-channel
<clever> are you on nixos or another distro?
<clever> it will just do it for any expression
<clever> when done right, it will copy all inputs out, and copy the products back
<clever> nixos also has options to configure it
<clever> nix-daemon (running as root) needs read on the key
<clever> this says to ssh into the given user@host, and to use that ssh privkey to get in
<clever> builder@192.168.2.15 i686-linux,x86_64-linux /etc/nixos/keys/distro 3 4 big-parallel,kvm,nixos-test
<clever> [root@nas:~]# cat /etc/nix/machines
<clever> a nix build slave is better
<clever> yeah, nix-copy-closure on a .drv doesnt copy all the inputs, so the destination has to rebuild/download them
<clever> what fails when you do that?
<clever> then use nix-copy-closure to copy that elsewhere, and nix-store -r to build it
<clever> so just "nix-instantiate" with no args, that will give a .drv for the whole thing
<clever> you can run nix-copy-closure on a .drv file
<clever> ah, then you want to use a nix build slave, or nix-copy-closure
<clever> why are you trying to build a list?
<clever> so just no -A flag
<clever> it doesnt return an attribute set
<clever> inputs attribute
<clever> so nix-build -A cant find inputs
<clever> Myrl-saki: there is no attribute in that file
<clever> yeah, that names also fits
<clever> catern: ive called that variable raw_func before

2017-08-13

<clever> its in /
<clever> whats this? lol
<clever> -rw------- 1 root root 0 Apr 9 2016 .#mnt.lck
<clever> recursively readDir
<clever> { ".#mnt.lck" = "regular"; bin = "directory"; boot = "directory"; "config.json" = "regular"; dev = "directory"; etc = "directory"; hax = "directory";
<clever> nix-repl> builtins.readDir "/"
<clever> catern: builtins.readDir
<clever> and doesnt inherit that env var
<clever> but nix-daemon runs as root
<clever> and it cant find your agent
<clever> MP2E: nix-daemon is probably the one initiation the ssh connection