2019-10-12

<clever> infinisil: i keep forgetting to file it, let me gist the repro files...
<clever> infinisil: its a pretty weird bug, $NIX_BUILD_TOP isnt set right
<clever> infinisil: there is a bug i recently found, that makes that statement non-true on non-nixos!
<clever> i should get off to bed, its now 3:30 am!!
<clever> snifffy: how does it differ from regular old luks?
<clever> snifffy: "Warning: Development of TrueCrypt was discontinued on May 2014"
<clever> wedens: the ssh hostkey for dropbear is also in plaintext, and an evil maid can just backdoor your /boot, or spin up a honeypot with the same keys, and wait for your pw to be typed in
<clever> and the whole point of dropbear is usually to enter the luks pw for /, so /boot cant be encrypted
<clever> though, your wifi password must now be in /boot, in plaintext
<clever> and nix makes a modular initrd so much simpler, compared to when i cobbled one together in raw bash, lol
<clever> if your booting via legacy, grub is still using the legacy (dos era) drivers to access the disk
<clever> MichaelRaskin: grub has worse IO performance (due to the drivers it has)
<clever> MichaelRaskin: i think its still IO expensive
<clever> since lost the code though
<clever> wedens: i know, because i was insane enough to re-implement firmware loading in bash once, to get nfs root over wifi, lol
<clever> wedens: loading firmware requires a full udev (or a lot of hacky bash scripts), and most wifi cards need firmware to function
<clever> ah
<clever> MichaelRaskin: maybe the lava lamps dont even matter? and its just "art" infront of a webcam that only uses the lowest bits! lol
<clever> MichaelRaskin: and that might be part of what the lava lamps are helping with
<clever> although, which would generate more heat? lol
<clever> MichaelRaskin: i have a feeling that the wall of lava lamps is likely still a higher bitrate source then a wall of sound cards
<clever> (seriously, they use lava lamps as an rng source :P)
<clever> MichaelRaskin: the lava lamps do a lot of the task that both a human and computer cant do!!
<clever> MichaelRaskin: and dont forget the lava lamps
<clever> wedens: you will also want step 4 of the above issue, to setup the bootloader, once it has been copied
<clever> wedens: if its already in the /nix/store of the live usb, sure
<clever> then it tells the nix on machine 2, to do what i said earlier, and prefix all paths with /mnt/
<clever> wedens: that tells the nix on machine1, to first ssh into machine 2
<clever> wedens: for that, you want something slightly different
<clever> its basically a chroot, but entirely done thru string prefixing
<clever> wedens: that will configure nix to prefix all paths with /mnt before accessing them, on the destination side
<clever> wedens: nix copy --to local?root=/mnt /nix/store/foo
<clever> danderson: programs.screen.screenrc is just a helper, to generate /etc/screenrc for you, and since its of type lines, nixos will merge things between multiple files
<clever> danderson: if you want to configure things in /etc, then you must use a nixos module, and thats what programs. handles
<clever> danderson: things in systemPackages can only add files to /run/current-system/sw/ and nothing more
<clever> superbaloo: nix-store doesnt really interact with nix files, only derivations
<clever> superbaloo: and `nix why-depends`
<clever> superbaloo: nix-store -q --tree
<clever> and nix-shell will just shove them into PATH for you
<clever> the things i jam in, are shell scripts, that run a file under dist/build/foo/foo, with the right args
<clever> i just grab .env as before, then .overrideAttrs, and jam a few things into buildInputs!
<clever> all haskell packages have a .env attribute on them, meant for use with nix-shell
<clever> `nix-shell '<nixpkgs>' -A haskellPackages.aeson.env`
<clever> nix doesnt provide cabal-install (the cabal binary), only Cabal (the hackage package)
<clever> Squarism: ah, then you want to shell into the .env attr, and use `runhaskell Setup.hs configure` then build
<clever> `make` is simpler, and you probably already use it?
<clever> Squarism: nix-shell into the drv, cd into the right dir, and then run either `make` or `buildPhase`
<clever> Squarism: what parts of the build do you want done? is the source already unpacked?
<clever> -I will prefix that list
<clever> and NIX_PATH is just a : seperated list of those entries
<clever> jonathan34: -I nixpkgs=/foo will directly map <nixpkgs> to /foo (instead of /foo/nixpkgs)
<clever> jonathan34: -I/foo will tell nix to search for nixpkgs in /foo, just like gcc -I/foo
<clever> jonathan34: <nixpkgs> will search $NIX_PATH for nixpkgs
<clever> jonathan34: most channels also get into $NIX_PATH, so you can reference them there too
<clever> jonathan34: you can also just make a shell.nix, that imports a specific nixpkgs, and uses it directly
<clever> jonathan34: `nix-shell '<nixpkgs>' -A hello` saves you from needing a cd
<clever> jonathan34: while `nix-shell -A hello` will load default.nix in the current dir, then give you a shell suitable for building hello
<clever> jonathan34: the other major difference, is that `nix-shell -p hello` will give you a shell suitable for using hello
<clever> jonathan34: this is just some dumb string concat, to generate an expr for -E, based on the -p flags
<clever> thats all -p does!
<clever> possibly channels_root
<clever> jonathan34: nix-shell -I nixpkgs=~/.nix-defexpr/channels/foo/
<clever> jonathan34: nix-shell -p always loads from <nixpkgs>, but you can use -I to remap <nixpkgs>
<clever> jonathan34: nix-env is the only tool that is directly aware of channels
<clever> if each channel has a unqiue name in `nix-channel --list`, then you can refer to it directly with nix-env
<clever> jonathan34: when you do `nix-env -iA nixos.hello`, thats telling it to use a channel named nixos
<clever> AmandaC: yep, so nothing is storing huge things in a tmpfs, id say its all cptofs to blame
<clever> spiderbit: yeah
<clever> spiderbit: nix-build/nix-env/nixos-rebuild, against another nix file, and a custom profile
<clever> spiderbit: because `config` builds the nixos for you, while you might be using `path` to manage it yourself via other methods
<clever> AmandaC: what does `df -t tmpfs` report?
<clever> AmandaC: 0 swap free, almost no ram free, yep, your out!
<clever> AmandaC: its installed by default
<clever> free -m ?
<clever> thats weird
<clever> AmandaC: how much memory does the system have?
<clever> spiderbit: and it must point to a build of nixos (from nix-build '<nixpkgs/nixos>' -A system`) to function correctly
<clever> spiderbit: the option named path, is also of type path
<clever> spiderbit: the path type accepts anything starting with a /, it doesnt enforce that its a path to the right thing
<clever> > pkgs.su
<clever> red[m]: su is in su
<clever> hpfr[m]: the man page confused me too, it looks more like 5 man pages cat'd together
<clever> hpfr[m]: nix-store {--realise | -r} paths... [--dry-run]
<clever> hpfr[m]: not sure what else could be checked, try doing `nix-store -r /nix/store/foo` using something the remote machine has, but the local doesnt, and also not in the binary cache
<clever> red[m]: directly in /run or a subdir? does it have an option to move it?
<clever> red[m]: i made a typo when i showed the .user earlier
<clever> red[m]: this generates a systemd service, which gets ran as a given user
<clever> red[m]: the modules are just a handy way to organize things that a service needs to run, and provide a simpler way for a user to enable it all at once
<clever> red[m]: there is basically no difference between configuration.nix and the modules in nixos
<clever> red[m]: it works in either one
<clever> red[m]: if you set ensureDatabases, then the script wont have to `su - postgres`, and can be ran without root
<clever> hpfr[m]: like -vvv or maybe -vvvv
<clever> hpfr[m]: try adding more -v's?

2019-10-11

<clever> red[m]: nixos has options to do that for you
<clever> so it never needs su, and never gains root
<clever> red[m]: if you set systemd.services.serviceConfig.User = "foo"; then systemd will drop-root for you
<clever> red[m]: that only triggers if you run the script as root
<clever> red[m]: a: su, b: why does the service need su?
<clever> red[m]: systemd will merge it with the other values
<clever> red[m]: you must set systemd.services.foo.path = [ pkgs.gawk ];
<clever> red[m]: systemd has a different default for PATH
<clever> danderson: ahh, it doesnt really keep much state either, so not much lost
<clever> AmandaC: i'll take another look at my code and see about fixign that
<clever> danderson: what was the one thing that changed?
<clever> danderson: ah yeah, thats a good catch
<clever> danderson: if you remove or change the stateVersion without reading them, then you may break the things its meant to not break, but you could just go ahead, and then fix whatever is broken
<clever> danderson: the release notes should have details on that kind of thing
<clever> danderson: postgresql uses stateVersion to control the version of psql, so you can access your db, and you must manually export it to .sql, upgrade, then re-import
<clever> danderson: sshd for example, at one point, it changed the type for ssh hostkeys, the upgrade is seamless, but it creates new hostkeys, causing mitm alerts for every single client, and nixos prefers to avoid causing such errors
<clever> danderson: in general, you need to figure out what services you use, that care about stateVersion, and then investigate what changes it will cause
<clever> AmandaC: oh, nice, thats much simpler then i thought
<clever> fuzen: note, that you need a linux build slave to build the linux build slave...
<clever> fuzen: just run `nix-build -A go` and then `./result` to boot it
<clever> you can then just add 127.0.0.1:2200 as a linux build slave
<clever> t
<clever> fuzen: it will use the darwin build of qemu to do tha
<clever> fuzen: this generates a script, that boots nixos under qemu
<clever> fuzen: i generally use dockerTools.buildLayeredImage
<clever> hpfr[m]: try `nix-build '<nixpkgs/nixos>' -A system -v` ?
<clever> ,profile
<clever> as long as you never move those to a 32bit only cpu, yep
<clever> AmandaC: for nixos, you must set nixpkgs.system, which is a nixos option
<clever> AmandaC: not really
<clever> AmandaC: pass system= to nixpkgs, any time you import <nixpkgs>
<clever> AmandaC: that tells the darwin machine, that it is a linux machine, and is capable of running linux binaries
<clever> AmandaC: --option system is your problem
<clever> AmandaC: it should also understand that linux things cant run on darwin, what command are you using to do the build?
<clever> AmandaC: can you pastebin the expression that is at fault?
<clever> AmandaC: your trying to run a linux binary on darwin, i think
<clever> AmandaC: it sounds like your mixing up linux and darwin binaries
<clever> Squarism: probably
<clever> yep
<clever> AmandaC: i have notes somwehre, but id have to dig thru them
<clever> Squarism: and use that to add both LambdaForms and servant-client-ghcjs
<clever> Squarism: you need to do haskell.packages.ghcjs86.override { overrides = self: super: { .... }; };
<clever> AmandaC: havent gotten that one solved yet, but i have seen signs that something related may already be in nixpkgs, need to look into that when i get a chance
<clever> Squarism: can you pastebin it?
<clever> Squarism: you need to add it with cabal2nix and an override
<clever> Squarism: servant-client-ghcjs doesnt exist in haskellPackages
<clever> correct
<clever> catern: the shellHook is an attribute of the derivation, and impacts the hash of $out
<clever> fresheyeball: if you are chaining several overrides, they wont
<clever> fresheyeball: use old.shellHook, not drv.env.shellHook
<clever> fresheyeball: it likely broke everything else :P
<clever> fresheyeball: you must not add a ghc to the inputs
<clever> theres your problem
<clever> fresheyeball: a: you appear to have 2 ghcWithPackages in buildInputs, which breaks everything
<clever> fresheyeball: what does `which --all ghc` return?
<clever> fresheyeball: its not using shellHook
<clever> fresheyeball: what are you overriding?
<clever> slyfox: --arg cant override that param
<clever> slyfox: simplest to just add doCheck = true; to the derivation in the nix file
<clever> fresheyeball: just open a shell on the .env attr, and it will do the ghcWithPackages for you
<clever> fresheyeball: the .env attr will run ghcWithPackages for you
<clever> slyfox: doCheck = true;
<clever> fresheyeball: nope, since ghc needs all of the pkg files in a single directory
<clever> fresheyeball: ghcWithPackages generates a shell script called ghc, that changes the dir ghc looks in for the pkg db
<clever> infinisil: nix-diff will diff drvs
<clever> yeah
<clever> __monty__: the problem is that an env var is incorrectly set to /build, when ti shouldnt be
<clever> __monty__: its a bug in nix, that seems to only occur on non-nixos machines
<clever> __monty__: you can also add sandbox = false to /etc/nix/nix.conf
<clever> __monty__: --option sandbox false
<clever> and with buildkite/frontend being archived, i dont know if the source is up to date anymore
<clever> i'm not sure what the difference is between ~~~ and ---, they both seem to be top-level folds, but different colors
<clever> yeah, that looks nice
<clever> gchristensen: you could give each nix-build command its own ~~~ header
<clever> gchristensen: check the screenshots in https://github.com/buildkite/frontend/issues/421
<clever> 1 ~~~ Running global environment hook
<clever> gchristensen: if you download the raw log for a buildkite build, you can see its using ~~~
<clever> gchristensen: buildkite uses any repeated character i think, ive seen `set -x` trigger it
<clever> gchristensen: thats why you have a fold that says `Running build script`
<clever> gchristensen: if you do `echo ~~~ header` in a buildkite script, it will fold the logs, and label this section with header
<clever> gchristensen: have you seen the `echo ~~~` trick with buildkite?
<clever> gchristensen: nice
<clever> Minall: the service is called display-manager
<clever> arianvp: sounds similiar to my nixops plans with `nix copy`
<clever> hpfr[m]: journalctl -t xsession, i think

2019-10-10

<clever> higherorder: nix show-config | grep sub
<clever> yeah
<clever> which turns into: import ${src} {}
<clever> asheshambasta: in the case of termonad, the default.nix returns a function, so you then have to give that function some arguments
<clever> asheshambasta: which was in the reply on the discourse page
<clever> let src = fetchFromGitHub {...}; in import "${src}/release.nix"
<clever> then you need to add another string onto the string
<clever> if you give import the path to a directory, it loads the default nix file
<clever> import will just take the path to a .nix file, and return whatever the top-level expr is
<clever> "/nix/store/rcka5aqdhlnyb260d0wvbz2acxb8cvsx-source" in this case
<clever> it returns a string, pointing to a directory where the fetched thing exists
<clever> fetchFromGithub is a function, that will generate a derivation, which fetches things (from github)
<clever> can you paste another gist with your latest code?
<clever> exact same error? it shouldnt be
<clever> asheshambasta: https://discourse.nixos.org/t/how-to-install-package-from-github/444/3 and the answer is already in the link you gave
<clever> updated my gist
<clever> and it then returns a derivation
<clever> the default.nix defines a function, so you need to at least add a {} at the end of my example, to call it with something
<clever> and the gist i linked
<clever> yeah, you want IFD, refer to what {^_^} said above
<clever> asheshambasta: https://gist.github.com/cleverca22/7b604cab0bdd345a3e6228968313cd38 will probably get you closer
<clever> so you cant run it in a shell script
<clever> default.nix is not a shell script
<clever> doing it all wrong*
<clever> asheshambasta: no, i mean your doing it all write, and the lack of +x is stopping things from going any further
<clever> ,ifd asheshambasta
<clever> asheshambasta: does that file have the +x bit?, no, so permission denied, you cant exeute it
<clever> asheshambasta: that sets the buildPhase to "/nix/store/rcka5aqdhlnyb260d0wvbz2acxb8cvsx-source/default.nix"
<clever> asheshambasta: you cant use nix-build inside a derivation
<clever> asheshambasta: can you pastebin the nix expr, and the full output when it fails?
<clever> asheshambasta: a derivation can only write to $out or $NIX_BUILD_TOP
<clever> asheshambasta: any other derivation you recieved as an input
<clever> asheshambasta: any time you try to write to one of your inputs
<clever> and some other minor search paths that go into env vars, like man pages
<clever> arianvp: i think the main thing is just somewhere to point $PATH, and to act as a gc root

2019-10-09

<clever> so it just blindly allows 32bit on 64bit
<clever> likely because your nix is too old to support it
<clever> __monty__: it has a default
<clever> __monty__: there should be an extra (system|platform) thing
<clever> [root@amd-nixos:~]# nix show-config | grep platform
<clever> extra-platforms = i686-linux
<clever> and building with --keep-going
<clever> id say try updating the remote nix node
<clever> __monty__: what version is the remote nix?
<clever> __monty__: it should have some defaults, what does just `nix show-config` output?
<clever> __monty__: what about `nix show-config | grep feature` on the remote machine?
<clever> __monty__: what is the contents of /etc/nix/machines ?
<clever> __monty__: that error has nothing to do with trusted users
<clever> __monty__: what file are you editing? does it appear in `nix show-config`, what is the actual error?
<clever> inkbottle: i just install ghcid into my profile
<clever> inkbottle: but if you have a cmd that can convince stack to give you a repl, you can pass that to `ghcid -c "..."`
<clever> inkbottle: `ghcid -c "runhaskell Setup.hs repl lib:cardano-explorer"` is what i use, and i just ignore stack entirely
<clever> shmish111: https://github.com/cleverca22/nix-tests/blob/master/haskell-init/default.nix is based on nh2's repo, and boils it down to the simplest expr possible
<clever> elvishjerricco: try turning on the log-to-file flag i linked?
<clever> elvishjerricco: logToJournal defaults to true, and i think you read it with `journalctl -t xsession` ?
<clever> na, that looks dead
<clever> -rw-r--r-- 1 clever users 9.7K Aug 5 2016 .xsession-errors
<clever> elvishjerricco: what about ~/.xsession-errors
<clever> elvishjerricco: *looks*
<clever> elvishjerricco: `journalctl -f -u display-manager.service` i think

2019-10-08

<clever> pie__: if free space goes under 3gig, it will delete enough to put it above 6gig
<clever> pie__: have you tried min-free based collection?
<clever> hyperfekt: i wouldnt expect that to cause such an error
<clever> hyperfekt: oh, thats weird
<clever> hyperfekt: .device is only for non-efi usage
<clever> hyperfekt: you set boot.loader.grub.device = "nodev";
<clever> hyperfekt: also, nixos-install is just a script that does `nixos-rebuild` in a chroot for you
<clever> hyperfekt: yeah, enable cantouchefi, enable grub, and then `nixos-rebuild boot --install-bootloader` again
<clever> hyperfekt: can you try switching to grub with efi?
<clever> hyperfekt: try reading the systemd config file, and confirm what params are in it
<clever> hyperfekt: that means the init= is missing from the kernel params
<clever> hyperfekt: what exactly doesnt work?
<clever> hyperfekt: and is the uuid its listing, the right one for your boot partition?
<clever> hyperfekt: what does `efibootmgr -v` report?
<clever> hyperfekt: what exactly isnt working?, which boot loader are you using?

2019-10-07

<clever> kyren: doesnt matter that much
<clever> kyren: is nix-daemon still running?
<clever> kyren: did you fully remove nix before trying to switch?
<clever> kyren: first, are you on a singleuser or multiuser setup?
<clever> kyren: it should be fairly simple to upgrade nix without that script
<clever> qyliss: the new nvme controller is non-standard, and requires kernel patches!!
<clever> qyliss: even if you try to nixos your mac hardware, your in trouble!
<clever> selfsymmetric-pa: rec in the override wont really make it work any better, as for sharing the rev and version, you can use either rec or let
<clever> selfsymmetric-pa: the values get baked in at parse time, and you have no way to change them
<clever> selfsymmetric-pa: thats just a nasty side-effect from using rec
<clever> selfsymmetric-pa: you need to override version, rev, buildFlagsArray, and src
<clever> selfsymmetric-pa: thats why i avoid using rec whenever possible, it just leads to confusion
<clever> the channels hydra provides*
<clever> mishac: ive never used the channels nix provides, i just git clone whatever repo the hydra is following
<clever> mishac: how did you add it?
<clever> mishac: you can just use nix-build and normal nix-env on the beaglebone too
<clever> the next logical step, if you want a more interactive workflow, like make && ./test, is to just run `nix-shell` right on the beaglebone
<clever> installing is optional, since you can just directly run it from /nix/store
<clever> or install it: nix-env -i /nix/store/hash-test/
<clever> either directly, /nix/store/hash-test/bin/test
<clever> paste that path to nix-copy-closure (or use readlink result), and then use the same path on the beaglebone
<clever> nix-build told you what path it just build
<clever> mishac: when you tell nix to copy test over, nix already knows what test depends on, and copies them as well
<clever> and those changes are generally small
<clever> mishac: when you re-build something, and re-copy it with nix-copy-closure, only the derivations that have changed will get copied
<clever> mishac: it sounds like your just trying to fix nix's help at every step?
<clever> mishac: you want to edit the nix exprs, so nix does the patchelf for you, and the working binary is in /nix/store/
<clever> nix will deal with copying anything it depends on
<clever> mishac: you can copy only the final thing with the binaries you want
<clever> mishac: you dont need gcc to be copied to the beaglebone
<clever> mishac: different hashes?