2018-06-01

<clever> codygman: if you wait a few minutes, does the flashing stop?
<clever> du --max=0 -hc $(nix-store -qR /run/current-system) | sort -h
<clever> oops, you want --max=0 on the above
<clever> --query --size will only show the size of a single dir, not the entire closure
<clever> acowley: i tend to use `du --max=1 -hc $(nix-store -qR /run/current-system) | sort -h`
<clever> acowley: one min
<clever> Guest70xxx: mumble/murmur
<clever> jophish: that looks like its failing to find the device tree blobs
<clever> Guest70xxx: you must set it in config.nix as the error tells you
<clever> Guest70xxx: configuration.nix doesnt effect nix-shell
<clever> jophish: sounds like a bootloader issue
<clever> Guest73580: nix-shell itself wont, but teamspeak will create ~/.ts3something
<clever> Guest73580: the above command stores the paths in /nix/store, and a normal nix-collect-garbage will delete all unused files in there
<clever> adamt: you would either need to add a subdir in nginx that shares all of /nix/store/ or setup symlinks in www-root every time you finish a build
<clever> adamt: replace with a server-side scripting language of your choice
<clever> adamt: that file receives the mac of the machine in the GET params, and it could just nix-build something on the fly, then respond with the path to the result
<clever> adamt: see the boot.php file in the example i linked above?
<clever> jophish: i havent done any fpga stuff since getting into nixos and haskell
<clever> jophish: i had partially implemented dhcp in verilog before deciding to use an ARM
<clever> adamt: this is how i run my pxe booting
<clever> adamt: yeah, nix-serve just shares the whole directory as a .nar.xz
<clever> the arm wasnt required to be in the loop, it was just to turn things on/off
<clever> jophish: my general plan, was to capture ~70mbit worth of data with an fpga, and shove it out ethernet
<clever> adamt: hash.narinfo and hash.nar.xz, for /nix/store/hash-foo
<clever> and then have some out of band traffic for other fpga stuff
<clever> jophish: my plan was to turn the fpga into an ethernet card, and then write a custom SPI based driver for it on the rpi
<clever> jophish: ive had plans to do something similar many years ago, but i didnt have any fpga's with a hardcore, so i was going to abuse an rpi
<clever> only 1 of my machines has enough space for that, lol
<clever> jophish: the last time i did fpga stuff, the tools took up something like 20gig, and i dont see nix playing well with a 20gig storepath
<clever> jophish: how did you get the fpga netlist building under nix?
<clever> jophish: nice
<clever> ikitat: time to change passwords?
<clever> jophish: https://github.com/cleverca22/crosspiroot is the older thing i made
<clever> ive used it to chroot into rasbian images before i discovered nixos
<clever> qemu-user would allow you to nixos-enter and then nixos-rebuild boot to apply config changes
<clever> mpickering: yeah, something seems off with the docker images
<clever> mpickering: i'm looking into it a bit on this end
<clever> mpickering: so the real question, is why does /lib exist in it?
<clever> mpickering: the root problem, is that all of the paths in the binaries are hard-coded to /nix/store/
<clever> they will only differ if it was a symlink
<clever> was that /lib or /lib/ ?
<clever> mpickering: what does `ls -l /lib` say when in the docker?
<clever> one min
<clever> and ghc is 1gig in size
<clever> mpickering: oh, if you want ghc to be in the image, then of course ghc is going to be in the image
<clever> mpickering: what storepath is the root of your dep tree, that you added to the docker image?
<clever> mpickering: then your real problem is that you depend on ghc at runtime, use `nix why-depends` to figure out why
<clever> mpickering: buildImage will always put a /nix/store/ into the image
<clever> mpickering: run ncdu on that store dir, what path within store is the biggest?
<clever> mpickering: i think thats so that docker just unpacks the whole file to a dir that becomes / after the chroot
<clever> mpickering: its probably because it expects you to mount that image as the rootfs
<clever> mpickering: where is buildImage putting the /nix/store, is that inside the disk image its making?
<clever> mpickering: can you give an example of the path your asking about?
<clever> which needs the OS to not be running
<clever> i first used it on one of my laptops, to move /nix from the / filesystem to a /nix filesystem
<clever> yep
<clever> minus the netboot
<clever> and it runs from ram
<clever> that is an entire nixos, in /boot, with its own option in grub
<clever> 3.9M -rwxr-xr-x 1 root root 3.9M Dec 31 1969 rescue-kernel
<clever> 385M -rwxr-xr-x 1 root root 385M Dec 31 1969 rescue-initrd
<clever> this is consuming 385mb on my /boot
<clever> yikes
<clever> Filesystem Size Used Avail Use% Mounted on
<clever> /dev/nvme0n1p1 511M 492M 20M 97% /boot
<clever> just an option if you choose to go that route
<clever> then your kernels are on ext4,but the efi loader is on the ESP
<clever> you can also mount the ESP to /boot/EFI/, set the right option in nixos, and then have an ext4 /boot that is not ESP
<clever> legacy booting with an encrypted /boot and grub requires entering 2 passwords, one for grub to open /boot, and a 2nd for the rootfs
<clever> UEFI requires a cleartext /boot
<clever> yeah
<clever> so i have a dataset for /, /nix, and /home
<clever> but i dont want snapshots on /nix
<clever> i also keep snapshots enabled in all of my datasets
<clever> zfs entirely solves that
<clever> also, when you split things between root and home, you have to pick the right sizes or you run into issues later
<clever> i just make 1 luks, and use lvm to split it up
<clever> so it doesnt ask for the pw twice
<clever> then that partition is uses as key material to decrypt 2 (or more) other partitions
<clever> yeah, its an ugly hack where your passphrase decrypts an extra paritition
<clever> thats why i put lvm inside luks
<clever> yep
<clever> you would need to either create 2 luks volumes, or use lvm to split the luks up
<clever> shachaf: you can also just do ext4 directly on the luks device
<clever> shachaf: swap on zfs has problems
<clever> shachaf: https://github.com/cleverca22/nix-tests/blob/master/kexec/justdoit.nix is how i automate my installs
<clever> shachaf: and my luks device tends to be LVM with swap + zfs
<clever> shachaf: i always do a cleartext /boot with an encrypted rootfs partition

