2017-10-20

<clever> yeah
<clever> tazjin: and the code doesnt even exist in the latest master
<clever> tazjin: at a glance, it looks like it will only do something if there is a reference to system.build.toplevel-docker
<clever> yeah
<clever> hyper_ch: just a pair of matching eeepc 701's
<clever> goibhniu: i do have 2 of my netbooks managed by nixops
<clever> andrewrk: once something in the store has been built, its read-only and can never be modified
<clever> yeah
<clever> pie___: it looks like its only a qt5 thing
<clever> qt5.qtbase.dev 2,541 x /nix/store/vv5by93zr05xv69hnp4nl9anl57j3n6g-qtbase-5.8.0-dev/include/QtDBus/qtdbusglobal.h
<clever> glibc should be in the stdenv, so it will just work
<clever> which has the -I paths based on your buildInputs
<clever> andrewrk: you need to make sure the compiler obeys $NIX_CFLAGS_COMPILE
<clever> that will append it to the bash variable at build time, rather then doing it at eval time
<clever> '';
<clever> cmakeFlags="$cmakeFlags $(dirname $(cc -print-file-name=crtbegin.o))"
<clever> andrewrk: preConfigure = ''
<clever> yeah
<clever> oh, nice
<clever> yeah
<clever> "/nix/store/hlm2kkh1f1zbcssza8pzhsk2imd7c0h6-gcc-6.4.0"
<clever> nix-repl> "${stdenv.cc.cc}"
<clever> ah
<clever> zig?
<clever> gcc should just find it automatically
<clever> why do you need crtbegin.o?
<clever> andrewrk: what do you need that path for?
<clever> but stdenv.cc.cc is the real gcc
<clever> stdenv.cc is a bash script wrapping gcc
<clever> andrewrk: pkgs.gcc.cc
<clever> ldlework: returns a list without any keys
<clever> [ 10 20 ]
<clever> nix-repl> lib.mapAttrsFlatten (key: value: value*10) { a=1; b=2; }
<clever> lib.mapAttrsFlatten is another one
<clever> another example
<clever> nix-repl> lib.mapAttrs (key: value: value*10) { a=1; b=2; }
<clever> { a = 10; b = 20; }
<clever> ldlework: this
<clever> nix-repl> lib.mapAttrs (key: value: "${key} = ${value}") { a="1"; b="2"; }
<clever> { a = "a = 1"; b = "b = 2"; }
<clever> or "git diff"
<clever> the standard output of "diff -ur"
<clever> patches = [ ./foo.patch ];
<clever> pie___: add it to the patches list witin the derivation

2017-10-19

