2018-05-03

<clever> debug1mounts will fail after it has mounted everything
<clever> debug1 just fails in the middle of parameter parsing
<clever> ghostyy: ctrl+f for the vars it sets, to see what they affect
<clever> you can also use e at grub to dynamically change it
<clever> i wouldnt put debug1 into there, it will "fail" every time it boots
<clever> boot.kernelParams = [ "boot.shell_on_fail" ];
<clever> ghostyy: its a kernel param, not a nixos option
<clever> ghostyy: there is also things like boot.debug1, which force it to "fail"
<clever> ghostyy: you can also add boot.shell_on_fail to get a shell when the initrd fails
<clever> ghostyy: i believe they do
<clever> yep
<clever> ghostyy: nixos will just insert that string into the stage-1 shell script
<clever> ghostyy: and the other similar options under boot.initrd
<clever> ghostyy: https://nixos.org/nixos/options.html#boot.initrd.postdevi
<clever> boothead: yeah
<clever> then it will be in the grub config by default
<clever> you can also add boot.shell_on_fail to boot.kernelParams
<clever> it seems stable during stage-1
<clever> boothead: i do find it strange that the problem only manifests after you proceed to stage-2
<clever> boothead: and you should be able to check lsmod after you get an initrd shell to confirm
<clever> boothead: you wouldnt even be able to mount /nix if dm_mod was missing
<clever> boothead: nixos already has those by default
<clever> Myrl-saki: the remote nix.conf controls the core count
<clever> Myrl-saki: it doesnt control the core count, only the total number of nix jobs you try to send to the machine
<clever> boothead: the cmdline in grub should show the version, as would uname -a in the initrd
<clever> google the error and see what others have done
<clever> boothead: yeah
<clever> boothead: id try an older generation of a channel, but its all gone now
<clever> boothead: due to the deterministic nature of nix, it is likely to recreate the same problem if installed from the same nixpkgs
<clever> boothead: try exit and see if it can continue to boot
<clever> or its ext4?
<clever> boothead: ahh, so your iso formatted /nix with new features, and the kernel you installed cant mount it
<clever> then we can review your configuration.nix
<clever> and then exit out of that shell to resume the boot
<clever> then you should be able to just mount each LV to the right sub-dir of /mnt-root/
<clever> boothead: and is the status available?
<clever> boothead: does it say the access is read/write?
<clever> boothead: you may need to use "lvm pvdisplay"
<clever> boothead: lvm should be available
<clever> boothead: thats basically partitioning your partitions
<clever> boothead: generally, the dm-0 device shouldnt be partitioned
<clever> boothead: what does tabtab show as being available?
<clever> boothead: you can now open a shell, and check what lvdisplay, pvdisplay, and vgdisplay say
<clever> boothead: then you can get a shell when it fails to mount the root
<clever> boothead: boot.shell_on_fail
<clever> boothead: do you know how to edit the cmdline in grub with e?
<clever> Myrl-saki: the user importing the build from the builder has to be trusted
<clever> sphalerite: use relative paths in the config?
<clever> if you dont specify a user when you ssh into a machine, it defaults to the same user you are locally
<clever> remote builds are not initiated from the nixbld group
<clever> Myrl-saki: ssh keys?
<clever> it shoved 4 NAR's worth of data into the socket before getting a reply back
<clever> and ive seen it claim to be copying 4 things, then fail because the 1st was unsigned
<clever> ive seen only a single `nix-store --write` on the remote end
<clever> i think it does 1 thing at a time over 1 ssh, but it doesnt wait for confirmation that things are working
<clever> Myrl-saki: oh, and i have also noticed similar lag spikes, my laptop is a build slave and is on 802.11g, and synery lags noticably when its transfering things
<clever> not sure
<clever> scp does things one file at a time, and waits for the remote end to sync
<clever> ive seen users in here before trying to diagnose why X dies whenever they try to build something
<clever> nix will kill the chosen user, so any nix build command is asking nix-daemon to kill your entire session :P
<clever> do not add yourself to the group, its literally suicide
<clever> oh yeah, you also need a nixbld group with write to the store, and build users in the group
<clever> Myrl-saki: yeah
<clever> Myrl-saki: i think nix tries to auto-create it with the users name, the one in the user may also have to be updated to not be default anymore
<clever> Myrl-saki: this symlink may also have to be manually created
<clever> lrwxrwxrwx 1 root root 29 Oct 11 2015 /root/.nix-profile -> /nix/var/nix/profiles/default
<clever> not sure
<clever> Myrl-saki: the default and user profile should be in $PATH, something in $NIX_PATH, the user should own his own profile dir
<clever> Myrl-saki: then i run nix-daemon as root, and fix the errors as i see them
<clever> Myrl-saki: i tend to mutate single into multi, i start by chowning /nix/store to root:root, and i tend to drop nix.sh entirely and set things up myself
<clever> ah, i see
<clever> Myrl-saki: there is an option in nix to have the remote end use a binary cache when possible
<clever> nikivi: use "sudo -i" then "nix-channel --list"
<clever> nikivi: sudo sets the wrong $HOME
<clever> nikivi: are you on darwin?
<clever> nick_l: can you pastebin the full output when its failing (and ran with -v) and also the info output?
<clever> then nix-build only has to be ran once to update the script
<clever> jD91mZM2: it would be better to have nix wrap or modify that script in an automated way, to insert the paths it needs
<clever> nick_l: every line of code that nixops can potentially reference
<clever> nick_l: this will search the entire closure of nixops for "foo" or "undefined variable"
<clever> [clever@system76:~]$ egrep -r --color 'foo|undefined variable' $(nix-store -qR $(type -P nixops))
<clever> nick_l: one min
<clever> nick_l: what command produced that error?
<clever> jackdk: check the git history on it, and read the most recent commit msg
<clever> yeah, you need to tell home-manager to also not build nixos man pages
<clever> eqyiel: it sys the nixos-manpages and home-manager depend on it
<clever> eqyiel: can you pastebin the full output when the build fails?
<clever> Xal: it likely wants a special symbol in the libc, to define it as being recent enough

