2018-05-28

<clever> parsnip: then you need nix-env -iA nixpkgs.emacs
<clever> sauyon: it has to be a channel name from `nix-channel --list` (your user, or root), and then a package attribute path
<clever> sonne: turn off the boot splash?
<clever> you may need init=/nix/var/nix/profiles/system/init
<clever> and now that i look closer, i can see that this default isnt right
<clever> sonne: if you use the i shell, you can just exit to resume it
<clever> sonne: and its not at /init
<clever> sonne: you have to run switch_root on the rootdir and the path to init
<clever> sonne: and was the rootfs mounted in targetRoot, what was stage2Init set to?
<clever> sonne: read the stage-1-init.sh i linked above, and poke arround to see what its doing and how it fails
<clever> sonne: f or i work, f just gives you the option to manually exec the real init
<clever> sonne: boot.debug1devices will load the modules, then "fail"
<clever> sonne: one sec
<clever> debug1 happens before it loads modules
<clever> oh right
<clever> you can lsmod again inside the initrd once its working to confirm which ones its using
<clever> check lsmod to see all those in use, anything with usb, hci, or hid in the names are likely of use
<clever> that will include modules in the initrd, and it will auto-load them as needed
<clever> sonne: boot.initrd.availableKernelModules = [ ... ];
<clever> you need to build your initrd with usb and hid support sometimes
<clever> and you can exit to resume normal booting after you poke around
<clever> i should give you an interactive shell
<clever> sonne: boot.debug1 will cause a fake failure at this point in the script, and drop you into an initrd shell
<clever> i think so
<clever> sonne: if you add boot.debug1 to the kernel params, what does it do?
<clever> sedutil is a linux program for unlocking the hdd encryption
<clever> ah, it was ottidmes
<clever> 2018-03-02 10:01:20< ottidmes> clever: For sedutil to do its thing I cannot have access to the SSD, so far I have been rebooting into a LiveCD everytime I wanted to configure the SSD with sedutil (other than unlocking), but I was thinking, shouldn't I be able to use your rescue netboot example so that I can boot into that, do the configuration, and kexec back into the kernel on the SSD after I am done?
<clever> just an entirely empty kernel params
<clever> sonne: try without any systemConfig
<clever> yeah
<clever> sonne: the last guy with this issue, had a shadow boot partition, that would appear whenever the drive is locked, and it would boot a second OS from there, which asks for the pw
<clever> tfc[m]: yeah
<clever> sonne: there was a guy in here a month or 2 ago with a very similar problem, and he used kexec to solve it
<clever> sonne: ah, let me find the right link...
<clever> tfc[m]: channels are only a way to get the nix expressions, they have no real link to the binary caches
<clever> sonne: and if they hit c after the bios has unlocked it, then they have the password?
<clever> sonne: if they hit c prior to the bios unlocking things, then they have no more access then if they just ripped the drive out of the machine
<clever> tfc[m]: and also add the key that the hydra signs with
<clever> sonne: the same as sourcing a config file after you decrypt the real boot partition
<clever_> sonne: it would be no less secure then running i_am_not_a_virus.bin that was renamed to /boot/default/kernel
<clever_> tfc[m]: yeah
<clever_> tfc[m]: if you run `nix-store -r /nix/store/foo` on a storepath, without having given it expressions on how to build it, then its only option is to download from the binary cache
<clever_> sonne: it should still boot without kernel params, it just means you cant configure them from configuration.nix
<clever_> yeah, that method entirely ignore kernel params
<clever_> that will create a dumb /boot/default/kernel and /boot/default/initrd
<clever_> sonne: https://nixos.org/nixos/options.html#boot.loader.generations
<clever_> which reminds me
<clever_> so you have to convince grub that a /nix/store/ symlink in the nix filesystem should be read at /store
<clever_> and that relies on being able to follow symlinks when your /nix may not mount directly at /
<clever_> its in a file in there, and i dont know if grub can read a file and use it as kernel args
<clever_> but the kernel cmdline is harder to get
<clever_> you can also load the kernel and initrd from /nix/var/nix/profiles/system/
<clever_> sonne: the only issue there, is that the grub config cant load modules, so you have to pre-load all grub modules it may need prior to sourcing
<clever_> sonne: grub has a source command, so you can just source the grub config nixos generates

