2019-06-02

<clever> root3: one min
<clever> root3: that likely wont help
<clever> root3: i cant reproduce the problem on that rev
<clever> root3: nix eval nixpkgs.lib.version
<clever> root3: thats more down to your nixpkgs rev, then your arch
<clever> simpson: it may be on a nixpkgs rev that has since fixed it, or not yet broken
<clever> the sha256 guards against user error, and it wont use any wrongly made tars
<clever> and then the user must download the file, and run nix-store --add-fixed on it
<clever> you give a url, sha256, and a msg to the user
<clever> o1lo01ol1o: requireFile can deal with that issue
<clever> and if you didnt, it gives html asking you to do so
<clever> some websites force you to agree to a license
<clever> no need for fetchurl, it doesnt have to fetch a url
<clever> src = /Users/timpierson/Downloads/vulkansdk-macos-1.1.106.0.tar.gz;
<clever> note, if you want a local file, just use a local file
<clever> once you fix the src, you can likely undo all of the unpack stuff
<clever> that would explain why the default unpackPhase didnt work
<clever> file /nix/store/aqzbskifzn9qqzi03ca440z90fxziajp-vulkansdk-macos-1.1.106.0.tar.gz
<clever> for $curSrc
<clever> what did the ls say?
<clever> so it will just never try to unpack $src
<clever> o1lo01ol1o: unpackPhase = "true"; disables running unpackCmd
<clever> o1lo01ol1o: can you pastebin your entire nix expression?
<clever> curSrc only exists when unpackCmd is being ran
<clever> o1lo01ol1o: try putting it first instead
<clever> try unpackCmd = ''tar xvf $curSrc ; ls -l $curSrc'';
<clever> try unpackCmd = ''tar xvf $curSrc ; ls -l'';
<clever> oh, but your setting unpackCmd, so unpackPhase should do that for you...
<clever> o1lo01ol1o: you need to set sourceRoot="foo";
<clever> ,locate 2nix
<clever> ,locate bin mcs
<clever> ,locate ,bin mcs
<clever> iqubic: dont know of any
<clever> iqubic: then put mono in the buildInputs and use buildPhase to run it on the src

2019-06-01