2018-05-02

<clever> gchristensen: ah
<clever> gchristensen: also dont see any use of nix here, and it looks like its transfering in chunks?
<clever> --dump and --restore are basicaly tar -c and tar -x
<clever> obadz: nix-store --export and --import could be used for closure management
<clever> obadz: nix wont track the input or output, or closures
<clever> obadz: not even copy-closure, its more like rsync or scp
<clever> gchristensen: neat
<clever> obadz: that gives me an idea, nix-store --dump foo | pixz | netcat, and on the farend, netcat -l | unxz | nix-store --restore foo
<clever> gchristensen: upload the nix expression and build on the far end?
<clever> supernanovoid: you may need to configure cmake to check for SDL2_mixer in pkgconfig
<clever> supernanovoid: try just adding pkgconfig to the buildInputs and do nothing else, does it build?
<clever> supernanovoid: there is an SDL2_mixer.pc, so pkgconfig should work
<clever> ingore all other platforms, nix is the only way to go :P
<clever> Dezgeg: the reason i dont like that, is that every pre-nix package has its own unique way of finding the right cflags
<clever> then the headers are in $out/include/SDL_mixer.h and <SDL_mixer.h> just works
<clever> supernanovoid: the way i would prefer to fix it, is to modify the postinstall of SDL itself, to just get rid of that useless prefix
<clever> i would prefer to just ditch the SDL2 prefix in the postInstall, so it works out of the box
<clever> they currently rely on either pkgconfig or `-I${SDL}/include/SDL2`
<clever> and now they are making nix harder to use, lol
<clever> because nix wasnt a thing and they had to work around the conflicts
<clever> Dezgeg: the issue is that a lot of packages expect -I/usr/include/SDL2 and try to include their own files without the SDL2 prefix
<clever> supernanovoid: id try pkgconfig first
<clever> bbl
<clever> ive also heard rumors that bad ram can cause a scrub to just shred the entire disk
<clever> id say its more aggressive then fsck, because it checks the data as well
<clever> that reads every single block on the filesystem, and compares it against the checksums
<clever> i left all the others on defaults
<clever> iqubic: and also set that to .enable to true in configuration.nix
<clever> iqubic: did you read the scription of .enable on https://nixos.org/nixos/options.html#services.zfs.autosnapshot
<clever> iqubic: yep
<clever> wolftune: the nixbld users have no default path at all
<clever> and then you have to shred all the backups to get your space back
<clever> the snapshots save every single byte your deleting when low on space, so you gain nothing
<clever> i turn it off, because it basically makes garbage collection useless
<clever> and its easily overriden
<clever> check the 2nd file in the last gist and you can see how the inheritance works
<clever> /nix will need to be on its own dataset
<clever> you can also do that
<clever> yeah
<clever> if you set the flag on the root node of the pool (naspool in one of my machines), it inherits to all child nodes
<clever> i also keep snapshots of / so the configuration.nix is preserved
<clever> the description of .enable says how to set/unset it
<clever> iqubic: you need to enable this service, and set the right flag on each dataset you care about: https://nixos.org/nixos/options.html#services.zfs.autosnapshot
<clever> if you ever delete something, or need to undo something that isnt in your editor's undo buffer
<clever> i find snapshots are good to have, so you can undo any oops moment you have
<clever> and snapshots off for /nix when possible
<clever> with dedup in select areas
<clever> a mix of lz4 and gzip-9
<clever> 2018-05-02 15:55:06 < clever> iqubic: https://gist.github.com/cleverca22/2f208e127ac74fd83decbb27453d286d
<clever> iqubic: oh, i linked it 8 minutes ago
<clever> so i'm wondering if there is some special step the old admin forgot to mention
<clever> it sounds like this machine has never built that container before
<clever> wolftune: are there any .nix files in that directory?
<clever> wolftune: it would likely fail, try just running the launcher script without docker first and see what fails
<clever> wolftune: what is the contents of launcher?
<clever> yeah, docker requires config changes and a rebuild
<clever> wolftune: git wont be available until you install git
<clever> wolftune: how did you install git and docker?
<clever> iqubic: let me gist my setup...
<clever> iqubic: is it listed in `mount` ?
<clever> UNIcodeX_: it would still waste cpu cycles on write, then find it made it worse and save uncompressed
<clever> i find zfs better then btrfs
<clever> after fixing /boot and the config that refered to it
<clever> boot nixos form usb, mount the rootfs, run nixos-enter, nixos-rebuild boot
<clever> maurer: i dont even bother with backups for /boot, it can be recreated in minutes with the right recovery media
<clever> grub already has trouble traversing /nix/store/
<clever> UNIcodeX_: i wouldnt trust any bootloader with zfs, since its so bleeding edge
<clever> UNIcodeX_: i also dont trust grub with zfs, so id still use a diff boot
<clever> `Native encryption is not production ready, keep backups.`
<clever> i think the topic in the channel also says so
<clever> a 32bit-only and a 64bit-only wine?