2018-05-31

<clever> andrewmiller1: just mount the existing FS's and run that
<clever> andrewmiller1: it should be enough to just run `nixos-install` from the livecd after mounting, and it will repair nearly all of it
<clever> andrewmiller1: then everything in /nix is toast and you have to reinstall
<clever> andrewmiller1: thats the other database, which is safe to delete, `rm /root/.cache/nix/binary-cache-v5.sqlite*`
<clever> shachaf: they should be
<clever> andrewmiller1: what signs are saying its corrupt?
<clever> andrewmiller1: if that db is lost, then everything in /nix/store is toast
<clever> andrewmiller1: which nixos db?
<clever> nh2[m]: but in our case, its stack->ghc->gcc.exe
<clever> nh2[m]: i think we have been dealing with the exact same problem on windows, lol
<clever> rihards: the 6c064e6b1f3 at the end is a git rev
<clever> "18.09pre135256.6c064e6b1f3"
<clever> nix-instantiate '<nixpkgs>' -A lib.nixpkgsVersion --eval
<clever> maurer: on multi-user installs, its empty, because nix is in roots profile
<clever> maurer: on single-user installs, the install script has to install nix into that profile
<clever> yeah, that sounds useful
<clever> jbaum98: not sure
<clever> jbaum98: export variable
<clever> hyper_ch: double-check the settings in the dns registrar
<clever> the original admin of the site will need to fix their config at the registrar
<clever> r
<clever> so you have to know the answer, to find the answer, to be able to ask for the answe
<clever> hyper_ch: the nameservers behind roleplayer.org are ns6.roleplayer.org and ns5.roleplayer.org, but there are no glue records to say what IP to find them at
<clever> hyper_ch: they messed up the dns config
<clever> hyper_ch: ah, the glue records are missing, i see whats wrong
<clever> and it has dnssec
<clever> hyper_ch: if i try again with `dig +trace`, i can see the NS records still exist
<clever> hyper_ch: no response from the dns server
<clever> hyper_ch: depends on what it is
<clever> ryantm: yeah
<clever> ryantm: and are you on nixos?
<clever> ryantm: does nix-env -q say nix is installed?
<clever> ryantm: fun things happen when you later try to upgrade the system nix, and the one in nix-env stops it from upgrading
<clever> ryantm: but dont try to install nix with nix-env on nixos
<clever> moet: i would also have a nixpkgs-src.json that specifies where to fetch nixpkgs from, and point NIX_PATH to that
<clever> moet: you can also generally ignore that warning
<clever> moet: your running a different version of nix then the host
<clever> and nix-shell -p requires it
<clever> --pure will clear NIX_PATH
<clever> rotaerk: ive had to copy the teamspeak client binary because its being too smart about that
<clever> rotaerk: the problem is when the path to the exe winds up reading symlinks, and looks in the original derivation
<clever> rotaerk: now your 3rd derivation is just a 2 line bash script, that runs the haskell program, giving it a path to the shaders
<clever> ''
<clever> exec ${haskellthing}/bin/haskellthing --shaders ${shaders} "$@"
<clever> #!${stdenv.shell}
<clever> { writeScriptBin, shaders, haskellthing }: writeScriptBin ''
<clever> or writeScriptBin
<clever> in that case, id instead use runcommand
<clever> the tricky part is if you need to find that path at runtime
<clever> id just do the subdir in the shaders derivation
<clever> { buildEnv, shaders, haskellthing }: buildEnv { name = "both"; paths = [ shaders haskellthing ]; }
<clever> yeah
<clever> and both/default.nix just has { runCommand, shaders, haskellthing }:
<clever> so you can do packages = self: { haskellthing = pkgs.haskellPackages.callPackage ./haskellthing {}; shaders = self.callPackage ./shaders {}; both = self.callPackage ./both {}; };
<clever> rotaerk: if you do this, then every package defined inside packages, can refer to eachother, as-if they where all in nixpkgs
<clever> let pkgs = import <nixpkgs> {}; packages = self: { foo = self.callPackage ./foo {}; }; in pkgs.lib.makeScope pkgs.newScope packages
<clever> rotaerk: oh, let me find another example
<clever> rotaerk: buildEnv just merges 2 outputs into 1 with symlinks
<clever> rotaerk: runCommand may also help you with compiling the shaders, it just runs a bash script to create $out, all phase stuff is gone
<clever> rotaerk: there is no need to recompile the haskell code when changing the shaders
<clever> rotaerk: i would make it 3 derivations, the shaders, the haskell code, and then a `pkgs.runCommand` or `pkgs.buildEnv` that joins them up
<clever> mpickering: you may want to set Cmd to be a script, that just does `export src=${./.}` or similar, then runs bash
<clever> mpickering: oh yeah, .env lacks $src
<clever> mpickering: you may need to add at least a shell to the contents, and set a Cmd that gives you a working shell: https://github.com/input-output-hk/cardano-sl/blob/develop/docker.nix#L31
<clever> mpickering: how exactly didnt it work?
<clever> justan0theruser: so the uefi testcase, turned into directions on creating a uefi install
<clever> justan0theruser: gchristensen had made some code before, that tool the nixos-install tests, and auto-generated directions on how to install nixos
<clever> ref and/or rev
<clever> and if its a set, it will contain a url, ref, ref, and name
<clever> arg0 can either be a string, or a set
<clever> this is the source for builtins.fetchGit
<clever> but everything under builtins is part of nix, not nixpkgs
<clever> palo: (probably as root) do a nix-channel --update on that machine
<clever> palo: then it will use the nixpkgs for the host that is running nixops
<clever> palo: did you pin the nixpkgs with `nixops modify -I` (does `nixops info` show a -I nixpkgs=) ?
<clever> > "${ { outPath = "foobar"; } }"
<clever> "${ { outPath = "foobar"; } }"
<clever> adelbertc: treating an attribute set as a string always refers to .outPath automatically
<clever> > "${hello}"
<clever> > hello.outPath
<clever> > hello
<clever> yeah, and .outPath will still build it normally
<clever> adelbertc: it will build it as a normal non-root derivation, then pass you the path to the built product