<clever> nh2: also, i dont think it uses this, when choosing to use a label
<clever> fileSystems.<name?>.label
<clever> and if you specify sda directly, you risk blowing away the MBR on a windows disk randomly
<clever> but, mbr and gpt both lack disk-wide uuid's
<clever> you must give it the root of a device, like sda (or a symlink to sda)
<clever> nh2: oh, and a very very anoying problem with legacy grub
<clever> even if its unrelated to your target rootfs
<clever> if ANY usb mass-storage is connected, it will include mass-storage support in your initrd
<clever> ive also seen purity bugs in nixos-generate-config
<clever> lsblk understands luks, and knows that /dev/mapper/root is contained within nvme0n1p2
<clever> nh2: lsblk can also be interesting to look at
<clever> nh2++
<clever> nh2: yep
<clever> since nix strips common indent for you, nix files dont turn ugly like that
<clever> so bash forces you to not indent that block, and make a mess of the whole file :P
<clever> and the indent on each line within is kept
<clever> <<EOF only stops if it finds another EOF at the START of a line
<clever> m1crOman: uglyness like this is what happens when common indent isnt stripped
<clever> ''string'' will remove all common indent, creating nice output on the other end
<clever> both "string" and ''string'' support multiple lines, but "string" will perserve all the indenting and make a mess of your output
<clever> m1crOman: this is a chunk of haskell code, right in a nix string
<clever> m1crOman: i just put multi-line strings all over the place
<clever> yes
<clever> m1crOman: just put regular old newlines inside a ''string'';
<clever> nh2: nothing directly setting the ip there, but you will want to read the config in the initrd too, which could be tricky to access
<clever> when in rescue
<clever> nh2: what does /proc/cmdline show?
<clever> nh2: no dhcp running, and an ip is setup in /etc/network/interfaces
<clever> nh2: double-checking...
<clever> i think the cache is only to allow non-root users to query things
<clever> blkid will just read the device you point it to, it doesnt really cache things much
<clever> nh2: if ovh doesnt have dhcp services, youll need to staticly configure it in nixos as normal
<clever> nh2: that sounds like a bug in nixos-generate-config, where its using the old uuid, rather then getting the real one with blkid
<clever> nh2: if you dont want swap, you can also remplace the mdadm+lvm+ext4 layers all at once, with just zfs
<clever> nh2: and this just stops you from importing it while in-use, it doesnt mess with the name after the import is done
<clever> nh2: zfs lets you clear that binding by just exporting the pool when your done, and you can ignore it with a force import
<clever> to allow importing from the wrong hostid, you must `zpool export` to fully close it
<clever> and that makes it safe to have zfs on a network block device, since you cant accidentally import a pool thats still in-use by another box
<clever> nh2: at normal shutdown, that hostid is still using it, so other machines cant import it without using the force flag
<clever> nh2: with zfs, when you import(/assemble/mount) a pool, it marks the hostid that is currently "using" it
<clever> nh2: ah, that weirdness reminds me of zfs and hostid's
<clever> then both will refer to the same version
<clever> o1lo01ol1o: you need to override haskell-src-exts = haskellPackagesNew.haskell-src-exts_1_21_0;
<clever> o1lo01ol1o: its pulling in the 1.21 version, which breaks it
<clever> > haskellPackages.haskell-src-exts_1_21_0
<clever> > haskellPackages.haskell-src-exts
<clever> ah, i see the problem
<clever> o1lo01ol1o: try adding an override to haskell-src-exts= as well?
<clever> o1lo01ol1o: what is the error?
<clever> o1lo01ol1o: which packages is it getting doubles of?
<clever> that is weird
<clever> nh2: note that there are many uuid's at play, the partition uuids, the raid uuids, and then the fs uuids
<clever> nh2: have you tried addding boot.allow_shell to the kernel args, so you can get a shell in the initrd?
<clever> nh2: double-check that the uuid's are correct, or use labels instead
<clever> its probably cabal being paranoid, checking $PATH, and complaining that $out/bin isnt in $PATH (yet)
<clever> Guest74468: are the binaries in /run/current-system/sw/bin/ ?
<clever> drakonis: nix-store --verify --check-contents
<clever> drakonis: yeah, re-opening the shell will remove it from NIX_PATH
<clever> then another --update
<clever> rm /home/drakonis/.nix-defexpr/channels
<clever> its a symlink into the store
<clever> i said just rm
<clever> what is the exact command you ran?
<clever> it shouldnt be
<clever> try deleting /home/drakonis/.nix-defexpr/channels then, just simple rm
<clever> oh
<clever> i dont think lustrate has much to do with this
<clever> drakonis: double-check the contents of ~/.nix-channels
<clever> but home manager is likely using <nixpkgs> (as nonroot)
<clever> i can also see that <nixos> and <nixpkgs> (as root) will map to the channel you want, with the new version
<clever> thats saying you currently have 2 chnanels on your user, home-manager and nixpkgs, try running `nix-channel --update` again and see if it changes anything?
<clever> can you pastebin the output of `ls -l /home/drakonis/.nix-defexpr/channels*/`
<clever> when did you last --update without root?
<clever> thats strange
<clever> and what exactly does nix-channel --list return? on both users
<clever> that means you have a channel called nixpkgs on your current user
<clever> /nix/var/nix/profiles/per-user/root/channels/nixos
<clever> ]$ nix-instantiate --find-file nixpkgs
<clever> drakonis: what does `nix-instiate --find-file nixpkgs` return?
<clever> drakonis: what does `nix-channel --list` report for both your user and root?
<clever> drakonis: on darwin?
<clever> drakonis: what is the exact command you ran?
<clever> drakonis: which user are you doing --update as?
<clever> nh2: grub does actually support /boot being on luks, but ive not tried using it
<clever> nh2: it sounds like your grub binary has memory leaks in some of its FS drivers
<clever> nh2: grub-install mentions encrypted volumes??
<clever> so i often ssh into one from the other
<clever> i use my laptop as a 4th monitor
<clever> or your switching between many pre-existing terminasl
<clever> if the shell init stuff is off
<clever> colemickens: try running an UPDATESTARTUPTTY on an ssh link, then use gpg elsewhere on the same box the ssh goes into
<clever> even if you have since walked away from that tty
<clever> so the pinentry stuff starts asking you over the ssh session
<clever> colemickens: line 87 runs any time you open a terminal, including over ssh
<clever> colemickens: and because i run screen, that just makes things worse, it maps to the tty above screen, not inside screen
<clever> colemickens: ah, from reading that gpg page, i'm guessing nixos runs `UPDATESTARTUPTTY` any time you login over ssh
<clever> i just have normal keys in my gpg state, no hardware tokens
<clever> oh, and gpg-agent has been giving this error for months, any idea what the solution is?
<clever> agent key RSA SHA256:Xn2yZ3FAQeRqcF7EDiXsPtiuptNLzEAxtOo1DRDzhDM returned incorrect signature type
<clever> and you dont notice it, so ssh just appears to lock up
<clever> the problem it causes, is that any time it wants a password, the prompt opens in a terminal in the other room
<clever> if you turn it off, then it just goes to the first place you logged in, which is typically your X11 session
<clever> selfsymmetric-mu: so the unix socket maps to wherever you last "logged in"
<clever> selfsymmetric-mu: its more that the nixos options tie it into systemd/logind, and rebind to any login sessions
<clever> and then the passphrase prompts open in that ssh session, not in xfce!
<clever> selfsymmetric-mu: if you turn on the gpg-agent stuff in nixos, it will auto-restart it, any time you connect over ssh
<clever> selfsymmetric-mu: i'm not really sure how i setup gpg-agent, i cant find it in ~/.bashrc or anywhere else obvious, and i know i didnt turn on programs.gpg-agent, that causes even more trouble
<clever> selfsymmetric-mu: that means the parent process has since quit
<clever> selfsymmetric-mu: `ps -eH x` and see what the parent process is