2018-05-01

<clever> gleber_: build-time would likely use exec, runtime would use nixops key management
<clever> gleber_: runtime or buildtime secrets?
<clever> and its safe in a multi-user context, since it runs as your own user, the nix it spits out is evaluated, and then its pure and the daemon doesnt care or know
<clever> it always runs as the user doing the nix eval, never the daemon
<clever> gleber_: updated the gist, you can see it ran as my user
<clever> not sure what the game itself does with it at runtime
<clever> drakonis: the current factorio derivation involves putting your name&pw into your packageOverrides, and leaking it into /nix/store/
<clever> otherwise, the env vars in the nix-daemon could lead to priv escalation
<clever> and it has to be a new hashmap and not just setting environ and reusing getEnv
<clever> in theory, nix-build could forward its env vars to the daemon, and make it more transparent
<clever> and then return the storepaths
<clever> your downloader will need to fetch things to /tmp, and run nix-store --add-fixed on the files, to import them into the store
<clever> an issue is open about that
<clever> nix-build --allow-unsafe-native-code-during-evaluation sill be required
<clever> like your current env vars and your $HOME dir
<clever> but it is free to read things outside the sandbox
<clever> downloader will be stored in the store
<clever> and downloader must then print out a chunk of nix, which exec will import
<clever> and then it will build and run downloader, outside the sandbox
<clever> gleber_: so you can do mod_paths = builtins.exec [ downloader arg1 arg2 arg3 ]; i believe
<clever> gleber_: when enabled, builtins.exec can execute a program, and then nix will parse the stdout of said program as nix, and import the result
<clever> gleber_: i think your only remaining option is builtins.exec
<clever> gleber_: but fully declarative would be nicer
<clever> gleber_: i think you can upload a single-player map to the server, and it will inherit all the mods
<clever> git?, http basic auth?
<clever> gleber_: what are these auth details going to be used for?
<clever> so you need the daemon to do the work on your behalf
<clever> gleber_: you lack permission to do builds
<clever> gleber_: if you lack write access to the store, nix1 will fail, and nix2 will auto-detect and switch to the daemon
<clever> ah, i wasnt sure about point 2, that can be an issue
<clever> gleber_: it will silently ignore the vars if its not a fixed-output derivation
<clever> gleber_: but if you instead only do impureEnvVars = ["FOO"]; on a fixed-output derivation, and set FOO at build time, it should get in
<clever> gleber_: builtins.getEnv also saves the auth details into /nix/store as world-readable files
<clever> gleber_: the value it gets is put into the .drv file, and when the value changes, it triggers a rebuild
<clever> gleber_: builtins.getEnv is still "pure"
<clever> dmj`: pkgs.gcc contains g++
<clever> dmj`: did you try gcc?
<clever> stdenv.cc.cc
<clever> nschoe: ah, then nixpkgs may not have enabled opus
<clever> nschoe: but it can find opusparse ?
<clever> nschoe: its part of the nix-index package
<clever> nschoe: [clever@amd-nixos:~]$ nix-locate opus | grep gstream
<clever> nschoe: it appears to be in plugins-bad
<clever> gst_all_1.gst-plugins-bad.out 23,088 x /nix/store/43szlakcix305r4rwr45v0sxpfb939a9-gst-plugins-bad-1.10.4/lib/gstreamer-1.0/libgstopusparse.so
<clever> yep
<clever> lejonet: what about this?, after you fix the references
<clever> lejonet: systemd.services.libvirtd.environment.LIBVIRTD_ARGS = lib.mkForce ''--config "${configFile}" ${concatStringsSep " " cfg.extraOptions}'';
<clever> lejonet: what happens if you set unix_sock_group twice in the same config file? via extraConfig
<clever> where exactly is it hard-coded?
<clever> lejonet: and then you have to pass that path to whatever you want reading it
<clever> lejonet: each call to writeText returns a unique storepath, based on the contents
<clever> lejonet: nope
<clever> yeah
<clever> nix-shell -E 'with (import <nixpkgs> { overlays = [ (import /home/myrl/nixos-configs/overlays/qemu-user.nix)]; system="armv7l-linux"; }); stdenv.mkDerivation { name = "dummy"; }'
<clever> Myrl-saki: you need to create a new derivation with mkDerivation or runCommand, which depends on gcc (mkDerivation already does by default), and add things to its buildInputs
<clever> Myrl-saki: thats just a dumb list of derivations and will fail the same way
<clever> Myrl-saki: also, -A gives you a shell suitable for building gcc, not running gcc
<clever> Myrl-saki: it has no clue how to merge 2 of them
<clever> Myrl-saki: it creates a shell that has all of the env vars of the named derivation
<clever> [Leary]: what about its log output?
<clever> Dezgeg: if there is only one dvb-core.ko at the time depmod is ran, it wont see the kernel version
<clever> Dezgeg: i'm guessing meta.priority so the nix buildEnv of modules overwrites correctly before the depmod runs?
<clever> [Leary]: what does `systemctl status wpa_supplicant` say?
<clever> [Leary]: nix repl '<nixpkgs/nixos>' and then config._modules.args.pkgs
<clever> Ralith: you could have a dedicated user for the daemon and store write, but then build users wont work
<clever> jnoah: in that setup, nix-daemon runs as root, and only root has write to /nix
<clever> jnoah: its best to use nix-daemon when sharing it
<clever> jnoah: if you can get the admin to create an empty /nix and give you ownership, you can then install it without needing sudo or root
<clever> Ralith: yeah
<clever> Ralith: the runtime graph is only known once the build has completed
<clever> Ralith: runtime or buildtime graph?
<clever> Ralith: it should accept a config argument at the top level
<clever> Ralith: yeah, it wouldnt work in that example, but usually this is within nixpkgs itself
<clever> Ralith: you would do a packageOverride on the nixpkgs above, before it does callPackage on this new set
<clever> Ralith: it only contains what the packages function returned, plus some util functions
<clever> Ralith: correct
<clever> ./. + "/foo/${bar}.txt"