2018-05-30

<clever> which would let you merge system.build.path with environment.systemPackages
<clever> i could see apply being used to turn something like a systemPackages list into a buildEnv
<clever> ah
<clever> i'm not sure what the differences is between apply and merge on a type
<clever> and types.comma i think its called
<clever> and also types.string which was deprecated
<clever> kreisys: and then the core of nixos, will throw an error if any module have set that special "optino"
<clever> kreisys: but there is also a module level assertion, which basically acts as a nixos option any module can set, and it gets merged between all modules
<clever> kreisys: the assert builtin has to deal with lazyness, you need to get it into the codepath, or nix will just silently skip over it
<clever> fin-ger: if your planning to reboot, you can also do `nixos-rebuild boot`
<clever> yeah
<clever> Jetien: its not a string though, its a path to a file
<clever> Jetien: you need an input on the jobset called ssh-config-file, then <ssh-config-file> will find that input
<clever> > let x = { repo, domain ? "gitlab.com" }: domain; in x { repo = "foo"; }

2018-05-29

<clever> depends on if you want the CI systems to silently ignore a major problem and take an hour longer for every build, or to fail and bring attention to it
<clever> ah yeah
<clever> just make hydra 404!
<clever> LnL: found a simpler fix that can also just be upstreamed: https://github.com/input-output-hk/iohk-ops/pull/348/files
<clever> Myrl-saki: i run a hydra
<clever> nas:/nas 1.3T 1.3T 2.6G 100% /nas
<clever> take that :P
<clever> Filesystem Size Used Avail Use% Mounted on
<clever> LnL: kk
<clever> LnL: source? that sounds like something i could use
<clever> LnL: nginx?
<clever> LnL: nix also has a bug where it fails to build if you ever gc something that the client thinks is in the binary cache
<clever> it manually extracts just 1 file to $out (i also missed -C $out), and then only that one file exists
<clever> this wont let it import any other file within the tar
<clever> import (pkgs.runCommand "name" {} "mkdir $out; tar -xvf ${pkgs.fetchurl {...}} path/within/tar/foo.nix")
<clever> elvishjerricco: something like this:
<clever> elvishjerricco: you would need to import from a custom derivation, that runs the right tar -x command

