2017-03-11

<clever> ndowens08: is the ext4 on a partition or lvm or luks?
<clever> mythmon: pythonPackages.tox builds on my copy of nixos-unstable
<clever> ndowens08: what is the ext4 fs ontop of?
<clever> mythmon: did you try libtoxcore?
<clever> samae: looks like all i did was networking = { wireless.enable = true; enableB43Firmware = true; }; and manualy poppulated /etc/wpa_supplicant.conf
<clever> samae: when i used wpa_supplicant, i just manualy copied a pre-existing config to /etc/wpa_supplicant.conf, and it just worked
<clever> yeah, foo has to be replaced with the name of the package you want to override
<clever> ndowens08: this defines a function for applying overrides, and it will modify the foo package to use clang instead of gcc
<clever> ndowens08: one sec
<clever> config.nix doesnt get those argments, and its completely invalid
<clever> yeah, that wont work at all
<clever> ndowens08: ah, can you gist the config.nix also?
<clever> ndowens08: can you gist all of the involved files?

2017-03-10

<clever> its currently using buildbot, so i cant do concurrent builds, and there is tons of impure state to deal with
<clever> LnL: i plan to nix-ify it, as we discussed in ##nix-darwin
<clever> its doing something weird, that allows the dylib files to be within the foo.app "package"
<clever> ekleog: that project is still building the non-nix way
<clever> ndowens08: that lets you switch any derivation to clang
<clever> ndowens08: you can also do foo = foo.override { stdenv = clangStdenv; };
<clever> it now compiles all the way to a .dmg, but i havent had a chance to test it yet
<clever> ndowens08: so ive had to redo that project to build protobuf with clang
<clever> ndowens08: my best guess to the problem is that they did c++ name mangling differently, and now clang cant find the symbols
<clever> ndowens08: i spent an hour today trying to get clang to link against some protobuf stuff i think was built by gcc
<clever> yeah
<clever> you just reference which one you want in the nix expression
<clever> with nix, you shouldnt install things like gcc or clang
<clever> ndowens08: there is a clandStdenv.mkDerivation that uses clang by default
<clever> ndowens08: id say just test the program as normal, and if it works, it works
<clever> spluko: the ~/.config/nixpkgs/config.nix path was recently added, and has priority, some people have been tripped up by that, when it just ignores ~/.nixpkgs/config.nix
<clever> spluko: all other commands use ~/.nixpkgs/config.nix or ~/.config/nixpkgs/config.nix
<clever> spluko: yeah, only nixos-rebuild obeys the config in configuration.nix
<clever> spluko: that is much slower, so -A is always recomended
<clever> spluko: without the -A, nix-env will search the .name of every package (in every channel?)
<clever> spluko: so just add unstable as a channel to your user, and call it nixpkgs
<clever> spluko: nix-env -iA nixpkgs.foo will use the channel called nixpkgs
<clever> and there is state that may not be logged at all
<clever> jeremejevs: are you able to ssh in from another machine?
<clever> and then all applications claimed they didnt even have pulseaudio support, lol
<clever> so the new pulseaudio failed to start
<clever> jeremejevs: i did have an oddity yesterday when i had to restart xorg, and the old pulseaudio refused to die
<clever> then both nixos and root share the same overrides
<clever> some people just do nixpkgs.config = import /root/.nixpkgs/config.nix; in configuration.nix
<clever> jeremejevs: if the config argument isnt set, it will default to ~/.nixpkgs/config.nix
<clever> jeremejevs: internaly, nixos uses the config argument to force nixpkgs to obey nixpkgs.config
<clever> jeremejevs: i dont think this part is in any of the manuals
<clever> jeremejevs: you want let unstable = import <unstable> { config = config.nixpkgs.config; };
<clever> jeremejevs: that 2nd nixpkgs you loaded ignores the nixpkgs.config specified in configuration.nix
<clever> jeremejevs: and how is polybar installed?
<clever> jeremejevs: what file did you put that packageOverrides into?
<clever> jeremejevs: did you tell nix to build polybar again with the new config?
<clever> polybar = polybar.override { i3Support = true; };
<clever> ah, i3 is already an option
<clever> jeremejevs: if you add cmake to the list of buildInputs, it should automaticaly take over the configurePhase
<clever> c74d: this trick might even work on a 2.6 era kernel
<clever> c74d: i see mention of it in 2004 on wikipedia
<clever> c74d: and once hijacked, the old os means nothing, and its running pure nixos
<clever> c74d: the kexec trick basicaly uses a kexec-enabled kernel to steal ring0 control, and hijack the machine by force
<clever> c74d: any linux distro with kexec enabled will work
<clever> but you need to get the network and boot stuff 100% right, or it wont be accessible, and then its basicaly a brick
<clever> c74d: with this method, you get the installer env running from a ramdisk, so your free to format the hdd and nixos-install like normal
<clever> c74d: ive got a few ways of doing that
<clever> dmj`: i think xen is being referenced in the nixos manual
<clever> jsgrant-: the grub.conf file only gets updated when you do a nixos-rebuild (switch|boot)
<clever> shlevy: though being able to default back to a hard-coded version could be usefull
<clever> shlevy: in the case of NIX_SSL_CERT_FILE, i think that nixos and the nix profile script should setup sane defaults, pointing to either a system copy or a copy installed via nix-env
<clever> shlevy: using an absolute path to nix, or after sourcing the profile?
<clever> ah
<clever> shlevy: and if you dont source the nix profile script, you wont even get access to the nix tools
<clever> shlevy: the lines i just linked, install the certs to the nix profile using nix-env
<clever> cursor knob wont click, so i cant confirm the baud
<clever> smw_: scope is confirmed 80% working, i can see serial if i probe the TX of my serial adapter
<clever> but the SD reader is MIA
<clever> smw_: i may need to copy the /boot partition to an SD card to get thru this step
<clever> smw_: i'm thinking start.elf is failing to load
<clever> same on the 3.3v rail
<clever> might just be due to the pi being abnormaly idle
<clever> its perfectly flat even at the most extreme timebase
<clever> abnormaly stable 5v
<clever> steady 5v on the 5v pin
<clever> smw_: strange, 0v on the tx line
<clever> smw_: let me dig out the scope
<clever> smw_: no video or serial output
<clever> and its just an inch away from the usb serial adapter, lol
<clever> smw_: now to find the pi, lol, it should be at the other end of this hdmi...
<clever> smw_: the missing adapter, was on the end of the hdmi cable, still plugged into the pi!
<clever> (facepalm)
<clever> until u-boot works, you have zero serial output
<clever> harder to debug firmware problems then
<clever> smw_: now to find an hdmi<->dvi adapter...
<clever> smw_: 1475686400 bytes (1.5 GB, 1.4 GiB) copied, 537.569 s, 2.7 MB/s
<clever> smw_: flashing a usb stick now...
<clever> i believe that program is part of mask rom, so its etched into the cpu die when its made
<clever> it is a bit weird, but that are extremely short on rom space for that program
<clever> both methods can work on their own
<clever> the same bit enables both usb and network
<clever> no
<clever> who has control of your network?
<clever> since it can load an OS over the ethernet
<clever> probably a security risk
<clever> then it can load bootcode.bin from usb, or even tftp
<clever> if you can boot it once with a start.elf and a config.txt, you can burn a fuse in the cpu to enable it
<clever> nope
<clever> i can probably do it over usb
<clever> oh wait, i turned on the new bootstack in my rpi3
<clever> ive located a 16gig uSD card, now i just need a reader
<clever> but now that i have the build working, i can more quickly make changes on this end
<clever> no changes yet
<clever> i'll need to find a spare SD card and a reader, then i can test it on my end
<clever> and it will download the image i built
<clever> smw_: if you add that to /etc/nix/nix.conf, you can just run "nix-store -r /nix/store/n5n74pijd3x9jpcz0qrni9cdl7vgn1is-sd-image-armv7l-linux.img"
<clever> smw_: i added a nix.conf entry to the previous gist
<clever> smw_: havent had a chance to test that
<clever> icetan: hydra will also get the entire build-time closure of every dependency, even if it can get the built copy from the cache
<clever> smw_: that has to go into either configuration.nix or nix.conf (with changes)
<clever> icetan: try putting this config into the host: https://github.com/NixOS/nixpkgs/issues/18015#issuecomment-273374379
<clever> smw_: https://gist.github.com/cleverca22/3a5cbf36d23070c046091ed40125478d if you load this into any machine with nix and ~3gig of free space, you can download the image from my binary cache
<clever> i have 23gig free on a ZFS array, so the build took 1m 19sec, lol
<clever> it is now building the img
<clever> its more about being lazy, lol
<clever> but v6 has the same issue on real v7
<clever> even if its building for v6
<clever> packages like openssl detect the current cpu as armv7, and put v7 opcodes into the build
<clever> smw_: and this also has some issues with armv6
<clever> oh, and it looks like that qemu isnt in the chroot sandbox, i'll need to flip that off
<clever> and some other misc issues
<clever> xargs malfunctions, so large builds like a kernel are broken
<clever> smw_: and if i run the register script from that derivation, my x86 machine can magicaly run any arm binary
<clever> [root@amd-nixos:~]# ./arm/bin/register
<clever> so it will blindly try to run the arm gcc to do arm builds
<clever> smw_: now nix-daemon thinks i can run armv7 binaries on my x86 machine
<clever> smw_: nix.extraOptions = "build-extra-platforms = armv7l-linux";
<clever> smw_: ok, i have now build my nix-daemon with https://github.com/cleverca22/nix-misc/blob/master/upgrade.patch
<clever> smw_: ah, and my patch to nix isnt in place, i'll have to nixos-rebuild
<clever> smw_: this is the current output when i try to build it
<clever> error: a ‘armv7l-linux’ is required to build ‘/nix/store/zhz2053lqxmnp8kh2q25q8yay8wn9xag-users-groups.json.drv’, but I am a ‘x86_64-linux’
<clever> x86 binary cache means nothing to arm
<clever> so you arent garanteed x86 binary cache coverage, but it wont brick your machine
<clever> -small will run testing, but wont wait for the main hydra.nixos.org to finish every single build
<clever> smw_: its configured to follow nixos-unstable-small
<clever> smw_: i have a cache on my router, http://hydra.earthtools.ca/
<clever> smw_: but now that i think of it, i can just enable the qemu-user stuff i wrote, and then i can do that step on my desktop
<clever> smw_: i was able to compile everything, but i dont have enough free space on the SD to build the .img file
<clever> and if the OS fails to boot, it looses the fight
<clever> so the 2 parties are forever fighting over what the default should be
<clever> and then when the OS finishes booting, it restores the default again
<clever> generaly, its done by grub changing its own default, right before it boots the OS
<clever> yeah
<clever> and it would be much harder to brick a remote machine
<clever> with that, and a bit of panic+reboot on fail, you could get automatic rollbacks
<clever> ekleog: but this is also something i have been interested in, if a given generation fails to boot, go to the previous generation
<clever> until you run boot/switch again
<clever> not really, the boot flag will change the default and leave it like that
<clever> i have done that on purpose twice, to convert gentoo boxes to nixos
<clever> ekleog: i have also done even more insane things, if you run "switch-to-configuration boot" on a machine that isnt nixos, and you trick it into thinking it is nixos, it will overwrite grub!
<clever> next time i boot, the hack is gone
<clever> i prefer the 2nd fix for cases where i want to temporarily hack an option in, and i dont want nix to remember it
<clever> nixos-rebuild will undo that, and restore the symlink
<clever> ekleog: next level, is to go into /etc/nix, copy the contents of the symlink to a new file, delete the symlink, rename the file, and then fix the syntax error
<clever> ekleog: this will just directly activate any generation you want, without changing the default
<clever> ekleog: simplest, is something like "/nix/var/nix/profiles/system-268-link/bin/switch-to-configuration test"
<clever> ekleog: i can think of 2 options
<clever> my new hydra farms all binary cache access out to build slaves, so its a bit slower
<clever> my old hydra just downloads from the binary cache directly, and it shows up as localhost in the build steps
<clever> nope, but i have helped others that turned the binary cache off entirely and had it
<clever> ive been running the same version of hydra for over a year, so i'm not sure how the new versions behave yet
<clever> icetan: and https://github.com/NixOS/nixpkgs/issues/18015 is the open issue for this problem
<clever> services.hydra.useSubstitutes is a new option i found in nixos
<clever> icetan: the only solution is to use a binary cache to get a pre-built copy, or to ensure the /bin/sh referenced in nix.conf doesnt depend on the glibc your building
<clever> icetan: but /bin/sh is linked against glibc
<clever> icetan: the problem is that it needs to rebuild something like glibc.doc, so it has to omit the entire glibc from the sandbox
<clever> icetan: ive seen that before

2017-03-09

<clever> Yaniel: all libraries in nix should use absolute paths within /nix/store
<clever> jeremejevs: nix-env -iA nixos.google-chrome or nix-env -iA nixos.chromium
<clever> Yaniel: it may also obey the rpath of each so it reads
<clever> stepcut: that works
<clever> http://localhost would cover that
<clever> stepcut: nix-push can be an aimed external drive, as long as you can get the contents over http
<clever> stepcut: and with the above nix-build command, you can also root .dev outputs
<clever> stepcut: you can also use "nix-build '<nixpkgs>' -A foo -o foo" to root foo, without it landing in $PATH
<clever> stepcut: nix-push can be of use, you can export stuff to a static http server, then treat that as a binary cache
<clever> ah
<clever> so the GC will eat everything else, and then it may not run out
<clever> stepcut: the active build will root everything it needs, so the GC cant eat that
<clever> stepcut: one tip, start a build you know is going to run out, then start a GC

2017-03-08

<clever> 870/1198 storepaths copied, 2.4gig remain
<clever> 2.5gig left on mine, and about half of the storepaths are copied
<clever> Dezgeg: ouch!
<clever> copying 1198 missing paths (2859.95 MiB) to ‘builder@192.168.2.126’...
<clever> Dezgeg: looks like my build compiled everything, but is now running out of space making the disk image
<clever> /nix/store/gjhsysgkl234r95ly2kn1ypmfp704v4v-stdenv/setup: line 500: export: write error: No space left on device
<clever> building path(s) ‘/nix/store/n5n74pijd3x9jpcz0qrni9cdl7vgn1is-sd-image-armv7l-linux.img’
<clever> and what Dezgeg said can help also
<clever> stepcut: nix.buildMachines in configuration.nix is how you configure that on nixos
<clever> stepcut: and it will ssh into the pi to do the arm builds, but use the x86 ram for the nix expressions, where you are currently having the problems
<clever> stepcut: with that config and command, i can initiate an arm build on an x86 machine
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ nix-build nixos/default.nix -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix --argstr system "armv7l-linux" -k -A config.system.build.sdImage
<clever> builder@192.168.2.126 armv6l-linux,armv7l-linux /etc/nixos/keys/distro 1 1 big-parallel
<clever> $ cat /etc/nix/machines
<clever> stepcut: using nix build slaves, you can do the ram-heavy eval on another box
<clever> stepcut: check dmesg, that may tell you about oom issues
<clever> gchristensen: https://www.youtube.com/watch?v=V6ogpgieJrQ is an example of what ive done, this was operating with zero kernel code
<clever> lol
<clever> gchristensen: i have used the rpi gpu before, without the non-free driver
<clever> viric: and this COMPAT option allows an aarch64 kernel to run 32bit code
<clever> heh, there is a kernel option to allow an aarch64 kernel to emulate big-endian systems
<clever> then if the non-free gpu userland uses that to allocate memory, it would be safe to truncate the pointers
<clever> and there was talk of implementing the same flag in the aarch64 kernel
<clever> which forces the upper 32bits to be 0
<clever> x86 64bit has a MAP_32BIT flag in mmap
<clever> yeah
<clever> its not going to be happy when you stick a 64bit userland in the mix
<clever> LnL: and the gpu then returns those 32bit pointers back in events
<clever> LnL: a lot of the gpu accel stuff involves passing userland pointers to the gpu in 32bit fields as tokens
<clever> but it has 2 kernels, v6 and v7
<clever> the raspbian userland is always compiled in armv6, so it maintains compat with the rpi1
<clever> LnL: the pi3 is aarch64, but its also backwards compat to armv6 and armv7
<clever> 64bit x86 can do the same
<clever> i would expect it to be able to do that
<clever> contrapumpkin: v7 as well?
<clever> bennofs: your looking at all-packages.nix, but sphalerite mentioned python-packages.nix
<clever> sphalerite: i dont see a pkgs.sed in nixpkgs, but i do see a pkgs.gnused
<clever> copumpkin: yeah, i'm moving away from it as well, but it would take a while to redo the entire thing
<clever> let me get the full error
<clever> but 17.03 and unstable fail to even unpack my nodejs source
<clever> nice
<clever> copumpkin: i cant remember what i used, and i still need to make a systemd unit so it auto-runs
<clever> ah
<clever> i'm on 16.09
<clever> contrapumpkin: did that already get fixed in master?
<clever> contrapumpkin: oh, i have a patch ive been needing to apply to buildbot, it uses /usr/bin/tail to follow its own logs
<clever> shlevy: and then you can do simple int compares in the macro, to detect whatever you want
<clever> shlevy: i usualy see programs that have #define NIX_MAJOR 1, and #define NIX_MINOR 11 #define NIX_PATCH 7
<clever> xeviox: so it will use the old value of version
<clever> xeviox: the problem is that it evals the ${version} and ${name} before the overrides apply
<clever> xeviox: you need to override name and src, version has no effect on the build
<clever> but if you always want it from nixpkgs, <nixpkgs/pkgs/os-specific/linux/kernel/linux-4.10.nix>
<clever> johnw: the presense of "/tmp/nix-build-git-2.12.1337.drv-0" says its running as nix-build, probably as nixbld1
<clever> spacekitteh: does it show the "make install" arguments above that?
<clever> spacekitteh: double-check that your shell isnt part of the FHS stuff, try opening a whole new xterm
<clever> thats not right
<clever> and bash tends to not expand ~ after =, so you need to manualy type in your home folder
<clever> you want -I nixpkgs=~/nix-patches/nixpkgs
<clever> note the double nixpkgs
<clever> does ~/nix-patches/nixpkgs/nixpkgs/default.nix exist?
<clever> so when you import <nixpkgs> it tries to open ~/nix-patches/nixpkgs/nixpkgs/default.nix
<clever> your telling it to search inside ~/nix-patches/nixpkgs
<clever> i see the problem
<clever> oops, its pkgs.runCommand
<clever> spacekitteh: looks like its doing something, lets wait for it to finish and see what comes out
<clever> nice
<clever> that will override the defaults
<clever> you can also give nix-shell a path to a file
<clever> try "nix-shell -A env" with this variant of the file
<clever> spacekitteh: do you want to manualy build that new git, or let nix build it, and provide a git command in $PATH?
<clever> for this command
<clever> nix-shell -A myGit
<clever> can you pastebin the output of running nix-shell and the prompt that came up?
<clever> spacekitteh: and -p wont work at all
<clever> spacekitteh: "nix-shell" and "nix-shell -A myGit" will give you an env for building that git, so you have to run configurePhase and buildPhase
<clever> spacekitteh: and what nix command did you run?
<clever> can you gist the command you used and the nix expressions its referencing?
<clever> spacekitteh: and how do you want to use that custom git?
<clever> spacekitteh: what have you tried?

2017-03-07

<clever> or man pags
<clever> nor where i found the info, i probably just googled it
<clever> i used it years ago, but cant remember anything about it right now
<clever> gchristensen: and due to how tmux was configured, $NIXOS_CONFIG didnt exist in half his shells, so it worked half the time, then just didnt obey the commands
<clever> gchristensen: and related, $NIXPKGS_CONFIG has higher priority then both files, and i ran into a problem with smw_ a few days ago, where $NIXOS_CONFIG was making it ignore -I nixos-config
<clever> so now you have to play a guessing game every time you help somebody
<clever> and if you give people the new path, it will either not work (nixpkgs too old), or it will break their existing config.nix
<clever> if you keep giving people the old path, it will randomly break like this
<clever> gchristensen: i had a feeling this would happen 3 days ago when i learned of the change
<clever> yeah
<clever> the new ~/.config/nixpkgs/config.nix path takes priority over the old ~/.nixpkgs/config.nix
<clever> oh
<clever> samae: what command are you running that is giving an error?
<clever> samae: does ~/.config/nixpkgs/config.nix exist?
<clever> nice
<clever> smw_: though it probably cant use the gpu decode accel if you are on linux_latest
<clever> you would also loose that much ram
<clever> smw_: the initrd will be 200-300mb in side, but it wont need to mount a rootfs
<clever> smw_: but with a few tweaks, you could put a squashfs of the root inside the initrd
<clever> smw_: this display case was running with a normal r/w rootfs, and the guys at the store just cut power every night, until it corrupted the fs
<clever> smw_: that will build the kernel .config file for that nix expression
<clever> smw_: nix-build nixos/default.nix -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix -A config.boot.kernelPackages.kernel.configfile