2019-05-31

<clever> samueldr: hydra-build-products would make it a lot simpler
<clever> nefix: you can do that on any arch with nix installed
<clever> nefix: just run `nix-store -r /nix/store/hash-foo` on the storepath in hydras details page
<clever> fresheyeball: try grepping the nixpkgs src for networkmanager
<clever> fresheyeball: some things like gnome enable it automatically
<clever> well, 2 if you only look at the first level, but it casdades up the tree
<clever> catern: if you have 2 nearly identical derivations, for the same thing, but on 32 and 64bit, they will still differ in many ways: the system attribute, the storepath for all of its inputs (32 or 64bit version, which each have the same difference casdading)
<clever> habbah: haskell.lib.doJailbreak
<clever> after that, its all fairly obvious stuff, based on insmod cmds in grub.cfg
<clever> nh2: then it loads the normal module, which upgrades grub from the bare-bones rescue mode, to a fairly fully functioning grub (adds help, and tab completion)
<clever> -rw-r--r-- 1 root root 113K Sep 17 2018 /boot/grub/i386-pc/normal.mod
<clever> combined, that is enough to find /boot, and read more files at runtime
<clever> nh2: and then it will merge boot.img and your MBR together, and update the offset/length that refer to the bios-boot-partition
<clever> -rw-r--r-- 1 root root 512 Sep 17 2018 /boot/grub/i386-pc/boot.img
<clever> nh2: basically, grub will merge the core and the driver for the /boot fs, then write the merged result into the bios-boot-partition
<clever> -rw-r--r-- 1 root root 5.9K Sep 17 2018 /boot/grub/i386-pc/ext2.mod
<clever> -rw-r--r-- 1 root root 26K Sep 17 2018 /boot/grub/i386-pc/core.img
<clever> nh2: i think it only needs ~30kb
<clever> the grub on in the bios-boot-partition will fail to load the bulk of grub, and drop you into a rescue shell with very limited capability
<clever> so you need a /boot partition on the non-nvme disk, or switch to efi
<clever> but if your booting in legacy, it cant access the EFI firmware
<clever> grub technically doesnt support nvme, it relies on the EFI firmware to provide nvme drivers
<clever> that likely explains all of your problems
<clever> nh2: also, if you put grub on the non-nvme disk, it cant access a nvme /boot while booting
<clever> nh2: nvme cant boot via legacy, only efi
<clever> nh2: what type of ssd is it?
<clever> nh2: yeah, sounds like you want to go into the bios, and turn off efi booting
<clever> mac10688: what is the other OS?
<clever> samueldr: the paths of the inputs appear within the disk image file, so the disk image depends on its inputs
<clever> nh2: i would try adding the SSD to the devices
<clever> nh2: what FS is / on? is there any raid involved?
<clever> samueldr: i once moved a win95 machine to a nearly identical laptop, and it never ran right since
<clever> nh2: why are you setting the grub device to 4 different drives? and what is special with / and /boot ?
<clever> i think i'm on soyoustart
<clever> ive had to use activex *barf* based KVM before, lol
<clever> no kvm access on my ovh box
<clever> ah
<clever> nh2: where are you getting a black screen, how are you looking at the monitor?
<clever> nh2: have you tried it with just one entry, on the same device as a single /boot partition?
<clever> nh2: what is boot.loader.grub.device set to?