<clever> geolocated dns replies and cloudfront mirrors
<clever> looks normal
<clever> gilligan_: 404 for me
<clever> availableKernelModules are just available, and udev will auto-load them as needed
<clever> kernelModules are forcibly loaded
<clever> which calls under hci
<clever> you also need a usb driver for the controller
<clever> check lsmod for anything hci, usb, or hid related and throw it into boot.initrd.availableKernelModules
<clever> hyper_ch: yeah
<clever> no idea what you will loose by going to such an old version
<clever> yep, thats what nix-locate said
<clever> gnupg1orig.out 3,414 x /nix/store/6d7cs7ivz6lh9m0rji4jlbk67l3w501j-gnupg-1.4.21/bin/gpg-zip
<clever> ]$ nix-locate gpg-zip
<clever> not sure then
<clever> ldlework: that allows you to access "bar" at pkgs.plugins.foo
<clever> ldlework: overlays dont add it to the search path
<clever> ldlework: but what values you assign to the attributes, dont matter, you can store anything
<clever> ldlework: i believe the overlays must be in the form of self: super: { ... }
<clever> ldlework: that sets pkgs.plugins to a function
<clever> ldlework: so having a 3rd argument would break it
<clever> ldlework: the overlays systems expects to pass 2 arguments to the overlay, and get a set back
<clever> yeah, i have runit on mine, and it was able to work as a nix build slave, but not much more
<clever> MichaelRaskin: i also applied an override to a few things, to get systemd out of the closure
<clever> Li[m]1: yep
<clever> for fetch functions, you want to use super
<clever> super is the result from applying all previous overlays (using it wrongly can lead to some overlays not appearing)
<clever> self is the result after all overrides (it can cause infinite recursion)
<clever> both self and super are instances of pkgs
<clever> your arguments on line 1 arent right
<clever> ldlework: also, an overlay should have 2 arguments, self: super:
<clever> your already being given pkgs at line 1
<clever> ldlework: line 3 loads nixpkgs, which need overlays, which need nixpkgs, which need overlays.....
<clever> ldlework: line 3 is a problem
<clever> ldlework: can you gist the file you changed that triggered that?
<clever> Li[m]1: postInstall would be where i would usually do it
<clever> ldlework: its a nixos option, on the page i just linked
<clever> ldlework: not sure if home-manager includes that one or not
<clever> Li[m]1: writeFile will create a new derivation
<clever> ldlework: which is done at nixpkgs.overlays
<clever> ldlework: package overrides are better when you want to modify the list of pkgs directly
<clever> thats also how pkgs winds up in the args to begin with
<clever> ldlework: you can add custom arguments that get passed to every module
<clever> ldlework: i think your better off at this point putting things right into imports where they belong
<clever> so overlays help when you want to trivialy take overrides others have made, and add them to your own
<clever> yeah, the only real benefit i see to overlays, is that it you can only have 1 packageOverride, but you can have many overlays
<clever> but they take a super and self argument, and then return a set of overrides
<clever> i havent actually used them much yet
<clever> then they will already be loaded for everything
<clever> ldlework: you could also just use config.nix (or an overlay) to store your plugins at pkgs.your-plugins
<clever> it wont even load a file called plugins.nix!
<clever> and then <plugins.nix> will map to /home/clever/something-else.nix directly
<clever> you can also add plugins.nix=/home/clever/something-else.nix
<clever> it can be anywhere
<clever> just preference
<clever> thats how $NIX_PATH works
<clever> and then <plugins.nix> will look for a file called plugins.nix, inside /etc/nixos/plugins
<clever> ldlework: ah, you can just add /etc/nixos/plugins to the NIX_PATH
<clever> ldlework: what are you thinking of?
<clever> both of them went out of range while i was still within spitting distance
<clever> the music profile buffered lost packets, until it had 30 seconds of latency
<clever> the phone profile sounded like crap
<clever> same
<clever> when it should be looking directly in the store, at the right version
<clever> simpson: sounds like something is incorrectly looking in /run/current-system/sw/lib/
<clever> sirkha_: patchelf, its in the nixpkgs manual
<clever> ison111: for example, preConfigure = ''export DESTDIR=''${out}'';
<clever> ison111: you need to escape that ${ and then eval it at bash time, not nix time
<clever> ah
<clever> dont import it either
<clever> ldlework: you must put the result of the fetch in your list on imports
<clever> ldlework: so callPackage wont work, and giving it args will also fail
<clever> ldlework: thats a module, not a package
<clever> ldlework: oh
<clever> ldlework: it will use pkgs.config pkgs.lib and pkgs.etc
<clever> ison111: its only an environment variable, that exists at build time
<clever> ison111: that is refering to the nix variable out, which doesnt exist
<clever> ldlework: nix will inspect the function to see what arguments it wants, and pass those values from pkgs.
<clever> ison111: and what happens when you try to build that?
<clever> ldlework: pkgs.callPackage (fetchFromGitHub { ... }) {};
<clever> ldlework: also, you want to use callPackage, not import and args
<clever> ldlework: import (fetchFromGitHub { ... }) args
<clever> ldlework: you have to import the result of the fetch
<clever> ldlework: gist the expression and i can take a look?
<clever> ison111: something must have unset the variable

2017-10-18

<clever> rnhmjoj[m]: (drv: { patches = drv.patches ++ [ ./foo.patch ]; })
<clever> rnhmjoj[m]: ahh
<clever> that wont be restricted to any user, so sudo wont be required
<clever> ariutta: try using /nix/var/nix/profiles/default/bin/jq
<clever> ariutta: what does "ls -lh /home/ariutta/.nix-profile" say?
<clever> ariutta: no
<clever> ariutta: you may need to get the path to be set better
<clever> ariutta: run "type jq" to see where jq is coming from $PATH
<clever> so its being wrapped with 2 bash scripts
<clever> voiceftp: "emacs" is a bash script, that runs .emacs-wrapped, which is a symlink to emacs-25.3, which itself is an identical wrapper, over .emacs-25.3-wrapped
<clever> voiceftp: and i found a bug
<clever> voiceftp: i see why, that .emacs-wrapped is just a symlink
<clever> lrwxrwxrwx 1 root root 10 Dec 31 1969 .emacs-wrapped -> emacs-25.3
<clever> voiceftp: ah, that name includes the version, and it got truncated because the struct in the kernel has a limited size
<clever> voiceftp: what about the Name: field under /proc/<PID>/status ?
<clever> voiceftp: what name does "ps aux | grep emacs" show?
<clever> voiceftp: killall .foo-wrapped?
<clever> elvishjerricco: the only solution ive seen is to configure root@localhost as a build slave
<clever> elvishjerricco: it will only use build slaves defined in /etc/nix/machines
<clever> CrazedProgrammer: currently, you need to add some swap, or start with a smaller installation
<clever> euniarte, CrazedProgrammer: thats a bug in the current nixos-install
<clever> rec*
<clever> inherit doesnt get tripped up, and without the ref, foo=foo; does what you would expect in nix
<clever> nix-repl> let foo = 5; in rec { inherit foo; }
<clever> { foo = 5; }
<clever> the only time inherit foo is different from foo=foo, is when rec comes into play
<clever> { foo = error: infinite recursion encountered, at (string):1:29
<clever> nix-repl> let foo = 5; in rec { foo = foo; }
<clever> rnhmjoj[m]: nix keeps the $out of failed builds, but doesnt flag them as valid, so they are the first target for GC
<clever> rnhmjoj[m]: after it fails again, grep its output
<clever> rnhmjoj[m]: so you need to grep for /nix/store/[...]-gcc-wrapper-6.4.0 within /nix/store/[...]-firefox-56.0.1
<clever> rnhmjoj[m]: the problem is in the storepath, not the tmp directory
<clever> tnks: "found it, one min" with my hand being offset a column
<clever> tnks: its part of cabal2nix
<clever> tnks: fiybd utm ibe nun
<clever> tnks: interesting...
<clever> pkgs/development/haskell-modules/hackage-packages.nix: preConfigure = "sed -i hmatrix.cabal -e 's@/usr/@/dont/hardcode/paths/@'";
<clever> tnks: this file has overrides, to apply fixes to the generated content
<clever> tnks: there should be directions on how its generated in the same directory, and i believe peti does that most of the time
<clever> rnhmjoj[m]: use grep -r to find the gcc-wrapper path within the firefox output, after it fails
<clever> infinisil: if its usb, just unplug and replug the device, after the switch has finished
<clever> gchristensen: i recently threw together this module to make nixos rescue trivial: https://github.com/cleverca22/nixos-configs/blob/master/rescue_boot.nix
<clever> tnks: yeah
<clever> tnks: packages could still do that in $out/share/doc/
<clever> but its great if you just want to delete the user and all traces of the service when it stops
<clever> cransom: i dont think that plays nicely with having state that must be owned by the service
<clever> infinisil: thats just a set of every service that has been given an id
<clever> infinisil: and services are typically given a static gid
<clever> infinisil: automatic gid's lead to a different gid on every machine
<clever> woffs: ahh
<clever> eacameron: if you throw the entire output into a gist i can look over it
<clever> eacameron: and thats where /boot lives!
<clever> User Capacity: 160,041,885,696 bytes [160 GB]
<clever> eacameron: and the drive is at a toasty 35c right now
<clever> 194 Temperature_Celsius 0x0002 171 171 000 Old_age Always - 35 (Min/Max 13/56)
<clever> eacameron: in this case, i have had a total of 2 sectors fail on this drive, and it has silently remapped them to other spares
<clever> 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 2
<clever> eacameron: other numbers like this can also be of use
<clever> 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 2
<clever> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
<clever> eacameron: smartctl -a will check everything and print it all to stdout
<clever> ldlework: i havent read the source for home manager yet, so not sure what else you can do to make it work that way
<clever> yrashk: it looks like virtualbox is somehow mixing qt 5.9.1 and 5.9.1, youll need to investigate the output of "nix-store -qR" ran against the virtualbox binary, and some other things
<clever> yrashk: what does "type VirtualBox" return?
<clever> yrashk: how is virtualbox installed?
<clever> tnks: that gets compiled into the html docs, that are visible somewhere
<clever> ah
<clever> Unode: also, is this from the burp proxy suite?, i was thinking about getting it working recently
<clever> Unode: try adding set -x to the start of that script
<clever> Unode: the whole .service
<clever> Unode: can you gist the resulting .service file from /etc/systemd/system/ ?
<clever> but at this point, its probably better to just patch lib/default.nix instead
<clever> so when things try to use normal import, they instead get a scopedImport that overwrites builtins
<clever> ldlework: overwrite builtins.import = path: builtins.scopedImport { builtins = new_builtins; } path;
<clever> ldlework: but it only works at one level of depth, so you also have to wrap the new builtins.import if you want it to be recursive
<clever> ldlework: this even allows you to overwrite builtins with another attrset of your own creation
<clever> ldlework: this will import a given file (eval-config in this case) and forcibly set __nix_path as a global variable in that scope
<clever> ldlework: builtins.scopedImport { inherit __nixPath; } <nixpkgs/nixos/lib/eval-config.nix> {})
<clever> tnks: as long as the nix-daemon is from the old version, it should be safe, as long as the new nix doesnt gain root
<clever> infinisil: then you need a udev rule to assign a better group to that node, and put your user in the group
<clever> tnks: the new version of nix will upgrade the db in /nix/var/ and then the old nix wont work anymore
<clever> infinisil: what about the group of 006?
<clever> ldlework: scopedImport is an impure way of doing all kinds of fun things
<clever> tnks: its part of nixUnstable, "nix-shell -p nixUnstable" and avoid giving that nix root, enless you want to commit to using it forever
<clever> tnks: its the new replacement for nix-copy-closure
<clever> but some things like "nix copy" want to talk to the daemon and local
<clever> tnks: ah
<clever> tnks: i prefer ssh agent over giving the builder my secrets
<clever> srhb: it can upgrade your db.sqlite, and then the old nix wont be able to do anything
<clever> srhb: you need to "nix-shell -p nixUnstable" and be careful to not run that nix as root
<clever> sheyll: and this will copy from the default store, to /mnt/nix/store/
<clever> nix copy --to local?root=/mnt
<clever> then you need to secure /mnt so nobody can peek inside it
<clever> srhb: a command like this would operate on /mnt/nix/store/
<clever> NIX_REMOTE=local?root=/mnt nix-build ...
<clever> srhb: checking my notes...
<clever> there is a createHome option on ever user
<clever> Unode: is it also the home directory for a user?
<clever> Unode: what is the path?
<clever> no
<clever> taaperotassu: and if the nixos manual lacks the details, you lookup where nixos uses it, and then check the xorg manuals
<clever> taaperotassu: the manual says its , seperated
<clever> Example value:"grp:caps_toggle, grp_led:scroll"
<clever> taaperotassu: services.xserver.xkbOptions = "caps:swapescape";
<clever> taaperotassu: https://nixos.org/nixos/options.html#services.xserver.xkb
<clever> taaperotassu: there is a nixos option for that
<clever> Unode: and you also need to add it to nixos/modules-list.nix i believe
<clever> Unode: you need -I nixpkgs=/path/to/nixpkgs
<clever> taaperotassu: nixos can do that, one min
<clever> wmertens[m]: in my case, i was able to open the luks for the rootfs, but i forgot to add zfs support to that netboot image
<clever> wmertens[m]: i just grabbed the netboot kernel&initrd, and jammed them into /boot, with a menuentry
<clever> wmertens[m]: locally
<clever> gateway?
<clever> jtojnar_: routing tables?
<clever> wmertens[m]: got the rescue shell working
<clever> the script for building that derivation is telling emacs to write somewhere it shouldnt
<clever> ldlework: the error was at build time, so --show-trace wont help any
<clever> eacameron: nix-env -iA nixos.smartctl
<clever> eacameron: smartctl -a
<clever> jtojnar_: the NAT could also be the problem, is it only happening with idle connections?
<clever> jtojnar_: if the dhcp server is crap, and changes the IP you are given, yes
<clever> eacameron: ive memorized an unreasonable percentage of the nixpkgs codebase ...
<clever> eacameron: also look at line 99-102 in the same file
<clever> eacameron: i believe --cores is the one that gets routed to NIX_BUILD_CORES
<clever> wmertens[m]: that 2nd instance of nixos should also get a simple configuration.nix with things like boot.supportedFilesystems = [ "btrfs" ]; and a way to login
<clever> wmertens[m]: basicaly, you want to import a 2nd instance of <nixpkgs/nixos> (as i do in the netboot_server.nix above), and then refer to the kernel, initrd, and kernelParams like netboot.nix does
<clever> and presents a gui over ssh for selecting a different kernel
<clever> it would probably be a custom initrd with dropbear that just kexec's the default kernel in the config
<clever> so you dont need console access from the provider
<clever> wmertens[m]: i have also been thinking about a bootloader that gives you a network console, to deal with this kind of problem
<clever> and have 2 interfaces on one
<clever> but you would need to specialy route the network between 2 VM's
<clever> ah
<clever> wmertens[m]: remote or local vm?
<clever> wmertens[m]: another option, does this machine have an ethernet port, and do you have a 2nd machine with both wifi&ethernet?
<clever> wmertens[m]: after compression its about 200-300mb
<clever> TweyII: lib.optional and its friends can probably do it
<clever> which could fit into /boot/
<clever> i have another trick in mind, that gives you a full nixos environment, running from a ramdisk
<clever> so its simpler to just write that down and manualy append it when things go wrong
<clever> the tricky part, is that the names for the kernel and initrd are in constant flux
<clever> boot.debug1mounts would give you a shell in the initrd, with the rootfs mounted to /mnt/
<clever> boot.debug1 boot.debug1devices boot.debug1mounts force a shell at various points in the stage-1 script
<clever> boot.shell_on_fail lets you get a shell when it fails to run stage 2
<clever> wmertens[m]: these are all options that the initrd script will accept
<clever> ah, what is the total size of the /boot partition?
<clever> wmertens[m]: eek, my idea for a rescue shell needs ~300mb
<clever> wmertens[m]: i have been thinking of a simple option for that, how big is your /boot?
<clever> yep
<clever> thats for normal nix-env use, and wont have the nixos generations
<clever> thats the profile for nixos-rebuild
<clever> keta_suki: you also need to give it -p, to tell it which profile to list the generations in
<clever> wmertens[m]: https://btrfs.wiki.kernel.org/index.php/FAQ#or_My_filesystem_is_full.2C_and_I.27ve_put_almost_nothing_into_it.21
<clever> wmertens[m]: the metadata pool is full
<clever> wmertens[m]: btfs does that a lot
<clever> it may be partially corrupt
<clever> ah, then your rootfs is still good
<clever> wmertens[m]: there is also a rdinit= to change the init within the initrd, but the stage-1 script has other stuff thats better
<clever> wmertens[m]: take the existing init that ends in /nix/store/<hash>/init and change it to end in <hash>/sw/bin/sh