2017-03-12

<clever> viric: can you gist your nix file and the --show-trace?
<clever> viric: a fix i game up with a while ago
<clever> 2017-03-04 13:25:54< clever> 2017-02-28 22:08:14< clever> platform = (import <nixpkgs> { config = {}; }).platforms.aarch64-multiplatform;
<clever> viric: i think the cause was somebody changing how nixpkgs works, and they didnt test pkgs = import <nixpkgs> { platform = pkgs.platforms.foo; }
<clever> ndowens08: no idea, would need to know more context first
<clever> srk: there is also a nixos module that already does this
<clever> srk: nixos creates /etc on bootup
<clever> srk: and that will copy it current value to the right folder, if ran on bootup
<clever> srk: you can do ''cp -vi ${./configuration.nix} /etc/nixos/configuration.nix''; in a configuration.nix file
<clever> srk: so either append to $PATH, or add more things you use to the buildEnv
<clever> srk: line 17 may need some tweaking, i went the ultra-pure route, so $PATH only has exactly what you reference, and nothing from the host can leak in
<clever> or load app2.nix and reference it from app1
<clever> you can also use imports in config.nix, and make your config as fun as you want it
<clever> in theory, it will even work on darwin
<clever> but your not making any use of nixos modules
<clever> and that bash script has full use of the entire options/config framework that powers nixos
<clever> srk: and if you then nix-build -A config.system.build.app1, it will compile the bash script on line 15
<clever> srk: and then config.nix is where you put the actual config, just like configuration.nix
<clever> srk: default.nix and common.nix are just support framework to glue it together
<clever> srk: and it generates a script on line 15, that will setup env variables and execute the app, possibly referencing a config file also built by nix
<clever> srk: app1.nix is where you define all of the options for your app, exactly as you would in a normal nixos module
<clever> smw_: and u-boot has to load the right dtb, to tell it what hardware exists
<clever> smw_: ah, not sure about that one, it may need some dtb files to enable that hardware
<clever> NickHu: i believe it should be
<clever> smw_: did you enable the bcm usb stack in "make menuconfig" ?
<clever> NickHu: it can be forced: boot.initrd.prepend = [ "${/crypto_keyfile.bin}" ];
<clever> ah, what about boot.initrd.prepend = [ /crypto_keyfile.bin ]; ?
<clever> boot.initrd.prepend = /crypto_keyfile.bin;
<clever> what if you unquote it and dont make it an array?
<clever> does the file exist at that path on the main system?
<clever> what exactly did you put into the config?
<clever> NickHu: if you unquote the path, nix will automaticaly copy it into the build sandbox, and it has to already be a CPIO archive
<clever> srk: writing it now
<clever> smw_: oops, meant that for srk
<clever> smw_: i can whip up an example in a minute
<clever> :)
<clever> smw_: that will serialize the entire config, write it to a storepath, and put that path into an env var
<clever> smw_: i have this in a systemd unit for one of my services
<clever> CONFIG_FILE = pkgs.writeText "config.json" (builtins.toJSON config_set);
<clever> smw_: so you can just build a nix object describing the config, then turn it into json
<clever> smw_: nix also has a builtins.toJSON function
<clever> smw_: but to use the options framework, youll need code like this: https://github.com/cleverca22/not-os/blob/master/default.nix#L12-L34
<clever> smw_: that should be in the main nix docs
<clever> smw_: should be possible
<clever> smw_: the nginx configs in nixos are pretty powerful
<clever> NickHu: the key will also be world readable in /nix/store/
<clever> NickHu: unquote the path in the config for luks, and nix will automaticaly do all the copying for you
<clever> griff_: in my system, it does not depend on lvm2, but it does depend on llvm
<clever> griff_: this command will show the entire built-time dep tree for openjdk
<clever> [clever@laptop:~]$ nix-store -q --tree $(nix-instantiate '<nixpkgs>' -A openjdk)
<clever> the hardware
<clever> but the kernel has to match
<clever> smw_: raspbian always run an armv6 userland, so it maintains backwards compat to the rpi1
<clever> smw_: kernel.img is built for an armv6 (rpi1), kernel7.img is for the armv7's (rpi2 and rpi3 in compat mode)
<clever> smw_: if you unpack that to a normal linux system, you can cross-compile a kernel
<clever> smw_: and in here is the pre-built linux->arm cross-compiler: https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi
<clever> thats on the firmware repo
<clever> but if your building your own, just enable what you want, directly in the kernel config
<clever> the main point of the initrd, is so you can make a really tiny kernel, and then load the optional things that this exact user wants
<clever> smw_: but if you link that into the kernel at build time, you dont need the initrd
<clever> smw_: the initrd allows i to load modules after booting, to gain the ability to mount the rootfs
<clever> smw_: and if your building the kernel, you can just make everything you want built in, that eliminates the entire need for the initrd
<clever> smw_: i believe they also have a link to a pre-built arm gcc for linux
<clever> smw_: ah, thats much simpler
<clever> ndowens08: you want $out/bin/
<clever> ndowens08: line 33 is your problem, you are trying to reference your own return value
<clever> smw_: i usualy go the route of a "native" arm build, under qemu-user
<clever> smw_: so you wind up having to build everything twice, natively and cross
<clever> smw_: proper cross-compiling is tricky with nixpkgs, it considers it a different build, so native nix-env -iA will refuse to use the cross-built glibc and so on
<clever> ndowens08: can you gist that file?
<clever> NickHu: i have nixos-unstable on 3 systems, and 16.09 on 2 i think
<clever> ndowens08: which derivation are you trying to override?
<clever> smw_: but the boot rom in the rpi has no config
<clever> smw_: u-boot can read config files and just load it from the right place
<clever> smw_: ahh, thats a lot more flexible and wont need special dhcp config
<clever> srk: this is how i fixed the platform problems
<clever> 2017-03-04 13:25:54< clever> 2017-02-28 22:08:14< clever> platform = (import <nixpkgs> { config = {}; }).platforms.aarch64-multiplatform;
<clever> srk: ah, looks like your setting nix.package, which is different from what i was asking
<clever> srk: was the infinite recursion related to setting nixpkgs.config.platform?
<clever> smw_: you can also use a desktop or even a virtualbox vm in bridge mode
<clever> srk: platform?
<clever> mitchty: what happens if you just manualy run curl on the same URL as near the error msg?
<clever> srk: ive been following them in #raspberrypi-internals
<clever> Criena[m]: systemd.services.nginx.path = [ pkgs.python ]; should add python to $PATH for the nginx service
<clever> t
<clever> there are still some bugs the rpi foundation is ironing ou
<clever> smw_: when i was doing it, the uSD had to contain only bootcode.bin and no other files
<clever> that would allow you to boot the rpi3 over the network from a dir containing ~6 files
<clever> then you could in theory, configure network booting for the rpi
<clever> one crazy route we could take, disable the dhcp in the router, then setup your own dhcpd in nixos, that still says to use the router as a gateway
<clever> advance stuff that no home router gives you control over
<clever> smw_: do you have control of the DHCP server?
<clever> nope
<clever> smw_: yes
<clever> that will give you a shell with those 3 things available, without having to install them globally
<clever> lezed1: just run nix-shell -p eigen ncurses pkgconfig
<clever> lezed1: and the same for ncurses, dev is the default output
<clever> lezed1: just put eigen into the buildInputs
<clever> and when that string gets compiled, it will turn into a storepath
<clever> zetok: and because the vim config is in a nix string, i could include ${./foo.cfg}
<clever> zetok: https://gist.github.com/cleverca22/1e7dad019431a5dd014ef262f9e3325f is how ive done my vim stuff
<clever> zetok: i think its just boot.kernelParams
<clever> c74d: as long as nix can figure out the key names within your .config attrset, it can compute which module to route into, and lazy its way around the problem
<clever> c74d: so you are getting your own return value as an argument
<clever> c74d: the config argument passed to every module, is the result of inteligently merging the .config attribute RETURNED by every module
<clever> devoid: this should have some more info: https://wiki.archlinux.org/index.php/Mac#Arch_Linux_only
<clever> devoid: so it needs an unencrypted fat32 /boot partition for efi use, and boot.loader.grub.efiSupport = true; and grub.device = "nodev";
<clever> devoid: ah, i think the macbook's dont support legacy booting
<clever> c74d: ive only ever done it with a ext4 /boot, but the nixos modules imply it can work without that
<clever> devoid: does it say GRUB when booting?
<clever> devoid: you may need to turn off secureboot and enable the compatability module
<clever> but the scrollback is cleared when you change tty
<clever> shift+page up also works in the raw tty of linux
<clever> shift + pageup to scroll in most terminals
<clever> it may also be in the t command of fdisk
<clever> using gparted, a gui partitioning program
<clever> i just manualy ran it and copied the terminal output
<clever> devoid: can you gist the output of fdisk, along with the i of the bios boot partition?
<clever> yeah, try rebooting, and confirm fdisk shows the right attr still
<clever> oh w was also there
<clever> q is quit without saving
<clever> how did you quit fdisk?
<clever> is the grub device still set to sda?
<clever> ive usualy made it from gparted
<clever> devoid: it may be the A command under expert mode, you can confirm it did the right thing by checking i again
<clever> i believe you can set it with fdisk
<clever> devoid: does fdisk show the same attribute as on line 36?
<clever> devoid: no, let me find a command to inspect it
<clever> so i can reuse it without changes between many machines
<clever> i load that via imports = [ ./vim.nix ];
<clever> there is nothing after it
<clever> that {} is the entire body of the file
<clever> look closer at my gist, it only has a single {} after the in keyword
<clever> just take out lines 45 and 50
<clever> you need let ... in value, not let ... in value value
<clever> ndowens08: you now have 2 attribute sets
<clever> ndowens08: line 42-51 is your problem
<clever> the let block basicaly defines local constants for the value after the 'in' keyword
<clever> you can do key = let ... in value; but then it gets ugly
<clever> so it cant go directly inside an attrset where key=value pairs belong
<clever> yeah, the let ... in ... has to go before a value
<clever> ndowens08: can you pastebin your configuration.nix?
<clever> devoid: and in your case, that raw chunk of x86 has luks support, and will ask for the pw to unlock / and load the kernel
<clever> devoid: the stub in the MBR (the first 512 bytes) will execute the raw code in the biso boot partition
<clever> devoid: the bios boot partition has no FS on it, grub will write raw x86 code directly to the partition
<clever> ndowens08: i put my vim config into configuration.nix, so it always gets restored to the identical setup
<clever> c74d: but by chance, i noticed it had an ipv6 link-local ip, and was able to get in
<clever> c74d: only to discover, VM's get zero dhcp, and it had no routable v4 ip
<clever> c74d: so i configured my vpn to connect out on bootup, using the private ip from dhcp
<clever> c74d: with past experiments on a dedicated box, i found that the dhcp gives a private ip with NAT to the web, and you must configure a static public ip manualy to be open to the web
<clever> that datacenter was also a "fun" test of kexec
<clever> i gave it a 5 minute delay so i could always shutdown -c if i forgot
<clever> or i had no way to remotely stop nixos
<clever> so i had to correctly configure the network perfectly
<clever> i was last using it in a datacenter that lacked DHCP
<clever> c74d: and you can stop it with "systemctl stop autoreboot.timer"
<clever> c74d: if you cant get into it, it will reboot back to the previous os
<clever> devoid: and the error said exactly the same thing, "warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible"
<clever> devoid: and if you want to boot with EFI, there must be an unencrypted fat32 for the bootloader
<clever> devoid: if you want to boot via legacy with GPT, you must create a 1mb partition with the type set to "bios boot partition"
<clever> devoid: is this a gpt drive?
<clever> devoid: the config you gave doesnt enable efi
<clever> but that wont affect grub install
<clever> devoid: only other major difference i can see vs my config, is that i set it to open the luks before lvm
<clever> { name = "root"; device = "/dev/sda3"; preLVM = true; }
<clever> sda works, just need to be careful when the drives change order
<clever> and only GPT has a uuid for the root of the device
<clever> devoid: ah, reguarding the comment on line 23, the grub device must be the root, sda, it cant be a partition
<clever> checking the rest now...
<clever> that provides a sane default for home
<clever> devoid: you forgot to set isNormalUser=true; on your user
<clever> there is a nixpaste site, but i prefer gist because is sanely handles multiple files
<clever> nix-env -iA nixos.gist ; gist -p configuration.nix hardware-configuration.nix
<clever> gist.github.com, nix also has a gist command
<clever> can you gist the configuration.nix and hardware-configuration.nix?
<clever> thats not it then
<clever> devoid: what did you set grub.device to?
<clever> devoid: what did you set grubdevice to?