2018-04-30

<clever> Ralith: mostly for debug, so i could reuse the pkgs elsewhere
<clever> Ralith: you could do that, shouldnt make any difference
<clever> Ralith: i believe .overrideScope lets you apply overrides to the self passed in on line 16
<clever> Ralith: not sure, but i use it any time i'm creating a set of packages
<clever> but it was still easy to fix, once i found a copy of nix that still survived
<clever> i broke nixos pretty badly with `nix-store --delete --force` when i was new to things
<clever> which lets you apply overrides before the set of packages can reference itself
<clever> and makeScope modifies it to add .overrideScope
<clever> Ralith: i think newScope is what generates a set with a callPackage function
<clever> Ralith: dont know, i just found them in-use in a random area of nixpkgs
<clever> boomshroom: what error does it fail with?
<clever> ixxie: yeah, oops
<clever> jtojnar: yeah
<clever> ixxie: use pkgs.lib.makeScope pkgs.newScope, then .overrideScope will work
<clever> jtojnar: rewrite gnome3 to use pkgs.lib.makeScope pkgs.newScope, then .overrideScope will work
<clever> jtojnar: so you need to also gnome-shell = gnome3.gnome-shell.override { gdb = gdm; };
<clever> jtojnar: the other things in gnome3 are refering to the old values
<clever> ixxie: yeah
<clever> ixxie: for aws, there is ~/.ec2-keys
<clever> me and someone else had issues a month ago, where it would re-chmod it every time you nixos-rebuild
<clever> destroy all perl!
<clever> samueldr: nix will also enforce $HOME being 700 i believe
<clever> nix is able to obey relative paths as relative to the file that contains them
<clever> i would put it in the same directory as the nix file, and do "${./background.png}";
<clever> and it will fail a lot faster if the file doesnt exist
<clever> and make it world-readable
<clever> nix will copy that path into the store
<clever> ah, try "${/path/to/image}"; then
<clever> what error?
<clever> try unquoting the path
<clever> sydney: what if you unquote the path?
<clever> sydney: is that path readable by the lightdm user?
<clever> if its multi-user mode, then that sounds entirely normal
<clever> rizary: the path to outb has to appear in outa
<clever> rizary: basically, grep -r $outa $outb
<clever> rizary: so if the path to B does not appear in A's $out, then it wont depend on B at runtime
<clever> rizary: the runtime deps of A will depend on what paths its $out refers to
<clever> it will still get the runtime dependencies, but there is no way to stop that
<clever> lol
<clever> all edited by hand...
<clever> then i noticed the PR was up to 100 modified files
<clever> i was recently refactoring some haskell code
<clever> also +1's that
<clever> +1
<clever> i also found this bug today: https://github.com/NixOS/nix/issues/2125
<clever> ah
<clever> gchristensen: guess it was fixed
<clever> it didnt look like that a week ago....
<clever> The format is described in systemd.time(7).
<clever> 40 <manvolnum>7</manvolnum></citerefentry>.
<clever> 39 <citerefentry><refentrytitle>systemd.time</refentrytitle>