2019-05-30

<clever> fasd: i try to avoid autoUpgrade, it tends to waste disk space and make things update when your not expecting, causing random changes/breakage
<clever> fasd: yes
<clever> so, callHackageDirect { pkg="foo"; ver="foo"; sha256="foo"; } {};
<clever> followed by the normal callpackage empty-set
<clever> it takes a set containing a pkg, ver, and sha256
<clever> mitch-1002: you probably want callHackageDirect instead
<clever> and this variant exists, if the version you want isnt in all-cabal-hashes
<clever> 183 callHackageDirect = {pkg, ver, sha256}@args:
<clever> then you can just nix-build -A ray-tracer
<clever> mitch-1002: yeah, that will be loaded by callPackage in another file, that other file is where you want callHackage
<clever> mitch-1002: can you gist that file?
<clever> mitch-1002: haskellPackages.callHackage
<clever> v0|d: dont remember, i dont really use clang much
<clever> infinisil: callPackage has to do it once, and then create a smaller lookup table, so each reference within your pkg is faster
<clever> infinisil: and the lookup cost within that
<clever> infinisil: the size of the pkgs attrset, and the number of attributes it contains
<clever> infinisil: i think its partially a performance cost
<clever> nh2: ive mainly used the kexec via ssh, and its configured to reboot itself at the end of the hour, to restore the old OS
<clever> nh2: thats possible, maybe baud rate stuff
<clever> nh2: does dhcp work on that machine?
<clever> nh2: you may also be able to just use justdoit, as-is
<clever> nh2: so i just replace all of configuration.nix with a static file
<clever> nh2: the bootloader stuff is in configuration.nix, but you mainly care about hardware-configuration.nix
<clever> nh2: ^^
<clever> samueldr: yeah, once you set boot.loader.grub.device = "/dev/sda";, it will scan sda's partition table, and find the bios boot on its own
<clever> nh2: youll just need to edit the generated config
<clever> nh2: you need a 1mb bios boot partition, at any offset, not formatted, not mounted

2019-05-29

