2020-05-06

<clever> oops, managed to miss that
<clever> turion: with the $
<clever> turion: what does `echo "configurePhase"` say?
<clever> and genericBuild auto-detects that for you
<clever> but then you have to know if its been set or not
<clever> that would turn all the newlines into spaces, it needs to be more like `eval "$configurePhase"`
<clever> turion: `phases="configurePhase" genericBuild` is the simplest way to let nix pick the right one by the normal rules
<clever> turion: configurePhase always refers to a bash function for the default, $configurePhase is the override
<clever> turion: did you override configurePhase?
<clever> weird, callPackage is missing from the ,callPackage help text!
<clever> turion: but use nix-shell instead of nix-build
<clever> ,callPackage
<clever> sb0: though, its still copying the src, and then basically doing `mkdir build ; cd build ; cmake ..`
<clever> sb0: cmake already does that automatically

2020-05-05

<clever> etu: lol
<clever> etu: yeah, its a middle-man between the cpu and disk
<clever> if your motherboard dies, your data is RIP :P
<clever> etu: full disk encryption, seamless, no pw prompt, key is tied to the motherboard
<clever> etu: theres also the apple T2 based disk encryption
<clever> etu: and you now have no way of knowing how secure the disk actually is
<clever> etu: i think the root problem, is that the api meant to be just a on/off switch, not proper crypto
<clever> while still on
<clever> azazel: yeah, it would have to be done by somebody that knows its drive-managed, and they would have to get their hands on a pc after it booted
<clever> yeah, that too
<clever> morgrimm: and then i can just dump everything
<clever> morgrimm: in theory, if i remove the drive from the pc, without disconnecting power, it will continue to decrypt itself
<clever> thats one of them, there are others in that area
<clever> fresheyeball: cant remember the name of the tool
<clever> fresheyeball: no real laws on what you can or cant do
<clever> fresheyeball: for nix, it will just run the function in __functor, if you treat a set like a function
<clever> morgrimm: sounds like it should just work
<clever> fresheyeball: what are those laws?
<clever> fresheyeball: what is that?
<clever> fresheyeball: it lets you treat a set as-if it was a function
<clever> morgrimm: sounds like your bios is being funny
<clever> morgrimm: it should be showing uuid's like this
<clever> Boot0004* UEFI OS HD(1,GPT,27c99b08-455d-4dfe-a44f-6150cbc09ef8,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
<clever> morgrimm: "linux boot manager" doesnt look right
<clever> morgrimm: can you pastebin that all, and the output of `blkid /dev/sd*`
<clever> morgrimm: might have been -v
<clever> morgrimm: which uuid is in the efi vars (install efiboormgr) and if you have duplicate boot parititons
<clever> morgrimm: what does `efibootmgr -V` and `fdisk -l` report?
<clever> morgrimm: which bootloader are you using?
<clever> morgrimm: depends on which bootloader and what config it has
<clever> morgrimm: so the config in there said to delete them
<clever> morgrimm: sounds like /boot wasnt mounted when you added the users
<clever> pingiun: probably
<clever> energizer: it will try to umount /
<clever> energizer: yeah
<clever> energizer: hardware-configuration.nix would be a reasonable way to do it, but use boot, not switch
<clever> energizer: gchristensen has a blog post on that
<clever> pingiun: no idea whats happening, but id get more of the backtrace (beyond frame 9) and then post it to an issue on github
<clever> pingiun: the corefile is only of use with the binary that made it, run gdb against them (systemctl gdb <pid>) and then `bt`
<clever> pingiun: yeah, would need a coredump and bt to know more
<clever> pingiun: builtin:fetchurl means nix itself should just fork out a child proc, and run an internal function
<clever> pingiun: and if its linux+systemd based, try turning on coredumpctl
<clever> pingiun: run `nix show-derivation` on that drv to get its builder, then try just running that builder directly

2020-05-04

<clever> glittershark: dang, not sure what else to try then
<clever> glittershark: for a docker container, try adding glibcLocales to the contents list
<clever> sphalerite: they patched linux to make namespacing require root by default, for any operation
<clever> sphalerite: nice, but that will likely fail when debian disables user namespaces
<clever> sphalerite: is that `nix run --store` also chroot'ing the `hello` binary as well??, or was it just working by chance due to deps in the real /nix/store ?
<clever> energizer: you need to edit either the Makefile or the nix expr thats building it
<clever> energizer: gcc then complained that no, cert, and file are not in scope
<clever> energizer: which is ~3 variables, and a jumble of division and subtraction operations
<clever> energizer: so it turned into the C code: setenv("NIX_SSL_CERT_FILE", /no-cert-file.crt);
<clever> energizer: the /no-cert-file.crt wasnt double-quoted
<clever> 34 then takes a derivation from elsewhere (like default.nix), and overrides it, adding the 3 scripts to buildInputs
<clever> lines 31-33 run the function from 11, to generate 3 scripts
<clever> line 11 takes a set, and generates a bash script to run something from the dist folder (left-over from `cabal build`)
<clever> line 3 makes a dir with a bunch of cfg files
<clever> danderson: even a rubber duck works!
<clever> :D
<clever> danderson: let foo = stdenv.mkDerivation { ... }; in stdenv.mkDerivation { name = "shell"; buildInputs = [ foo ]; }
<clever> keithy[m]: switch always needs root
<clever> keithy[m]: and what does `nixos-rebuild switch` output?
<clever> keithy[m]: how did you try setting guiAddress?
<clever> keithy[m]: can you confirm the new address is in /etc/systemd/system/syncthing.service ?
<clever> keithy[m]: the guiAddress is directly in the ExecStart line of the .service file, it should restart when changed
<clever> keithy[m]: depends on how its told to use that file
<clever> keithy[m]: rebuild checks if the file in /etc/systemd/system/ changed
<clever> ixxie: systemd treats each of them as its own service, but they share the ExecStart and part of the name
<clever> systemd will replace that in the ExecStart (and other fields), with the bar from foo@bar.service
<clever> ixxie: and then look for %I in `man systemd.unit`
<clever> ixxie: and then you use systemd instances to define an ExecStart for foo@.service, then set just the wantedby for foo@bar.service
<clever> ixxie: you use submodules in nixos to let you set services.foo.<manythings>.bar
<clever> and if you need a 2nd vpn link, it just makes another instance
<clever> ixxie: nixos lets you define a services.openvpn.foo and then start openvpn@foo
<clever> ixxie: look at openvpn or wireguard for examples
<clever> ixxie: yeah
<clever> ixxie: then you want to create a minio@foo service in systemd
<clever> ,xy ixxie
<clever> ixxie: what about using foo@bar services in systemd?
<clever> ixxie: why do you want duplicate instances?
<clever> ixxie: put the copy of the module in /etc/nixos/ and do imports = [ ./copy.nix ];
<clever> services.hydra2
<clever> ixxie: i tend to just edit the name of the service and config in the module, if i want a dup
<clever> virus_dave: it should be deterministic, but darwin is case insensitive by default, which can cause issues
<clever> reirob: this produces a /init in an initrd, that is fully static
<clever> reirob: and then a stripped down example: https://github.com/cleverca22/nix-tests/blob/master/haskell-init/default.nix
<clever> reirob: one sec
<clever> mikky: so `foo = "bar";` is priority 100, while `foo = lib.mkForce "baz";` is priority 10
<clever> and the "default" priority (not mkDefault) is 100
<clever> 1500 is the default= inside an option, 1000 is mkDefault, 50 is mkForce, 10 is mkVMOverride
<clever> mikky: mkForce has a stronger (smaller number) then the normal setting
<clever> reirob: can you pastebin the entire cabal file that is failing?
<clever> mikky: but if you set it without a level even once, then it ignores all defaults, and uses all of the normals
<clever> mikky: so if you only mkDefault, then it will merge all mkDefault's
<clever> -highest
<clever> mikky: it will then get everything at that level (all of the mkForce values for ex), and merge them according to the normal merge rules
<clever> mikky: for every given option, nixpkgs will find the highest smallest override level (50=force, 1000=default) for that option
<clever> reirob: yeah
<clever> reirob: it should be all lowercase, but what you pasted had a E in it
<clever> immae: the bashrc stuff in nixos will put it back in PATH on login
<clever> reirob: lowercase executable, does that do something diff?
<clever> aanderse: if you remove permission to /nix/var/nix/profiles/per-user/clever, then i expect all nix-env commands to fail to modify it
<clever> lrwxrwxrwx 1 clever users 45 Oct 11 2015 /home/clever/.nix-profile -> /nix/var/nix/profiles/per-user/clever/profile
<clever> aanderse: always confirm what they claim
<clever> aanderse: never trust the user :P
<clever> aanderse: what about the grep?
<clever> aanderse: `grep nix-env /home/username/.bash_history` ?
<clever> aanderse: and busybox's ls likely doesnt support --color
<clever> aanderse: a common issue, is that `comand-not-found` will tell you to install busybox, because it has everything
<clever> aanderse: `command ls -l /home/username/.nix-profile/bin/ls`
<clever> reirob: what if you run cabal2nix on the cabal file manually?
<clever> aanderse: what about `which ls`
<clever> lol
<clever> aanderse: what does `type ls` report?
<clever> ,pastebin
<clever> reirob: it already loaded ghci, so its not a problem building ghci
<clever> reirob: what is in release0.nix?
<clever> reirob: are you using nix-shell when you get the linker errors?
<clever> vandenoever: how much ram is nix using?

2020-05-03

<clever> energizer: yeah, which means proot isnt working right
<clever> energizer: load a normal dynamic library
<clever> cole-h: add `-f '<nixpkgs>'`
<clever> most programs use `isatty()` to figure out what stdout is
<clever> genevino: or just throw `|cat` at the end i believe
<clever> energizer: nope, its using LD_PRELOAD to overwrite glibc functions, and then prepends a string to all paths
<clever> energizer: but then debian/ubuntu decided to get in the way, and make namespacing require root by default, and you have to specially allow non-root to use it
<clever> energizer: nix-user-chroot uses namespacing, so it has better performance
<clever> prusnak: i try to always use dockerTools.buildImage
<clever> a static binary is the simplest answer
<clever> but it might break if ubuntu has the "wrong" glibc
<clever> you could just use patchelf to undo the rpath stuff
<clever> Ralith_: you need to use the libraries that ubuntu provides, or you run the risk of compatability problems
<clever> Ralith_: that will do exactly what you want, to generate deb and rpm packages of nix itself
<clever> Ralith_: one min
<clever> evanjs: that will build 2 packages at once
<clever> evanjs: nix-build -E 'with import <nixpkgs> {}; buildEnv { name = "foo"; paths = [ hello firefox ]; }'
<clever> simpson: yeah, it wont update until the linked job is green, and EVERYTHING in that eval has at least been tried, pass or fail
<clever> philipp[m]: for nixos, a range of failures, that look like a game of whack-a-mole, one gets fixed, then another comes up
<clever> philipp[m]: darwin is to blame i think, for the nixpkgs based channels
<clever> philipp[m]: https://status.nixos.org/
<clever> Aleksejs: valve deleted the .deb files after an update, the fix is already in nixpkgs master
<clever> cole-h: what does `nix show-config | grep sub` say?
<clever> notgne2: due to dhcp, it has to be edited at runtime
<clever> Aleksejs: yes
<clever> notgne2: just edit /etc/resolv.conf
<clever> Aleksejs: and what do you have in systemPackages?
<clever> Aleksejs: and what is the exact error msg?
<clever> Aleksejs: what have you set systemPackages to?
<clever> glittershark: so only :b, nix-build, nix-shell, and nix-env can cause the build to actually start]
<clever> glittershark: and when you try to build a derivation, all of its build-time deps get built
<clever> glittershark: if you then pass that string to another derivation, it magically becomes part of the build-time dependencies
<clever> glittershark: "${drv}" will return the path to the result, and invisibly attach the derivation to that string
<clever> cole-h: you can use --option to just make it smaller
<clever> $ nix show-config | grep nega
<clever> narinfo-cache-negative-ttl = 3600
<clever> cole-h: if nix-store -r cant find something, it wont bother checking again for an hour
<clever> cole-h: there is a negative narinfo cache
<clever> linarcx: libraries are special, and usually wont be picked up enless they are in the buildInputs
<clever> linarcx: pure only really matters in terms of $PATH and other env vars
<clever> linarcx: same rules for the clang that nix provides
<clever> linarcx: it can only find libraries that nix is providing
<clever> linarcx: the gcc provided by nix will never look in /usr/lib
<clever> linarcx: they will leak into the shell by default, and only --pure can stop that
<clever> ixxie: its on bus 0, slot 3, function 0
<clever> 00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
<clever> let me find my notes
<clever> Miyu-saki: pci bus, slot, and function number are some of it
<clever> oops
<clever> ,locate bin lspci
<clever> > bin lspci
<clever> ixxie: and what did lspci say about the card?
<clever> ixxie: but if you dont know those rules, and cant boot a nixos to query things, it can be simpler to just turn them off
<clever> ixxie: they are predictable, based on the output of lspci, and some complex rules
<clever> ixxie: loopback is always lo, so you can be sure it will be lo and eth0
<clever> ixxie: then you can just disable predictable names, and assume eth0
<clever> ixxie: how many interfaces on the machine, how do they differ from eachother?
<clever> Fare: builtins.readDir
<clever> Fare: something must be evaluating the nix expr with builtins.fetchGit, what did it?
<clever> Fare: how did you run the build from a shell?
<clever> sudo changes $HOME, so ~/.ssh is diff, but it leaves $SSH_AUTH_SOCK intact
<clever> Miyu-saki: `sudo ssh` works just fine when your using an ssh-agent
<clever> Fare: what url did you use? how did you run the build from a shell?
<clever> it runs git as your user, so it can use whatever secrets you have in the usual places
<clever> Fare: builtins.fetchGit can also clone anything you can with `git clone`
<clever> Fare: src = /home/clever/apps/foo;
<clever> FireFly: on a regular system, its just a symlink
<clever> lrwxrwxrwx 1 root root 4 Dec 17 2014 /usr/bin/sudoedit -> sudo
<clever> Fare: > I've already set `environment.variables.EDITOR` to `vim` and `echo $EDITOR` shows vim.
<clever> bpye: if you `systemctl kexec`, then systemd will reboot the machine via kexec, the issue though is getting it to pass the keys over...

