2019-12-18

<clever> pie_: use routing to flag the container as a gateway to reach the vpn subnet
<clever> ldlework: and the normal -I nixpkgs= flags
<clever> ldlework: nixops just obeys $NIX_PATH
<clever> ,ifd
<clever> so at eval time, it would have to build the unsigned binary, then exec the signer, which has to put things into the store and return a path
<clever> CMCDragonkai: also, if the arguments to builtins.exec refer to derivations, thats IFD
<clever> since somebody could just `rm -rf /` by slipping something into code your eval'ing
<clever> but thats a rather dangerous one to leave enabled
<clever> CMCDragonkai: it shows up in `nix show-config` so id say yes
<clever> $ nix show-config | grep native
<clever> allow-unsafe-native-code-during-evaluation = false
<clever> it only shows up in the code that parses command-line-options, which has a help string
<clever> looks like its undocumented
<clever> and if it returns a different output, you get a different derivation
<clever> every time you run the eval, it will run whatever builtins.exec says to run
<clever> yeah
<clever> CMCDragonkai: think of it as just running something outside nix, and then pasting an expr into the file
<clever> CMCDragonkai: nope, its basically the same as import
<clever> it should be
<clever> CMCDragonkai: --allow-unsafe-native-code-during-evaluation
<clever> yes
<clever> and nix never gets access to the private keys
<clever> its actually reaching out to a hardware signing module, which does the actual signing
<clever> whatever it parsed, is returned by exec
<clever> nix will just treat the array as a naked argv, run it, and then parse stdout as a nix expr
<clever> basically, builtins.exec [ "/bin/sh" "-c" "echo 5*5" ]
<clever> CMCDragonkai: its an eval-time backdoor to just run something as whatever user is doing the eval
<clever> CMCDragonkai: i currently handle code signing using builtins.exec
<clever> CMCDragonkai: you also need the hash of the private keys (or add an impurity that lets every build see the keys)
<clever> CMCDragonkai: but then you need to know when it was signed, to compute $out
<clever> tpham: just run nix-shell with no args, it will try to load shell.nix first, and if not found, it loads default.nix
<clever> tpham: either use lib.cleanSourceWith to exclude it (the proper method), or just `preConfigure = "rm -rf build";` to get rid of it within nix-build (the sloppy but simple method)
<clever> the laptop is a remote builder for the desktop!
<clever> i just have all of my hardware in the house work together
<clever> ah
<clever> lovesegfault: and this will auto-generate a nixos guest under qemu
<clever> lovesegfault: docker, virtualbox, qemu
<clever> tpham: nativeBuildInputs are compiled for the host, buildInputs are compiled for the target
<clever> tpham: thats also an option, it uses namespacing to automatically chroot and run within that
<clever> tpham: simplest option then is to install nix, and then use nix-copy-closure and nix-env
<clever> tpham: do you have write perms to /nix/ ?
<clever> tpham: use nix-copy-closure to copy the storepath, and everything it depends on
<clever> `configurePhase` is a function that will run cmake, with the cmakeFlags
<clever> that explains everything perfectly
<clever> tpham: and you omitted that when compiling in nix-shell by hand?
<clever> tpham: ah, and then it wants a static copy of boost
<clever> tpham: what was it?
<clever> tpham: yes
<clever> lovesegfault: both
<clever> lovesegfault: --dry-run
<clever> tpham: stdenv.mkDerivation gets the .dev automatically for you
<clever> tpham: how are you finding the path under both nix-build and nix-shell?
<clever> yep, those match up
<clever> tpham: load up a `nix repl '<nixpkgs>'` and then try to eval both "${boost.out}" and "${boost.dev}"
<clever> tpham: thats boost.out vs boost.dev
<clever> tpham: yep
<clever> dansho: makeOutputPath generates a similar string, based on the contents of the drv and the output name (.out .dev .lib), to create the hash in $out
<clever> dansho: yeah
<clever> i think references, is everything under inputSrcs and inputDrvs
<clever> so the type from earlier, will be "text:<r1>:<r2>", with a list of references
<clever> dansho: which then uses addTextToStore, from store-api.cc
<clever> and finally, it writes the drv to the store
<clever> auto drvPath = writeDerivation(state.store, drv, drvName, state.repair);
<clever> that generates $out
<clever> and then it calls this, with the name of each output (usually just "out"), the hash of the drv, and the name of the drv
<clever> Hash h = hashDerivationModulo(*state.store, Derivation(drv), true);
<clever> auto outPath = state.store->makeOutputPath(i, h, drvName);
<clever> where it begins to iterate over each key/val pair
<clever> thats the source behind builtins.derivation
<clever> dansho: for all objects, its a truncated hash of "${type}:sha256:${hash2}:${store}:${name}"
<clever> let me grab the source
<clever> and then the hash-name.drv, is based on the hash of its own contents
<clever> i believe the way it works, is that outpath, is a hash of the attrs to builtins.derivation (and some other constants)
<clever> one min
<clever> hmmm, wait, other way around
<clever> but is rather, based on that hash
<clever> out isnt part of the hash
<clever> not sure why args is absent from env
<clever> dansho: env, args, builder, and system
<clever> yeah
<clever> since they just become env vars, its a bit hard to list every single one, you have to read all of the shell scripts to see what they look for
<clever> dansho: all args (including the required ones) just become env vars during the build, you can also run `nix show-derivation /nix/store/foo.drv` to see the whole set
<clever> dansho: yeah, its and its the real primop behind things like stdenv.mkDerivation
<clever> dansho: the set of every key/value pair passed to builtins.derivation
<clever> tpham: id expect that to work then
<clever> and all -p does, is put those strings into the buildInputs
<clever> pretty sure boost belongs in buildInputs
<clever> tpham: -p can take multiple arguments at once
<clever> tpham: if you read the cmake file, how does it actually search for boost?
<clever> tpham: looks like it exists for me and the bot
<clever> > llvmPackages_9.stdenv.mkDerivation
<clever> jusss: i either tab-complete within `nix repl '<nixpkgs>'` or grep nixpkgs, but there is also `nix search`
<clever> tpham: llvmPackages_9.stdenv maybe?
<clever> 7700 clangStdenv = if stdenv.cc.isClang then stdenv else lowPrio llvmPackages.stdenv;
<clever> tpham: adding pkgconfig on line 10 may fix the boost issues
<clever> tpham: then you can delete lines 11 and 13
<clever> tpham: use clangStdenv, not stdenv, when you want to use clang
<clever> i can at least see why with rasbian, more noob friendly if you can just download any image, and it work on any pi
<clever> rasbian still uses armv6 userland, so they can ship a single distro for every model of rpi
<clever> samueldr: got my msg in #nixos-aarch64 ?
<clever> bt``: i'm currently working on rpi firmware stuff, and using 32bit mode on an rpi3, despite it being 64bit capable
<clever> bt``: that resulted in software i was working on, crashing due to illegal instructions
<clever> bt``: the last dinosaur i retired was 64bit capable, but lacked some (now common) sse extensions
<clever> Henson: cant hurt to contribute to both at once
<clever> i believe so
<clever> Henson: yeah, that sounds like a good idea
<clever> Henson: if you set fileSystems."/something" = { fsType = "nfs"; device = "server:/something"; };, then nfs will be added to boot.supportedFilesystems automatically
<clever> Henson: boot.supportedFilesystems = [ "nfs" ]; and nixos will setup all nfs client stuff for you
<clever> monokrome: as i expected, the lock wasnt on-disk but was in-kernel
<clever> monokrome: can you paste those 2 lines?
<clever> monokrome: `sudo strace nix-channel --update`, what does it hang around?
<clever> monokrome: what happens if you just `sudo nix-channel --update` ?
<clever> monokrome: what exactly are you running, that causes it to block?
<clever> monokrome: usually, those locks are kept in kernel space, and cleared on improper shutdown
<clever> duairc: check `modinfo ipv6`, and try adding just its deps to boot.initrd.kernelModules?
<clever> duairc: it might be that ipv6 was pulling in other stuff via its deps, that you needed
<clever> and nothing will renew it
<clever> and then it has to expire naturally, based on the expire listed in `ip route`
<clever> ahh
<clever> duairc: they are sent out at a regular interval, so it may take a while to see one
<clever> duairc: id start with tcpdump to confirm that
<clever> duairc: ack!
<clever> pie_: i believe so
<clever> pie_: check other activation scripts in nixpkgs to see examples
<clever> pie_: thats what the deps= is for
<clever> yep, just check this file in the linux github
<clever> Documentation/networking/ip-sysctl.txt:accept_ra - INTEGER
<clever> duairc: there may be kernel docs for it...
<clever> lovesegfault: pong
<clever> i'm not sure what has priority when they conflict like this, but i'm on defaults and it just accepts RA's
<clever> 1
<clever> $ cat /proc/sys/net/ipv6/conf/all/accept_ra
<clever> $ cat /proc/sys/net/ipv6/conf/enp3s0/accept_ra
<clever> 0
<clever> duairc: you can also read it from /proc to confirm the current setting
<clever> so that wasnt really an option, enless i wanted to manually configure v6 everywhere
<clever> in my case, i was also relying on RA to configure the real router
<clever> so it null-routed all v6 traffic
<clever> one of the routers i purchased, and repurposed into an access point, refused to stop sending RA packets
<clever> duairc: that is also why ive still not gotten onto N band wifi, lol
<clever> duairc: that happens when you get route advertisement packets from the "router"