2018-05-27

<clever> bbl
<clever> Orbstheorem: running ulimit before you start xmonad will handle what this is descripting
<clever> Orbstheorem: that tells the kernel that it can make coredumps, which might be needed, not sure
<clever> Orbstheorem: you may also need a `ulimit -c unlimited` before you start xmonad
<clever> Orbstheorem: that will tell systemd to save coredumps every time a fault happens anywhere in the system
<clever> Orbstheorem: systemd.coredump = { enable = true; };
<clever> Orbstheorem: then you need one other small change
<clever> Orbstheorem: then the main xmonad will always use that debug build
<clever> Orbstheorem: in your override-xmonad\ \(1\).nix file, just strip out all of the overrides, and run `LD_LIBRARY_PATH=${pkgs.enableDebugging pkgs.xorg.libX11}/lib ${xmonad/bin/xmonad &`
<clever> Orbstheorem: one min
<clever> Orbstheorem: take the lib dir from this, shove it into LD_LIBRARY_PATH, then run gdb+xmonad under that
<clever> nix-build -E 'with import <nixpkgs> {}; enableDebugging xorg.libX11'
<clever> or use LD_LIBRARY_PATH
<clever> you must edit nixpkgs
<clever> there is basically no way to override libX11
<clever> its not even using callPackage
<clever> oh crap
<clever> so libXrandr always refers to the original libX11
<clever> Orbstheorem: pkgs.xorg is fairly old, and lacks a proper way to override
<clever> let me improve the override
<clever> Orbstheorem: ah, libXrandr and other things
<clever> Orbstheorem: i built it locally with the overrides, and i see 2 libX11's in the dep tree, with and wihtout debug
<clever> so its changed via .override
<clever> that inherit is in the default args via callPackage
<clever> testing something on this end...
<clever> Orbstheorem: the overrideAttrs in there has no effect
<clever> Orbstheorem: what was your call to xmonad-with-plugins?
<clever> /nix/store/rka40nki4bxwiyy090q6xbp8xfraiajs-libX11-1.6.5/lib/libX11.so.6.3.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped
<clever> testing in a repl...
<clever> yeah, it should have worked the way i typed it
<clever> 386 enableDebugging = pkg: pkg.override { stdenv = stdenvAdapters.keepDebugInfo pkg.stdenv; };
<clever> let me double-check the source
<clever> sounds like the override didnt work right
<clever> no debug output?
<clever> then run `nix show-derivation BAR` on that, does it show several outputs?
<clever> Orbstheorem: if you do `nix-store --query --deriver FOO` on the storepath for the overridden libX11, you should get a .drv path
<clever> Orbstheorem: run `file` on the before and after libX11.so and confirm if the enableDebug override did anything
<clever> ryantrinkle: the contents of readme.md dont affect if things pass or fail
<clever> ryantrinkle: the ./. is just a question of if changing readme.md causes a rebuild, and id usualy try to avoid that
<clever> ryantrinkle: it would also be nice if hydra could do both head and merge builds, to confirm both pass
<clever> ryantrinkle: the metadata on an eval has to be improved to track both head and merge, and then the github status plugin has to use that metadata, then it might be as smart as travis
<clever> so the PR will always get a first eval when opened
<clever> also, the reval caching is within a jobset
<clever> ryantrinkle: depends on if you have a src = ./. that reads that file
<clever> ryantrinkle: youll need to make a new commit on the PR that actually causes a nix level rebuild
<clever> not the last
<clever> and it updates the rev that first made the eval
<clever> a force re-eval doesnt help if its the same derivations in the end
<clever> ryantrinkle: the new git rev is giving effectively the same nix expressions, so it doesnt need a new eval
<clever> ryantrinkle: thats a cached eval
<clever> if you need realpath or not, depends on what you want to do
<clever> which is a symlink to the real binary
<clever> iqubic: type/which give a path like /run/current-system/sw/bin/foo
<clever> iqubic: run type or which on it, then realpath on that path
<clever> Orbstheorem: also, now that we have switched to using a proper haskell override, you can just override X11, and it will affect xmonad automatically
<clever> yep
<clever> Orbstheorem: so you have to override the whole packageset it came from
<clever> Orbstheorem: i think think ghcWithPackages accepts .override at all
<clever> ryantrinkle: hydra would have to be improved to know about head vs merge internally, and test merge but post to head
<clever> ryantrinkle: yeah, but hydra doesnt know to post the status back to the head commit, and github cant show the status of the merge commit
<clever> ryantrinkle: and that special fake-merge commit doesnt show up in the PR page
<clever> ryantrinkle: the status is reported on a specific revision
<clever> ryantrinkle: yeah
<clever> Orbstheorem: that uses the haskell overrides to replace xmonad and X11, then gets a .ghcWithPackages from the modified set
<clever> Orbstheorem: you want (haskellPackages.override { overrides = self: super: { xmonad = super.xmonad.override { X11 = super.X11.override {libX11 = enableDebugging xorg.libX11;}; }; }; }).ghcWithPackages i think
<clever> ah, i see the issue
<clever> Orbstheorem: i think your problem is at ghcWithPackages = haskellPackages.ghcWithPackages.override
<clever> or possibly $HYDRA_HOME
<clever> ryantrinkle: i think its $PERL5LIB in the hydra-notify bash wrapper
<clever> libexec/hydra/lib/Hydra/Plugin/GithubStatus.pm is where the PR status is handled
<clever> then start adding prints to it
<clever> ryantrinkle: then modify hydra-notify to use the copy of -wrapped, and the copy of lib
<clever> ryantrinkle: copy .hydra-notify-wrapped to a tmpdir and also copy the path like `/nix/store/8dxcx2jv168c3f6a31fag1a3qwkps170-hydra-2017-11-21/libexec/hydra/lib` to a tmpdir (read the hydra-notify script), and copy hydra-notify as well
<clever> ryantrinkle: its always loaded
<clever> then check all of the logfiles it generates to to see what is being ran
<clever> try running `strace -ff -o logfiles -e execve -s 500 hydra-notify build-started 205`
<clever> yeah
<clever> ryantrinkle: the first one to match stops all others
<clever> ryantrinkle: do you have several githubstatus blocks?
<clever> what about the inputs field?
<clever> yeah, that should match
<clever> Build 205 of job obelisk:obelisk-pr-29:built-skeleton
<clever> ryantrinkle: ah, can you paste your regex and your job name?
<clever> ryantrinkle: that runs thru the same regex
<clever> ryantrinkle: grab an actual build# from the hydra UI
<clever> ryantrinkle: you can also manually run `hydra-notify build-finished 63657` or swap in build-started (as `sudo -u hydra -i`) to manually claim something has happened and update github
<clever> ryantrinkle: `journalctl -f -u hydra-queue-runner`
<clever> symphorien: lib.optional and its friends
<clever> > (lib.recursiveUpdate { a=1; b={c=3;d=4;}; e=5; } { b = { f=6;}; }).b
<clever> > lib.recursiveUpdate { a=1; b={c=3;d=4;}; e=5; } { f=6; }
<clever> ldlework: if you just want to recursively overwrite anything without merging, lib.recursiveUpdate
<clever> > { a=1; b={c=3;d=4;}; e=5; } // { b=2; }
<clever> ldlework: its non-recursive
<clever> Orbstheorem: just need to slot that into a config option like services.xmonad.package and i think your done
<clever> Orbstheorem: and this should force xmonad to use that version
<clever> haskellPackages.xmonad.override { X11 = haskellPackages.X11.override { libX11 = enableDebugging xorg.libX11; }; }
<clever> haskellPackages.X11.override { libX11 = enableDebugging xorg.libX11; } would create a custom X11 library using a debug build of libX11
<clever> Orbstheorem: ok, so the haskell xmonad package depends on the haskell X11 package, which depends on xorg.libX11
<clever> not really
<clever> Orbstheorem: you can arrange it to only affect xmonad
<clever> Lisanna: ah
<clever> Lisanna: what are you wanting to do?
<clever> Lisanna: yeah
<clever> Lisanna: i think your right, buildCommand inside runCommand is passed as a file
<clever> Lisanna: aha, it works when it is definitely an attribute
<clever> vals are /nix/store/20x9309p7vkq8gi5w5rqhxrvv3707s0x-hello /nix/store/20x9309p7vkq8gi5w5rqhxrvv3707s0x-hello
<clever> nix-repl> :b runCommand "hello" { foo = placeholder "out"; } "echo vals are $foo $out"
<clever> that gives me an idea
<clever> at least, it should be
<clever> Lisanna: but that string is in the .drv
<clever> yeah, thats not what i would expect it to be creating
<clever> /1rz4g4znpzjwh1xymhjpm42vipw92pr73vdgl6xs1hycac8kf2n9 /nix/store/zpiylv6am19byxaf6bhr2qffvfj2yqnl-hello
<clever> nix-repl> :b runCommand "hello" {} "echo ${placeholder "out"} $out"
<clever> Lisanna: first, try calling it something other then $out, and then echo both placeholder and $out
<clever> foldingcookie: also, unquote the path to the patch