2020-05-02

<clever> 6 , username ? "", token ? "" # get/reset token at https://factorio.com/profile
<clever> iqubic: and you can only login if you can proove you paid for it
<clever> iqubic: by logging in on the factorio site
<clever> iqubic: factorio can only install if you put an auth token into your config.nix file
<clever> symphorien: that would probably work, if you can mount over it
<clever> hmmm, just tried it, and its not working anymore...
<clever> symphorien: i believe `chmod 0` still impacts root, not sure why exactly
<clever> monokrome: i typically `chmod 0 /boot` before i mount /boot, so if that mistake ever happens, you get permission errors
<clever> monokrome: sounds like your hardware-configuration.nix is missing it then?
<clever> monokrome: if its not mounted, you stop updating the bootloader cfg
<clever> monokrome: was /boot mounted correctly when you ran nixos-rebuild ?
<clever> monokrome: try ctrl+alt+f7 ?
<clever> monokrome: did you hit ctrl+alt+f1 or similar?
<clever> ixxie: "we've moved:"
<clever> ixxie: it got re-uploaded, a few comments down
<clever> Raito_Bezarius: activationScripts just run in a bash shell, before systemd is even launched
<clever> Raito_Bezarius: activation scripts could run before the driver is loaded, a systemd unit would be better
<clever> ixxie: finding a link...
<clever> ixxie: i would make a systemd service that figures it out at runtime
<clever> ixxie: depends on what exactly your doing
<clever> ixxie: so you should push that choice off until runtime, or make the if name more predictable
<clever> ixxie: but the interface name at buildtime, may be wrong next time you boot
<clever> ixxie: what do you want to run, and what do you want to do with the output?
<clever> ixxie: as long as the expression doesnt depend on related options, its fine
<clever> the only time i get compiler tools, is when i run nix-shell
<clever> dsal: i prefer to never put any compiler things in nix-env, so that cant happen
<clever> adisbladis: and this is an example of how to make your own module thing
<clever> adisbladis: the explorer example i linked, is using the whole nixos to configure things, but its no fully automated
<clever> cole-h: probably doesnt work in docker
<clever> adisbladis: i could see the loss of s3 being a potential problem, if anybody wants to `nix-store --option substituters s3://bucket`
<clever> cole-h: yeah
<clever> ah
<clever> adisbladis: util-linux depends on it by default
<clever> adisbladis: does it have systemd in the closure?
<clever> cole-h: it even required that your username be emoji
<clever> cole-h: he also made an instant messaging app, that only allows emoji
<clever> siers: just put an unquoted path in your nix expr
<clever> cole-h: have fun typing that over a 7bit serial link
<clever> colemickens: thats when you bust out your thesaurus!
<clever> though, some of my machines just lack a hardware-configuration.nix entirely
<clever> energizer: i try to keep all the changes to configuration.nix, in theory, you should be re-running nixos-generate-config to update hardware-configuration.nix
<clever> jboy46: store a db version# in the db, and in the prestart for your service, check what it is, and apply migrations based on the number
<clever> dmj`: yes
<clever> adisbladis: nope
<clever> adisbladis: ahh, looks like its more about adding a sudo replacement?
<clever> keithy[m]: each user has its own list of channels, you can `nix-channel --list` to see them
<clever> dmj`: its in the man page for nix-store
<clever> keithy[m]: as root, `nix-channel --add <url> nixos`, then `nixos-rebuild switch --upgrade`
<clever> adisbladis: i would just use sudo, `sudo -u foo <cmd>`
<clever> keithy[m]: check the release-19.09 branch on github, and you should see it agree with you now
<clever> dmj`: sign things with `nix sign-paths` or set a secret key in nix.conf so it signs everything
<clever> keithy[m]: sudo nix-channel --list
<clever> keithy[m]: which channel are you on?
<clever> dmj`: only if you have nix-daemon setup and the store permissions restricted to root
<clever> dmj`: if you have +w to /nix/store, you are trusted automatically
<clever> betaboon: that also works
<clever> betaboon: yes
<clever> das-g[m]: you can also use nix-copy-closure to copy the drv file out of the machine, then nix-build it, and nix-copy-closure the product back out
<clever> das-g[m]: NIX_REMOTE=local may force it to stop, but simpler to just make a key
<clever> das-g[m]: it may be spawning the ssh from nix-daemon, which breaks the forwarding chain
<clever> you should see it in required features
<clever> das-g[m]: if you run `nix show-derivation` on the drv for linux
<clever> das-g[m]: building a kernel requires a special feature flag
<clever> dxtr: its best to build it with nix and have it live in /nix/store/
<clever> you can either use -I nixpkgs= to remap it somewhere, or just give it an absolute/relative path to the release.nix instead
<clever> romildo: `nix-build '<nixpkgs/nixos/release.nix>' -A tests.xfce.x86_64-linux`
<clever> dxtr: ah, simple!
<clever> romildo: then youll probably want to be editing release.nix to add the tests to it
<clever> romildo: you can just look at the attrset within that (either in an editor, or `nix repl`), and then just build one of those attrs
<clever> romildo: all of the tests are attributes of nixos/release.nix
<clever> i'm not sure what that mountpoint is really used for
<clever> unknown
<clever> because your not really root
<clever> openvz can make a lot of things return permission errors, even as root
<clever> dxtr: the host isnt allowing you to do that
<clever> dxtr: oh, yeah, that would definitely be it
<clever> dxtr: thats what `mount` should say when it works
<clever> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
<clever> dxtr: looks totally normal
<clever> and toss it all into a pastebin
<clever> dxtr: stat / /var /var/lib /var/lib/nfs /var/lib/nfs/rpc_pipefs
<clever> dxtr: did you run nixos-rebuild as root? are the permissions in /var weird? any errors in `dmesg`?
<clever> dxtr: ?
<clever> whyuk: lines 73, and 69, will put config.system.build.toplevel into the list that 18 was referencing
<clever> dxtr: it could be kernel version issues, try a reboot?