2018-05-28

<clever> tfc[m]: yeah, that should allow fetching from github
<clever> tfc[m]: you may need something like this
<clever> tfc[m]: one min
<clever> tfc[m]: is your code on github?
<clever> unreleased changes to opensource software?
<clever> jtojnar: i suspect that soundnode made changes to the electron build and didnt document them, might even be a license issue??
<clever> jtojnar: soundnode is an electron based app i came across a few months ago, that refuses to work with the nixpkgs electron
<clever> worldofpeace: i have patched a "mac" electron app for linux before, all i did was extract the JS from the .pkg file, then run the linux build of electron against it via pkgs.electron
<clever> mjrosenb: the problem is just that nobody has written a nix derivation that runs otool against the darwin build of oraclejdk
<clever> mjrosenb: the util for patching things on mac is called otool
<clever> the example even shows xrandr commands
<clever> sir_guy_carleton: ah, the setupscript will run after X is started, before you login, so that could be better
<clever> sir_guy_carleton: the display manager will run this after you login but before launching the desktop manager
<clever> sir_guy_carleton: https://nixos.org/nixos/options.html#services.xserver.displaymanager.sessioncommands
<clever> sir_guy_carleton: you can either configure nixos to run it after you login (the login page wont be on the right monitors), or you can somehow configure the DM to run the cmd, or you can configure a default in xorg with xrandrHeads
<clever> sir_guy_carleton: X isnt running until after the display-manager has started, so xrandr will fail when ran before
<clever> same
<clever> overrideAttrs should be the right one
<clever> very
<clever> yes
<clever> and thats based on the nix expressions, and that users config.nix
<clever> yeah
<clever> and then its al .drv files from then on
<clever> Unode: the user running nix-build will eval all expressions, convert them into .drv files, and forward the .drv files to nix-daemon, which puts them into the store
<clever> Unode: the nix expressions are no longer in the picture once things reach nix-daemon
<clever> same
<clever> you should never be modifying any file in nix/store
<clever> and how did you modify that?
<clever> Unode: did you tell it to use the new nixpkgs path?
<clever> Unode: i'm out of ideas then
<clever> Unode: thats what the above should answer
<clever> they only ever operate on .drv files
<clever> nix-daemon and the build users never read nix files
<clever> can you pastebin the result of `nix-instantiate '<nixpkgs>' -A findutils -vvvvv`
<clever> does ~/.config/nixpkgs/config.nix exist?
<clever> Unode: where did you put your config.nix file?
<clever> and the phase is entirely absent
<clever> Unode: or just run cat on it
<clever> what is the output of `nix show-derivation /g/bork3/home/mocat/nix/store/0a8aq0zicr8brd1lvj0swgd3vya0npgy-findutils-4.6.0.drv` ?
<clever> ah, i see
<clever> Unode: and why does that not begin with /nix?
<clever> /g/bork3/home/mocat/nix/store/0a8aq0zicr8brd1lvj0swgd3vya0npgy-findutils-4.6.0.drv
<clever> the nix output
<clever> Unode: i need the tail end of it, after it fails
<clever> Unode: can you pastebin the entire console output?
<clever> Unode: the output nix prints when failing should answer that question
<clever> if phases is empty, it should use the default phases
<clever> Unode: and if it still fails, pastebin the entire output of the console when it failed
<clever> that too
<clever> installPhase, fixupPhase are also needed
<clever> Unode: as am i
<clever> ThatPako: that doesnt sound like a driver issue
<clever> Unode: heh!
<clever> ThatPako: you have to add the drivers to services.printing.drivers
<clever> Unode: what about checkPhase = ":"; ?
<clever> Unode: and `nix-build '<nixpkgs>' -A findutils` also fails?
<clever> Unode: and what command is starting the build?
<clever> Plato[m]: can you run `ls -l /nix/var/nix/profiles/` ?
<clever> Unode: what about doCheck = null; ?
<clever> which is usually managed with nix-env
<clever> the user environment is just a directory that the ~/.nix-profile symlink points to
<clever> sonne: all installations are done by a non-root user, and then nix-daemon chowns it to root after its done
<clever> sonne: no setuid binaries are allowed in the store
<clever> sonne: thats just how nix works, anything any user installs is put in /nix/store and owned by root
<clever> jD91mZM2: it needs boot at /mnt/boot or it will not be able to update the bootloader config
<clever> boothead: yep
<clever> boothead: and you need to make sure boot is also mounted
<clever> boothead: yeah
<clever> jD91mZM2: nixos-install currently has a bug, where it will recreate your entire os in ram, then copy the changes to disk
<clever> boothead: you can also use `nixos-enter` and then `nixos-rebuild boot` from the install cd, so reinstall faster
<clever> jD91mZM2: if the grub version differs from what is on-disk, it can reinstall the bootloader automatically
<clever> mjrosenb: does the file behind $NIXPKGS_CONFIG exist?
<clever> its only looking for ~/.config/nixpkgs/config.nix
<clever> which only effects the nixpkgs used within configuration.nix
<clever> mjrosenb: also note that configuration.nix has its own setting for that
<clever> true
<clever> mjrosenb: [clever@amd-nixos:~]$ nix-instantiate --eval -E 'with import <nixpkgs> {}; config.allowUnfree'
<clever> so it wont work on mac
<clever> all the package does is patch the linux .tar.gz
<clever> mjrosenb: oraclejdk isnt available on osx
<clever> mjrosenb: that one is always hiding unfree software
<clever> snot and mjrosenb: may also want to look at https://github.com/NixOS/nixpkgs/issues/17126
<clever> snot: i see all of these when i tab-complete cit in nix-repl
<clever> citra citrix_receiver citrix_receiver_13_4_0 citrix_receiver_13_5_0 citrix_receiver_13_6_0 citrix_receiver_13_7_0 citrix_receiver_13_8_0 citrix_receiver_13_9_0
<clever> snot: you will need to write an override to change the src
<clever> mjrosenb: if unfree packages are enabled, it will return unfree packages
<clever> nix-env currently has a bug where it cant show that error
<clever> once you enable unfree things, the nix-env command i gave will work
<clever> snot: and `nix-build '<nixpkgs>' -A citrix_receiver --no-out-link` ?
<clever> sauyon: nix-env -iA nixos.citrix_receiver