2019-12-17

<clever> lovesegfault: `git show abcde`
<clever> try doing that on another distro :P
<clever> lovesegfault: and with nixpkgs, you can bisect your whole damn os, like, nixos-rebuild boot && reboot, to narrow down problems! lol
<clever> thats what i was doing when i found this in docker :P
<clever> but its not hit nixpkgs yet
<clever> there is a PR near the bottom, that fixes it
<clever> it no longer needs /build
<clever> mid-term, add `sandbox = false` to nix.conf
<clever> eacameron: short term, --option sandbox false
<clever> eacameron: yep, /build being created is a sign of this bug, you should never have to do that
<clever> ive seen this bug before
<clever> eacameron: one minute
<clever> duairc: does the script that --script points to, actually exist within the initrd env?
<clever> keithy[m]: it should just work then, with only enable set
<clever> keithy[m]: is this from the raspberry pi sd image?
<clever> keithy[m]: can you show the above output, before you reboot, and after
<clever> keithy[m]: what does `ls -lh /run/current-system` output?
<clever> keithy[m]: then it should run on boot, one min
<clever> __monty__: the error was trying to query it with nixos-option
<clever> keithy[m]: what does `nixos-option systemd.services.sshd.wantedBy` output?
<clever> Anton43: its possible something is already using the alsa device, so pulse cant use it
<clever> keithy[m]: can you pastebin the entire output from `nixos-rebuild switch` before you remove it
<clever> keithy[m]: the stackoverflow said to use systemd.services.sshd.wantedBy
<clever> keithy[m]: yep, because services.sshd.wantedBy isnt a valid option
<clever> keithy[m]: what does nixos-option services.sshd.wantedBy report?
<clever> Anton43: then the issue is within pulseaudio, try `pactl exit` to restart it
<clever> Anton43: what about pavucontrol ?
<clever> one min
<clever> keithy[m]: i would expect that to fail...
<clever> keithy[m]: and your editing /etc/nixos/configuration.nix right?
<clever> keithy[m]: what does `echo $NIX_PATH` say?
<clever> keithy[m]: what happens if you run `nixos-rebuild switch` ?
<clever> keithy[m]: `systemctl enable` will never work on nixos
<clever> keithy[m]: they are completely different options
<clever> keithy[m]: thats systemd.services.sshd, not services.sshd
<clever> keithy[m]: what happens if you run `nixos-rebuild switch` ?
<clever> keithy[m]: thats not a valid option!
<clever> keithy[m]: wait a second, line 66 should just fail hard
<clever> keithy[m]: you will also need to nixos-rebuild switch for the change to take effect
<clever> keithy[m]: if you remove line 66 of configuration.nix, and try another reboot, what happens?
<clever> __monty__: it isnt
<clever> keithy[m]: can you pastebin it anyways?
<clever> keithy[m]: and what about hardware-configuration.nix?
<clever> keithy[m]: can you pastebin the configuration.nix file?
<clever> keithy[m]: is this the installer image?
<clever> simpson: the ssh service in nixos opens its own port up automatically
<clever> keithy[m]: and if you do `systemctl status sshd` what does it report?
<clever> keithy[m]: did you enable ssh in configuration.nix?
<clever> even chromium has a test in the nixos framework
<clever> CMCDragonkai: because $HOME isnt set, X11 apps are looking as /.Xauthority, not /root/.Xauthority
<clever> CMCDragonkai: its not looking in /root/, is the problem
<clever> CMCDragonkai: then $HOME isnt set right, HOME=/root/ in your case
<clever> when `xauth list` starts with amd-nixos/unix:0, then that means it will only use that record when connecting to amd-nixos
<clever> CMCDragonkai: you may need to install it within the container first, the hostname may also matter
<clever> CMCDragonkai: what is the listing from inside docker?
<clever> CMCDragonkai: if you run `xauth` and then `list` both inside and out, what does it say?
<clever> CMCDragonkai: you can also use the xauth command, to export and import records from .Xauthority
<clever> CMCDragonkai: .Xauthority contains the secret password that lets you connect, but you also need to be able to connect to the unix socket at /tmp/.X11-unix/X0
<clever> both of which can add more context
<clever> pie_: 1610, it will check a set for a .toString function or .outPath value
<clever> pie_: line 1605, it will return either the copy or the original string (based on the bool), and only copyPathToStore is able to modify the context
<clever> pie_: line 1600, if you try to coerceToString another string, it will return the string, and add the context to the given list
<clever> pie_: but you found the other half i didnt link!
<clever> pie_: "${foo}" calls coerceToString on whatever is within foo
<clever> pie_: the bool passed to coerceToString controls if it will copy or not, the default is to copy
<clever> pie_: but toString ./. just turns the path into a string, without copying, and it cant have context on things outside of the store
<clever> pie_: "${./}" will create a new string, that depends on the copy at /nix/store/hash-foo
<clever> pie_: context only works for things in /nix/store, so toString doesnt have anything it could add as context
<clever> pie_: when it makes a copy, the new string will depend on the copy via a context
<clever> pie_: toString will just give the path as a string, casting it will copy
<clever> > "${./.}"
<clever> > ${./.}
<clever> > toString ./.
<clever> and then see if it changes again in the future
<clever> zeta_0: you can run this program to get an exact number to how slow the boot is
<clever> graphical.target reached after 14.233s in userspace
<clever> Startup finished in 6.405s (kernel) + 14.233s (userspace) = 20.638s
<clever> [root@amd-nixos:~]# systemd-analyze
<clever> nothing in the boot process should care about how many generations you have
<clever> zeta_0: who does it load faster? it shouldnt have any real impact on the speed
<clever> if it was a clean shutdown
<clever> it should
<clever> pie_: there is also `journalctl -b -1`
<clever> zeta_0: but the pastebin only shows the error, nothing useful
<clever> zeta_0: `nix-collect-garbage -d` cant delete system profiles if it lacks root
<clever> zeta_0: `fdisk -l` only works as root
<clever> zeta_0: can you pastebin the full output of `fdisk -l /dev/nvme0n1 ; df -h` ?
<clever> zeta_0: all commands in irc start with a /
<clever> lordcirth_: to make it look like its still sending a msg, even if its a cmd
<clever> it must be a bug in the emacs irc client
<clever> zeta_0: what is the last line of output from `df -h /boot` ?
<clever> lordcirth_: it starts with a /, which is the trigger for commands
<clever> zeta_0: compare what you said on irc to what you copied from the terminal
<clever> zeta_0: the 3rd line is missing
<clever> zeta_0: what does `df -h /boot` report?
<clever> zeta_0: is it booting with efi or legacy?
<clever> zeta_0: was /boot mounted correctly?
<clever> yeah
<clever> the nixops issue i linked, is about stream-lining that more
<clever> lordcirth_: so you would need to use justdoit to install, boot that, then nixops deploy to the hdd
<clever> lordcirth_: if you do that from netboot, it wont persist at shutdown
<clever> lordcirth_: the current nixops will just copy to the target /nix/store and switch to the new generation
<clever> zeta_0: ah
<clever> lordcirth_: the rest of the stuff in the issue, is just how to get a nixos env running on the target, in ram
<clever> zeta_0: the grub config isnt updated until you nixos-rebuild switch
<clever> lordcirth_: and step 4 tells nixos-install that its already been built, just fix the bootloader
<clever> lordcirth_: step 3 in the issue is how to copy-closure with a chroot on the remote end
<clever> lordcirth_: yep
<clever> lordcirth_: for example, you could just netboot a machine, then just point nixops towards the ip, and let nixops do the entire install
<clever> lordcirth_: something else i want to work on some time, that fits your needs, is https://github.com/NixOS/nixops/issues/1189
<clever> lordcirth_: so if you nix-build that on a mac, it winds up running nixos under the darwin build of qemu!
<clever> lordcirth_: but the 2nd nixpkgs (for qemu and bash) are left to default to the current os
<clever> lordcirth_: one nixpkgs is forced to x86_64-linux (for the nixos guest)
<clever> lordcirth_: this will use 2 instances of nixpkgs, to build a qemu that runs nixos
<clever> lordcirth_: you could also just run the vm from the netboot image directly, and never "install"
<clever> lordcirth_: only run that on a machine you are fine with wiping
<clever> lordcirth_: if you want to install nixos on another machine, yeah, and note that it curently has zero confirmations when being ran
<clever> lordcirth_: and if its the main router, you dont need the nat stuff
<clever> lordcirth_: yeah, customize lines 20-27 and 12 to suit your needs
<clever> lordcirth_: the original use, is that you plug any machine into the laptop ethernet, netboot it, run justdoit, and boom, its now nixos!
<clever> lordcirth_: lines 20-27 are then a nixos config for the client, that will boot over the network
<clever> lordcirth_: the main file, is meant to be a netboot server, on a laptop, you aim lan to an ethernet card, and wan to a wifi card, and it will NAT between them for you
<clever> lordcirth_: config for the justdoit script, if you run `justdoit` on the netboot client, it will nuke /dev/vda, and install nixos using luks
<clever> lordcirth_: this file also sets up everything needed for network booting
<clever> lordcirth_: that puts the tftp dir into the nix store, and manages it with a nix expression
<clever> lordcirth_: one minute...
<clever> i'm mixing 3 different cross-compilers in my current project, with little trouble
<clever> the cross-compile support is also amazing
<clever> mla: ${./foo.bin} will copy the file to /nix/store/hash-foo.bin, and insert that new path into the script
<clever> mla: nix builds everything in a sandbox, and changes the working dir
<clever> mla: did you use ${ like in my example?
<clever> mla: hardware.firmware = [ (pkgs.runCommand "foo" {} "mkdir -pv $out/firmware ; cp ${./foo.bin} $out/firmware/foo.bin") ];
<clever> mla: then you can use pkgs.runCommand to make it into a package
<clever> its usable for short-term testing, but dont leave it
<clever> qyliss: but thats even more unstable, it will change if the pr or master is merged, breaking your sha256's a lot
<clever> qyliss: there is also pull/merge/1234, which is the result of if the pr was merged
<clever> pie_: which reference the head of pr 1234
<clever> pie_: there are magic branches in github, pull/head/1234 i believe
<clever> pie_: there is...
<clever> mla: hardware.firmware = [ ./dir ]; and then put the files in dir/firmware/ i think
<clever> i have seen evals take 2 hours, because it had to build 3 copies of ghc
<clever> supermathieu: pkgs.runCommand takes a bash script, but to get the value within an expression, you must import from that derivation
<clever> ,ifd

2019-12-16

<clever> you can get incremental builds for a single package at a time
<clever> asheshambasta: i prefer using nix-build to build everything, and that properly sandboxes everything
<clever> asheshambasta: yeah, thats why i tend to avoid `stack --nix build`, its just an impure build in .stack-work
<clever> bahamas: thats generally what shell.nix files are for, commit shell.nix to git, and just blindly nix-shell every time