2017-03-11

<clever> c74d: i try to keep them on stable
<clever> Rotaerk: the laptop keyboard has a few faulty keys
<clever> hlolli: put boost into the buildInputs of the package
<clever> i'm talking about nix-env -i vs nix-hell
<clever> nix skips the dev output
<clever> and installing things never gives you headers
<clever> you need to builtins.toString and expect a number
<clever> yeah
<clever> Rotaerk: and then later do thing "initial" [ "1" "2" "3" ];
<clever> Rotaerk: and similiar to haskell, you can return a partialy applied primop, so you can just do thing = builtins.foldl' (a: b: a + b)
<clever> Rotaerk: so if you gave it a list of functions, it would run the lamba with "initial" f1, then f1(initial) f2 ...
<clever> nix-repl> builtins.foldl' (a: b: a + b) "initial" [ "1" "2" "3" ]
<clever> "initial123"
<clever> Rotaerk: you can probably use fold to run a list of functions on eachothers output, with x being the initial input
<clever> Rotaerk: foldl' maybe?
<clever> what are you trying to do?
<clever> i usualy identify which derivation the fault is in via gdb, then rebuild just that with symbols
<clever> but foo lacks symbols
<clever> so now bar gets symbols, and foo link against the debug build of bar
<clever> another way of using it, foo.override { bar = pkgs.enableDebugging pkgs.bar; };
<clever> zetok: every package you want debug symbols for
<clever> zetok: you need to run enableDebugging over a derivation, like nix-build -E 'with import <nixpkgs> {}; enableDebugging hello'
<clever> i recently switched 2 servers to nixos at another datacenter, and i had to open a support ticket just to get the cd tray closed, lol
<clever> the biggest benefit i see with the OVH rescue setup, is that you can remotely trigger it even if the machine is bricked
<clever> the linode guide on the wiki should work just fine
<clever> not sure, could open an issue and see what others think
<clever> just run "nox obs"
<clever> bb: yeah, and here is an example of what the changes should look like: https://github.com/NixOS/nixpkgs/pull/23679/files
<clever> nox is a python program that will cache the package list, and then do searches on that cache
<clever> zetok: i prefer either tab-completing in the repl or using nox
<clever> no idea when that is though
<clever> Yaniel: i'm guessing nix 1.11.8
<clever> so a -small channel updates faster, but you may have to compile things
<clever> and the non -small channels wait for hydra to build every single package
<clever> the -small channels wait for only the above tests, so they can still update relatively quickly
<clever> the nixpkgs- channel has only very basic tests, i heard something about just vim and emacs working
<clever> the nixos- channels have testing done, to ensure they cant brick a nixos machine, and that makes them slower to update
<clever> and you must never put a nixpkgs- channel on root with nixos
<clever> this will force it to load nixpkgs from the current user
<clever> nix-repl ~/.nix-defexpr/channels/nixpkgs
<clever> bu that will probably load the nixos channel on root
<clever> nix-repl '<nixpkgs>'
<clever> there is also nox, which will do search and cache the db
<clever> -iA tells it exactly what to install
<clever> which makes it ungodly slow, and in some cases, i dont have enough ram to even complete that
<clever> i avoid -i whenever i can, because it searches the .name attribute of every package in nixpkgs
<clever> looks like it
<clever> s
<clever> rather then the "first" channel with something called pas
<clever> yeah, that tells it to look in a channel called nixpkgs
<clever> but you can tell nix-env which channel to fetch from, the above command may solve it
<clever> and 16.09 isnt likely to have that update
<clever> brh: and try nix-env -iA nixpkgs.pass
<clever> yep
<clever> brh: run sudo nix-channel --list
<clever> brh: are you on nixos or another distro?
<clever> brh: oh, and that 5 day figure is nixos-unstable, but you mentioned nixpkg-unstable
<clever> brh: it may have updated 5 days ago, but did it use a commit from 5 days ago, or older?
<clever> brh: the nixos-unstable-small channel is 15 hours old, so thats one way to temporarily get around the problem
<clever> but its not in 1.11.7, so it probably wont even work on nixpkgs master
<clever> this allows you to do cmakeFlags = [ "a" "--foo=${builtins.placeholder "out"}" ]; at the nix lvel
<clever> Yaniel: something to do with hashPlaceholder
<clever> let me find it
<clever> Yaniel: there is a new feature being added to nix that will solve this
<clever> may need a space at the start, but that should work
<clever> so when bash does this assignment, it expands the old flags and out
<clever> could skip the bash array logic, cmakeFlags="$cmakeFlags --foo=$out";
<clever> ah
<clever> cmakeFlags = [ "a" "b" ];
<clever> ah, if they are constant you can just set them at the nix level
<clever> Yaniel: how are you setting them?
<clever> avn_nb: one option is to make /boot a seperate zfs filesystem within the same pool, then it can have dedup off
<clever> avn_nb: it might be that zfs dedups the /boot files and the originals in /nix/store, and grub cant handle that dedup
<clever> so grub is having trouble with some paths in zfs
<clever> avn_nb: ah, sounds like /boot is still on zfs, but then grub doesnt have to deal with the insane size of /nix/store/
<clever> i just trust lvm more with swap
<clever> and because of the deadlock stuff ive heard about, my laptop is (swap + zfs) on lvm, on luks
<clever> havent tried a swap file
<clever> Dezgeg: but zfs is also pretty memory hungry, and allocating memory while swapping isnt a good idea
<clever> Dezgeg: zfs claims to support swap in zvols, and its also a cow filesystem
<clever> avn_nb: ive only done it with an ext4 /boot, but i have seen a zfs option in grub
<clever> c0ff33: changing stateVersion will break the things it was meant to protect
<clever> c0ff33: and the whole point of stateVersion, is so nixos knows which version you originaly installed
<clever> brb
<clever> c0ff33: it tells nixos what version the state on your hdd is in, so pgsql and similar dont break from upgrades
<clever> c0ff33: stateVersion doesnt control what version of nixos you get
<clever> c0ff33: stateVersion doesnt do what you think
<clever> ndowens08: one of them has zfs on lvm on luks
<clever> ndowens08: 5 of my systems run with a zfs rootfs
<clever> grep -r on the source
<clever> substitute in ${linuxHeaders}/include/ maybe
<clever> thats one way to handle it
<clever> and not calling a compiler to do the job
<clever> Acou_Bass: so the real question, is why the python code is trying to open the header file directly
<clever> that works on 99% of linux systems
<clever> Acou_Bass: so the problem, is that this code is ignoring the search path entirely, and just doing string concats to build a path
<clever> it even says /usr/include right in the error
<clever> CHEAD = defines('/usr/include', 'linux/input.h')
<clever> if it was using the search path, it would have said <linux/input.h>
<clever> Acou_Bass: if the error says it cant find /usr/include/linux/input.h, then it probably isnt using the search path
<clever> Acou_Bass: what is the error?
<clever> ndowens08: but now i just throw it all on zfs, heh
<clever> ndowens08: this kind of problem is why i was throwing everything on LVM when i learned of it
<clever> ndowens08: and thats ~300gig you need to shift by 80gig
<clever> ndowens08: even if you delete sda12, you would need to move 6-11 down and out of the way
<clever> Ptival: could change the default then
<clever> Ptival: or use -I nixpkgs=/home/clever/nixpkgs when running nix-shell
<clever> Ptival: it gets that from the nixpkgs in $NIX_PATH usually
<clever> ndowens08: only options for resizing the ext4 in sda5 is to either delete/shrink partitions that come after it, or move it to a new drive
<clever> ndowens08: looks like its on a normal partition, what does "fdisk -l /dev/sda" say?
<clever> ndowens08: can you pastebin "df -h" ?
<clever> mythmon: ah