2018-05-26

<clever> averell: nix-env -iA nixos.mpv
<clever> mpickering: either clean up all your dist directories, or use builtins.filterSource to exclude dist
<clever> mpickering: yeah, thats common
<clever> mpickering: it just builds it with nix, so it depends on your systems nix.conf config
<clever> benley: and also, $PATH and /bin will be empty so you need to manually `export PATH=/nix/var/nix/profiles/system/sw/bin/`
<clever> benley: change the kernel cmdline to `init=/bin/sh` in the bootloader, and when it claims it doesnt exist, tell it to continue
<clever> you must also set it in config.nix
<clever> ldlework: configuration.nix has no effect on nix-env and nix-build
<clever> ldlework: nix-env doesnt show the unfree errors due to a bug, but nix-build does
<clever> nix-build will never add it to PATH
<clever> but it wont be in $PATH by default
<clever> it puts it in /nix/store and creates a result symlink pointing to it
<clever> ldlework: and the 2nd problem is that `nix-env -iA nixos.discord` wont show the unfree warnings
<clever> ldlework: the first problem is that -i wont show unfree packages if you havent turned on unfree
<clever> ldlework: nix-build '<nixpkgs>' -A discord
<clever> i have made it work before by port-forwarding a port to 192.168.2.255 on the router, and then sending the magic packet from outside
<clever> sphalerite: so you can either target its mac (hard with it not answering to ARP) or target the mac level broadcast addr
<clever> sphalerite: oh, and something else about wake-on-lan, it will activate if the card sees the magic bytes, in any packet that reaches it
<clever> nix-repl and/or `nix repl` can also be used to test things more easily
<clever> tomberek: depends on what is in scope
<clever> it has since been replaced with a c++ binary that directly links to the nix libs and calls those internally
<clever> tomberek: previously, nix-build was a perl script that did nix-instantiate and nix-store -r
<clever> tomberek: yeah
<clever> 404, notes not found
<clever> sphalerite: let me check my old notes...
<clever> tomberek: with the above, it now expects you to have a configuration.nix file in the current dir
<clever> tilpner: nix build '(import <nixpkgs/nixos> { configuration = ./configuration.nix; }).config.system.build.units."nix-daemon.service".unit'
<clever> tilpner: i find the tab completion in `nix repl` to be worse then `nix-repl`
<clever> infinisil: yeah, i find them a bit clunky still
<clever> and result/nix-daemon.service now exists
<clever> this successfully creates a result symlink
<clever> [root@amd-nixos:~]# nix build '(import <nixpkgs/nixos> {}).config.system.build.units."nix-daemon.service".unit'
<clever> sphalerite: it doesnt work either way
<clever> error: don't know what to do with argument 'config.system.build.units."nix-daemon.service".unit'
<clever> [root@amd-nixos:~]# nix build -f '<nixpkgs/nixos>' 'config.system.build.units."nix-daemon.service".unit'
<clever> the ( forces it to be an expression
<clever> `nix build` uses some weird algos to decide if your refering to a file or a nix expression
<clever> error: undefined variable 'config' at (string):1:2
<clever> [root@amd-nixos:~]# nix build -f '<nixpkgs/nixos>' '(config.system.build.units."nix-daemon.service".unit)'
<clever> hodapp: you have to pick an attribute inside qt5
<clever> hodapp: qt5 is a set
<clever> Cypi, symphorien: that sounds like it might be https://github.com/NixOS/nixpkgs/issues/30775 again
<clever> yurb: yeah
<clever> yurb: what about editing the source, then building it with both nix-shell and nix-build (using an override), and comparing the output, add print statements near the point of failure and compare values
<clever> yurb: if you build it from the same copy of nixpkgs, then it will have the same versions of everything
<clever> ldlework: and it automatically becomes a dependency, so if your string winds up in a script, nix will copy those files before your script, at all times
<clever> ldlework: any time you do ${./foo} in a string in nix, nix will copy the path to /nix/store, and substitute in that store path
<clever> and confusing errors spew forth
<clever> due to the error, it aborted in the middle of the activation scripts, and now systemd isnt in $PATH
<clever> months later, after forgeting he made such a change, he had a power outage and had to reboot
<clever> i helped one guy that tried to do network in his activation script, and it worked during `nixos-rebuild switch`, and he had since done garbage collection
<clever> and activationScripts are more fragile, one error in your script and the machine wont even boot
<clever> ldlework: you need to use either systemd or an activation script to run the string at bootup
<clever> ldlework: you can do it in any string in nix, you just need to be aware of when that string is being executed
<clever> ldlework: so you want to tell cp the full path
<clever> ldlework: just beware that nix will rename the file to /nix/store/hash-znc.conf, and then cp will preserve that name, and create /var/lib/znc/configs/hash-znc.conf on you
<clever> ldlework: yes, thats exactly how you can do it
<clever> ldlework: thats how dependencies work in nix
<clever> ldlework: nix can copy it to the remote machine for you if you just "cp ${./source} destination"
<clever> ldlework: why do the contents have to be in the prestart script?
<clever> yurb: you can also `nix-shell '<nixpkgs>' -A supercollider --pure` to tell it to find the default.nix in NIX_PATH
<clever> ldlework: and if that is in a prestart script, it will copy to /destination on the remote machine, during prestart
<clever> ldlework: the ${./source} will cause nix to copy the entire source into the nix store, and then deploy it to the remote machine
<clever> ldlework: "cp -r ${./source} /destination"
<clever> -A gives you an env with the source, that is suitable for building it
<clever> -p gives you an env with the (broken) supercollider already in $PATH
<clever> yurb: you need to use -A supercollider
<clever> s/look/loop/
<clever> sphalerite: or make a proper look and set its script in powerManagement.powerDownCommands
<clever> sphalerite: i think it is ran in a context without `set -e`, so you could just list every interface that exists on every machine, maybe
<clever> sphalerite: or turn off predictable interface names and just hard-code eth0
<clever> sphalerite: it looks like it has to run ethtool on every interface at shutdown
<clever> but machotool does have a cabal file, so it can make use of the haskell support in nixpkgs
<clever> arcstats doesnt even have a cabal file, i generally avoid cabal when i can
<clever> arcstats bypasses all of the haskell support in nixpkgs, so you get a usable shell without .env
<clever> and then ghcid will :r the project every time you save any file, and show the errors
<clever> another handy thing, you can do `ghcid -c "runhaskell Setup.hs repl"`
<clever> and nix-build will just build the project
<clever> but stack2nix will involve more rebuilding the first time its ran
<clever> initiumdoeslinux: those commands can be used with both stack2nix, and the simpler machotool examples
<clever> initiumdoeslinux: on lines 3 and 6, i then run the configure and repl commands, which gets me into ghci
<clever> initiumdoeslinux: on line 1 i ask for an env suitable for building machotool, which will build everything it depends on using nix, then drop me into a shell
<clever> initiumdoeslinux: let me paste an example of how to repl and build with the machotool example above
<clever> initiumdoeslinux: stack will always try to rebuild everything on its own
<clever> initiumdoeslinux: stack will never use anything made by either stack2nix or the 2 examples above
<clever> initiumdoeslinux: https://github.com/cleverca22/machotool/blob/master/default.nix is another simple example, this one overrides macho and creates machotool, so i can now `nix-build -A machotool` and freely modify the source of the macho library (it had many bugs)
<clever> initiumdoeslinux: https://github.com/cleverca22/arcstats/blob/master/default.nix is a very simple example, it builds arcstats with the stock lens+data-default, and a slightly modified datadog package
<clever> initiumdoeslinux: if you want help from the cache, you need to apply minimal overrides to haskellPackages
<clever> initiumdoeslinux: stack2nix overrides the versions of everything, so it wont get any help from cache.nixos.org
<clever> initiumdoeslinux: if you check `ls -ltrhd /tmp/nix-build*` what is it building?
<clever> initiumdoeslinux: which process is consuming cpu?
<clever> initiumdoeslinux: i think it was just a side-effect of some recent refactoring, and it wasnt that big of an issue at the time
<clever> initiumdoeslinux: that was a recent change, prior, to that it only defined attributes for your entire dependency tree
<clever> initiumdoeslinux: so you need to do `nix-build -A yourproject`
<clever> initiumdoeslinux: and stack2nix generates one for every single package in stackage
<clever> initiumdoeslinux: if you dont give a specific attribute, it will try to build every single one
<clever> initiumdoeslinux: did you tell nix-build which package to build?
<clever> colemickens: its in the nixos-rebuild man page, --install-bootloader
<clever> colemickens: one sec
<clever> ldlework: use -n on netstat
<clever> see if it has any log files open
<clever> lsof -p <PID>
<clever> ldlework: anything in the znc logs or journal?
<clever> ldlework: nixops scp --to
<clever> ldlework: not sure then
<clever> ldlework: how much ram available?, free -m
<clever> ldlework: what does dmesg say?
<clever> ldlework: how much ram on this machine?, any swap?
<clever> can you pastebin it?
<clever> dmesg, df, df -i
<clever> then run, and bt
<clever> gdb --args znc --makepem --datadir $PWD
<clever> gdb time
<clever> heh
<clever> ldlework: sounds like a znc bug then
<clever> reachingfourpeas: it sounds like the author of clash-playground didnt test things properly on nix2
<clever> reachingfourpeas: you need to modify the nixpkgs-src.json, put it into the unpacked hash field
<clever> reachingfourpeas: yeah
<clever> then look at its args and the /proc/PID/cwd for its pid
<clever> ldlework: ps aux | grep znc
<clever> ldlework: nixops ssh
<clever> ldlework: dont think so
<clever> reachingfourpeas: run `nix-prefetch-url --unpack` on that URL, then use that as the unpacked hash