2019-06-09

<clever> nix-build '<nixpkgs>' -A wineWowPackages.stable
<clever> laalf: i think this one
<clever> > wineWowPackages.stable
<clever> pie__: i should get to bed, its 8am, lol
<clever> currently, the /boot must be either ext4 or vfat, and it cant be encrypted
<clever> all of the config is done at nix eval time, and it generates a simple bash script with no control flow
<clever> adamantium: justdoit does the same thing
<clever> some may transition to active when you rename things
<clever> pie__: zpool create turns all features on by default
<clever> pie__: cross-refernece the zfs man pages, to see which features are read-only-compatible
<clever> "it boots, ship it"
<clever> nobody tested it on nix sizes dirs :P
<clever> pie__: and grub didnt support all the types
<clever> pie__: its more that zfs changes the type of a directory as the size grows, to keep it fast
<clever> but its a complete reimplementation of the zfs driver, so the ARC doesnt really exist
<clever> i suspect its running in 16bit mode, but i'm not sure :P
<clever> pie__: it has had problems before where it cant even read a file in /nix/store/ because the directory is too large
<clever> pie__: ive never trusted the grub zfs support
<clever> pie__: my guess is that a feature grub doesnt support was set
<clever> hyper_ch: havent tried it yet
<clever> but its still ext4 /boot/
<clever> and due to "recent" additions to nixos, it only prompts once
<clever> zfs and swap are now on seperate luks devices, that share the passphrase
<clever> ok, i have redone my justdoit script to remove lvm
<clever> but virtio devices dont appear in disk/by-id, so it breaks VM booting
<clever> nixos changes it to make the boot faster
<clever> but that winds up even searching floppies :P
<clever> for manual importing, i think it defaults to /dev/
<clever> under the initrd at least
<clever> which defaults to /dev/disk/by-id
<clever> on my real system, it doesnt list imported pools
<clever> that explains why its just "root" there
<clever> oh wait, i ran that test in the VM by accident, lol
<clever> not sure what the temp2 refers to
<clever> aha, so thats how you list un-imported pools, lol
<clever> pie__: so it should be the original name to boot
<clever> pie__: the name may be baked into the grub stage 1.5
<clever> lvm headers contain the list of fragments, and which disk each fragment is on, and it just tells DM to piece it all together and handle the rest
<clever> and once you decrypt the master key, it just tells device-mapper to handle the rest, with the offset for the ciphertext, and the masterkey
<clever> all contain the same master key
<clever> the luks header has multiple key slots, each can be encrypted with a different passphrase (or keyfile)
<clever> luks and lvm both use device-mapper
<clever> pie__: dmsetup ls, would have shown lvm anyways
<clever> yorick: i turned it off in my personal hydra, since the spinning rust is rather slow
<clever> that example from yesterday, was importing the default.nix within the tar
<clever> import takes a path (not a bash script) and then returns the nix value within that file
<clever> eyJhb: why are you trying to import it?
<clever> > lib.replaceStrings ["foo"] ["bar"] "foobazfoo"
<clever> eyJhb: and functions work the other way around
<clever> pie__: dmsetup ls?
<clever> swap, zfs, nfs, losetup, device mapper
<clever> pie__: kernel stuff isnt visible to lsof
<clever> eyJhb: when doing .overrideAttrs (drv: { ... }), the drv is an attrset containing the old stuff
<clever> pie__: i forgot to close my swap device on that last install, and couldnt close the swap luks device, did you check your swap?
<clever> pie__: i would think so, i would do a sync just to be paranoid
<clever> first, i'll drop the lvm
<clever> pie__: cat /proc/mounts ?
<clever> pie__: going to experiment with more crazy installs now...
<clever> pie__: did you export it in zfs first?
<clever> pie__: if you have a (crypto0) then that was already ran
<clever> pie__: i think its dynamically generating a grub config file, that calls luks_mount with the right params, and then gets sourced
<clever> still measuring that, dont have the final hardware to test against yet
<clever> but now its all zvols, so its just a rollback away
<clever> dhess: and because apple keeps breaking compat with nix, we have been hesitant to upgrade things, since there is no easy downgrade
<clever> dhess: but now its just a qemu running under systemd, ssh in, systemctl restart mac-vm, done
<clever> dhess: with services like macindloud, every time the machine hangs, you have to open a ticket and wait for them to reboot it
<clever> dhess: yeah, darwin in qemu, on nixos, on apple hardware
<clever> dhess: testing that out now, its based on the nixos-org version of that
<clever> my test has ext4 /boot/
<clever> and (proc) is just an FS of type procfs, with no contents
<clever> pie__: it looks like grub was expecting one type, but after reading the node, found the type to be different
<clever> pie__: i believe @ is the root of the zfs pool, which would get mounted to /tank in my example
<clever> pie__: if i ls the partition, i just get the type again, but if i tack a / on, i get all datasets within the pool (and an error), https://i.imgur.com/7yBnKpi.png
<clever> pie__: tab completion without any luks, on a (assumed working) install, https://i.imgur.com/qmZnAmv.png
<clever> but i can see it still needing a backdoor for the initial deploy, to set it up
<clever> dhess: ive also thought about how nixops should manage wireguard for you
<clever> pie__: installed, booting but not...
<clever> dhess: but that will run into trouble with any backend that does provisioning for you
<clever> dhess: wireguard on both the target machine, and also others in its LAN, and then i just mess with the deployip based on whatever is working at the time
<clever> dhess: i worked around the issue differently
<clever> dhess: nope, but gchristensen recently opened a PR to nixops to allow it
<clever> its 1 command, justdoit
<clever> pie__: installing nixos in qemu...
<clever> so i can "break" my grub, without actually breaking anything
<clever> to drop you back into rescue mode
<clever> neat, there is a normal_exit command
<clever> that says cat should work in rescue mode
<clever> ah, its normal you want to load, not core
<clever> luke, use the source
<clever> pie__: more? less?
<clever> pie__: i'll need to experiment on my end then...
<clever> pie__: what about /@/root/ ?
<clever> pie__: what about `ls (crypto0)/` ?
<clever> pie__: what about `ls (crypto0)/root` ?
<clever> and stage 1.5 isnt protected, so its just giving you some false security
<clever> i dont bother with luks on /boot because you have to enter the password twice
<clever> it has many slots of keys that can unlock the device
<clever> that definitely sounds like luks
<clever> pie__: so you can get rescue mode even if the luks partition was deleted
<clever> pie__: stage 1.5 isnt inside the luks volume
<clever> pie__: ls (crypto0) ?
<clever> pie__: sounds like the luks has been opened successfully
<clever> pie__: use ls to try and find core
<clever> pie__: you need to load the core module from the boot fs
<clever> pie__: but it has no tab completion
<clever> pie__: insmod should still work
<clever> pie__: let me poke around with justdoit
<clever> pie__: ive not tried /boot on zfs yet
<clever> grub-install is also responsible for embeding the correct drivers for the "boot" partition
<clever> pie__: and if it cant find that, it falls into rescue mode
<clever> pie__: when grub-install is ran, the path to the "boot" partition is baked into the stage 1.5 binary
<clever> pie__: you can just take a photo of the monitor
<clever> pie__: can you screenshot the error?
<clever> rprije: just `foo = import <channelname> {};` in a let block and then foo.hello somewhere
<clever> Athas: or just build it under nix-shell '<nixpkgs>' -A thing
<clever> Athas: ahh, then you want to either make it fail with `postInstall = "exit 1";` and build with --keep-failed
<clever> madhukar: i mostly stick to nix-build and nixos-rebuild
<clever> and nix will set $out to the right path before starting the build
<clever> Athas: the installPhase should copy everything to $out/bin and $out/lib for example
<clever> Athas: if you want to modify something in its output, just `nix-build '<nixpkgs>' -A thing` and see where the files are, and then use $out/thatpath in postInstall
<clever> madhukar: and now that you say that, i can see the differences
<clever> madhukar: i have it when blogs do that
<clever> Athas: usually, the working directory is left at the root of the source tree
<clever> it applies to every argument passed to builtins.derivation { ... }
<clever> but that magic also applies to buildInputs
<clever> its just string magic
<clever> yeah
<clever> madhukar: you could maybe try xkbOptions = "caps:ctrl_modifier";
<clever> madhukar: i dont know if a preset exists for that though
<clever> madhukar: if a preset is available for that, you can enable it like this
<clever> 457 xserver = {
<clever> 458 xkbOptions = "caps:shiftlock";
<clever> Henson: yep :D
<clever> thats if you want ignore the warnings
<clever> so your not seeing that firefox isnt supported on darwin
<clever> v0id72[m]: Allowunsupport is your problem, its causing un-supported software to try to build anyways
<clever> v0id72[m]: what is the content of config.nix?
<clever> v0id72[m]: the package was likely not tested on darwin, and doesnt support it
<clever> nix will ignore that
<clever> markasoftware: nix always puts bin in path
<clever> i dont think a lot of graphical programs from nixpkgs will work when on a mac, its mostly only command-line tools that work
<clever> the linux version wont work, because it expects a linux kernel
<clever> why do you want to build the linux version on a mac?
<clever> nix-env will accept that arg as-is
<clever> v0id72[m]: what command are you running to build chrome?
<clever> v0id72[m]: then add --argstr system x86_64-linux
<clever> v0id72[m]: and that .deb file is the linux build of chrome, not the mac build of it
<clever> v0id72[m]: i dont think alsa is supported on darwin
<clever> v0id72[m]: thats the real error
<clever> #error Header defining endianness not defined
<clever> v0id72[m]: just pastebin all of the output
<clever> v0id72[m]: the real error is above that
<clever> oborot: what error does it give?
<clever> oborot: i just search via tab completion in `nix repl '<nixpkgs>'`
<clever> oborot: are you searching for non-free packages?
<clever> rprije: if you set allowBroken = true; and see what breaks
<clever> Henson: yeah
<clever> Henson: i read the source for nix-env
<clever> when you do nix-env -iA nixos.hello, its using .nix-defexpr/channels_root/nixos/default.nix
<clever> the foo part can be renamed, its just the name you use when dealing with nix-env
<clever> Henson: the test part can be anything
<clever> and then nix-env can use it
<clever> you just create the above file, with 1 line of content
<clever> Henson: this just bypasses nix-channel entirely
<clever> Henson: you can now nix-env -iA foo.hello
<clever> [clever@amd-nixos:~]$ cat .nix-defexpr/test/foo/default.nix
<clever> import /home/clever/apps/nixpkgs
<clever> Henson: one min
<clever> gratin: and in the vbox app, you can set the guest resolution, and one is dynamic or automatic
<clever> oborot: `nix search`
<clever> gratin: and have you rebooted since enabling it?
<clever> pie__: root may have owned things in your home, and then mv failed to read them
<clever> pie__: did you do the mv as root?
<clever> and xmonad will just go along with it
<clever> and then the resolution of the monitor will dynamically change to match the host window
<clever> the guest additions typically include "gpu" drivers for xorg
<clever> pie__: that tends to be a pain, but there is `diff -ru`
<clever> pie__: its more more obvious when you use mv -vi
<clever> pie__: mv inter-device moves are basically just cp + rm

2019-06-08

<clever> Athas: yep
<clever> Henson: dhcpcd
<clever> it will then join systems together for you
<clever> either system (a string like "a,b,c") or systems (a list of [ "a" "b" "c" ])
<clever> eyJhb: you appear to have something invalid in nix.buildMachines
<clever> eyJhb: and what is like 390 of nix-daemon.nix doing?
<clever> eyJhb: https://gist.github.com/cleverca22/2c565b1d286e08c70aad78cb34b8bfc9 is the only form that works with imports
<clever> eyJhb: super.fetchurl would be better when it can work
<clever> eyJhb: the <nixpkgs> in displaylink.nix is loading 18.09, which may be too old for .extend
<clever> eyJhb: nix-instantiate '<nixpkgs>' -A lib.version --eval
<clever> eyJhb: if just ran with nix-build, it should work, what version of nixpkgs are you on?
<clever> > pkgs.extend
<clever> 2019-06-08 17:25:10 < pie__> if youre doing it in configuration.nix, theres an overlays argument somewhere that you can just pass the (self: super: ...) to
<clever> eyJhb: can you still pastebin your version of the file?
<clever> eyJhb: what is the contents of displaylink.nix?
<clever> yeah, 2 should have given an error
<clever> it would have shown that the luks device isnt open
<clever> for 1, it doesnt know if your luks device was misconfigured, or your drive is just slow to appear
<clever> pie__: boot.debug1devices
<clever> pie__: try boot.debug1devices this time
<clever> pie__: one minute
<clever> pie__: did luks ask for the passphrase before that?
<clever> pie__: add boot.shell_on_fail to the kernel cmdline in grub
<clever> pie__: can you get a shell there?
<clever> pie__: how far is it booting, and where is it hanging?
<clever> pie__: legacy requires mounting with the mount command, and on nixos, thats via fileSystems.
<clever> this will display the mountpoint (and a lot of other stuff) for every filesystem
<clever> zfs list -t filesystem -o name,used,referenced,logicalused,logicalreferenced,written,usedbysnapshots,usedbydataset,refcompressratio,compressratio,compression,mountpoint
<clever> ah
<clever> pie__: did you cleanly export it before shutting down the installer?
<clever> elvishjerricco: ^^
<clever> pie__: every FS in the fileSystems config, is automatically a supportedFilesystem
<clever> iqubic: callPackage is what calls that function
<clever> iqubic: that is defining a function, that takes 2 arguments
<clever> heck, i cant even complete > existing-file on some stuff!
<clever> pie__: ive found a lot of others stop you from completing what would have been normal things
<clever> pie__: haskell has a nice one, but you still have to tell the parser if something is a file, enum, or whatever
<clever> pie__: thats why i never use tab completion, its tends to be sloppy

2019-06-07

<clever> yes
<clever> and that wont make xmonad visible to other things
<clever> zeta_0: there wasnt an error in that last pastebin
<clever> zeta_0: yep, it works
<clever> zeta_0: ah, it was --recompile
<clever> zeta_0: only xmonad will be able to see it, during --reload, but it wont make it visible to other things
<clever> zeta_0: you may want to add xmonad to the ghcWithPackages near the top of the file
<clever> zeta_0: its not in scope for hie, only xmonad itself
<clever> zeta_0: looks like that is going to fix things for the `xmonad --reload` thing, but it wont make xmonad available to the editor
<clever> zeta_0: ghc based libraries cant be found when installed, you must be using a variant of ghcWithPackages that includes the library in question
<clever> zeta_0: ive only heard of it working via services.xserver.windowmanager.xmonad.enable, which deals with wrapping it so it can find XMonad
<clever> 5 seconds late
<clever> zeta_0: ive only heard of it working via services.xserver.windowmanager.xmonad.enable, which deals with wrapping it so it can find XMonad
<clever> there isnt much point in trying to stop them from having "root"
<clever> if somebody can nixos-rebuild or nixops deploy, they basically have root
<clever> not_a_robot: or put an ssh keypair on root
<clever> not_a_robot: sudo -i
<clever> not_a_robot: you might as well just allow everything with sudo, because that allows an attacker to just change sudo.extraRules
<clever> pie__: and once its built once,hydra will cache the result, and never build it again
<clever> pie__: that sha1 collision wont give you what you want, it can only give a binary output
<clever> o1lo01ol1o: if you give this some json descripbing the submodules, it can fetch the private repo
<clever> and you can do copy-on-write clones of a file, that you cant actually decrypt, i'm guessing
<clever> i'm guessing different sub-sections of a file can be encrypted with different keys?
<clever> pie__: ext4, files are a list of extents
<clever> so both mpv and lua are rooted
<clever> and mpv depends on lua
<clever> if you install mpv with nix-env, then /nix/var/nix/profiles/per-user/clever/profile-42-link is a gc root, that depends on mpv
<clever> anything mpv depends on, is also rooted
<clever> its less that mpv is a root, and more that root is just the starting point for the tree
<clever> while the world file is just a package name and maybe a verison
<clever> also, nix gc roots refer to a specific build
<clever> gyroninja: the dependencies of a package cant be deleted until the package refering to it is deleted
<clever> gyroninja: generations are basically nix keeping every version of the world file, so you can undo changes
<clever> gyroninja: it likely read the symlink, and showed the roots for its target instead
<clever> gyroninja: `nix why-depends otherthing /nix/store/something` to see how a given root points to it
<clever> gyroninja: `nix-store --query --roots /nix/store/something` to see what roots are pointing to it
<clever> usually only passing thru on connecting flights
<clever> worst case
<clever> so if its doing 10 jobs in parallel, thats 10x as much ram
<clever> it will need up to max_output_size ram, for every job its running
<clever> it may be using the old cfg
<clever> try restarting the hydra-queue-runner process?
<clever> you should be able to change it easily
<clever> thats just the default limit
<clever> 2gig
<clever> yeah
<clever> o1lo01ol1o: oh, did you turn on substituters?
<clever> not sure what else to check
<clever> o1lo01ol1o: can you confirm the new config is in /var/lib/hydra/hydra.conf on the hydra machine?
<clever> o1lo01ol1o: try going admin->clear failed build cache
<clever> o1lo01ol1o: you can check by just running du on its path, on the build slave
<clever> o1lo01ol1o: how big is the output?
<clever> o1lo01ol1o: its huge :P, took a month or 2 to figure it all out
<clever> tobiasBora: that is a directory, not an executable
<clever> tobiasBora: also
<clever> > "${pkgs.bash} -c \"while true; do echo 'YES';"
<clever> tobiasBora: you didnt terminate the escaped "
<clever> chuck*
<clever> tobiasBora: that will chunk it into a bash script for you, then put that in ExecStart
<clever> tobiasBora: https://nixos.org/nixos/options.html#.script
<clever> tobiasBora: you want .script in nixos
<clever> tobiasBora: ah right, ExecStart needs an absolute path
<clever> o1lo01ol1o: let x = builtins.fetchGit {foo}; y = builtins.fetchGit {bar}; in runCommand "name" {} ''cp -r ${x} $out --no-preserve=mode ; cp -r ${y} $out/y''
<clever> o1lo01ol1o: runCommand then has to copy that into a subdir
<clever> o1lo01ol1o: builtins.fetchgit will always clone into a random directory in /nix/store/