<clever> v0|d: if your not, nix-shell -E 'with import <nixpkgs> {}; clangStdenv.mkDerivation { name = "thing"; buildInputs = []; }'
<clever> v0|d: if your using a normal default.nix/shell.nix, just change stdenv to clangStdenv
<clever> v0|d: clangStdenv
<clever> but the efivars have to be mounted seperately
<clever> sysfs will only generate that dir if efi is enabled
<clever> nh2: its based on the presense of /sys/firmware/efi/efivars
<clever> you will also need to ensue your using MBR partitioning, legacy on GPT needs another (unformatted) partition
<clever> nh2: and systemd-boot is EFI only, so you need to switch to grub.enable = true;
<clever> nh2: if you want a single-partition install, then you cant use EFI
<clever> nh2: ah, you also need to mount the efi system partition to /mnt/boot/ in that case
<clever> nh2: have you mounted /boot within the chroot?
<clever> nh2: then the problem is with /sys/firmware/efi/efivars, not /boot
<clever> circ-user-dLdoV: then it just needs to be in the cargo.toml, and the cargosha256 has to be updated
<clever> nh2: is the efivars fs mounted?
<clever> circ-user-dLdoV: is glutin a cargo crate?
<clever> circ-user-dLdoV: if you tell nix to override things and add glutin, it will automatically build from source and not use the cache
<clever> circ-user-dLdoV: even if you tell nix to rebuild from source, if you didnt add glutin, it will produce the same binary with the same problem
<clever> Ankhers: just install appimage-run, and then run `appimage-run the-app-image` i think
<clever> circ-user-dLdoV: why do you want to bypass the cache?
<clever> Ankhers: appimage-run
<clever> catern: ah, that sounds good
<clever> catern: ls and stat claim you can write to it, so that will be difficult to test, without just checking for errors
<clever> ah, nice!
<clever> catern: the kernel may not allow it, due to how the pipe was made
<clever> catern: now /dev/stdout is the | that sh made, and it still leads to nix
<clever> catern: this works
<clever> nix-build -E 'with import <nixpkgs> {}; runCommand "name" {} "sh -c \"echo foo > /dev/stdout\" | cat"'
<clever> catern: what if you | cat the problem program?
<clever> catern: i think stdout being a pipe made by something outside the sandbox is part of the problem
<clever> catern: i suspect its namespace problems, ive had similar trouble with nix-collect-garbage in a namespace
<clever> catern: libredirect
<clever> same
<clever> /build/.attr-0: line 1: /dev/stdout: Permission denied
<clever> nix-build -E 'with import <nixpkgs> {}; runCommand "name" {} "echo foo > /dev/stdout"'
<clever> catern: which would be identical to just `echo foo`
<clever> catern: that will be the stdout of the bash that is running echo
<clever> adding -l reveals its a symlink to fd1 on yourself
<clever> lrwxrwxrwx 1 nobody nogroup 15 May 29 20:23 /dev/stdout -> /proc/self/fd/1
<clever> catern: nix-build -E 'with import <nixpkgs> {}; runCommand "name" {} "ls /dev/stdout"'
<clever> neonfuz2: do you have existing things in your profile, or is it empty?
<clever> depends on if its PATH or library
<clever> ,runtimedeps
<clever> markasoftware: github probably has a cap on how many it will report
<clever> ,runtime
<clever> mruntime
<clever> enless it knows to read that file
<clever> but the program itself wont know where to find those things at runtime
<clever> yep
<clever> markasoftware: refer to them somehow in your output
<clever> its more of an example of how to do a specific task, rather then re-implementing all of nixpkgs!
<clever> though in both cases, i'm cheating a bit, by using things like writeText, fetchFromGitHub, and haskellPackages.ghcWithPackages
<clever> no cabal, no stack!
<clever> markasoftware: a second example i made more recently, where i'm directly using ghc as the builder, no stdenv, no generic-builder.nix
<clever> markasoftware: https://github.com/cleverca22/nix-tests/blob/master/bare-env.nix is an example i made 3 years ago, there is a .txt of the same name, with the output of it
<clever> markasoftware: and when suing derivation directly, builder must be an absolute path, and its ran with args
<clever> markasoftware: technically, it will turn $out into a NAR (nix-store --dump /nix/store/foo) and then grep that bytestream
<clever> markasoftware: yeah
<clever> markasoftware: using builder directly results in PATH not even being setup, and more work for you
<clever> markasoftware: in general, you want to use buildPhase or buildCommand, not builder, and then you can just give it a chunk of bash script
<clever> and even if you never use the `a`, it still fails
<clever> > let f = { a }: 5; in f 6
<clever> and this forces it to be a set, and unpacks the attrs for you
<clever> > let f = { a }: a; in f { a = 42; }
<clever> it all depends on what is done with x
<clever> this form can accept any type, including a set
<clever> > let f = x: x.a; in f { a = 42; }

2019-05-28

<clever> li_matrix: that specific example, is creating a tar that contains the runtime closure of a given thing
<clever> get the list of deps, for one of your deps
<clever> li_matrix: this will (at build time)
<clever> li_matrix: one min
<clever> li_matrix: you can get that list at build-time
<clever> li_matrix: what do you need that list for?
<clever> li_matrix: the runtime deps are based on the subset of buildtime deps, found in the built result
<clever> li_matrix: you cant

2019-05-27

<clever> talqu: and what does /etc/sudoers say about wheel?, do you know for sure the pw is correct?
<clever> talqu: does `id` say your in wheel?

2019-05-26

<clever> DigitalKiwi: ive also heard that production=false has higher ratelimits, but ive never ran into issues, since ive just set it right from the start by chance/luck
<clever> DigitalKiwi: nope, but i notice the IP on your domain is different