2017-01-12

<clever> alphor: main limitation with that method is that you cant nixos-rebuild switch, just shutdown and re-run nix-build, then boot it back up
<clever> alphor: ive used this on both nixos and gentoo systems to test a basic nixos configuration out without having to setup a proper vm
<clever> alphor: this will build a bash script that runs a build of nixos under qemu
<clever> alphor: nix-build '<nixpkgs/nixos>' -A vm -I nixos-config=./configuration.nix
<clever> alphor: another fun thing you can do on any distro
<clever> so it depends on preference somewhat
<clever> full nixos has a bit of a steeper learning curve and forces you to learn everything at once, while nix on debian lets you cheat and just apt-get things and learn the right way later
<clever> and configures some base stuff like an ssh pubkey, so you can get back into the box
<clever> my kexec script takes the kernel+initrd from a netboot module in nixos, and just runs it via kexec instead
<clever> it is now running entirely from ram, so you can repartition the disk however you want
<clever> so you can basicaly boot the installer CD, without any usb stick or cd drive
<clever> MichaelRaskin: and if you run that, it will kexec the host into that kernel, which includes a full nixos inside the initrd
<clever> MichaelRaskin: if you build this, you get a bash script that references a kernel+initrd
<clever> MichaelRaskin: i have also messed with kexec some, one sec
<clever> MichaelRaskin: yeah, it depends on what your goals are
<clever> MichaelRaskin: and in 2 cases, i just ran ./result/bin/switch-to-configuration boot to force nixos to overwrite the gentoo MBR and take over the same rootfs
<clever> MichaelRaskin: i have done similar stuff to https://nixos.org/wiki/Install_NixOS_on_Linode to get nixos-install on a gentoo machine and installed against a USB stick
<clever> yeah
<clever> you can write to the dir you already have write to instead
<clever> no need to get root to make a new dir for you
<clever> that sounds better
<clever> sheenobu: i believe nix will recursively search the gcroots directory, to find all roots
<clever> lrwxrwxrwx 1 clever clever 21 Oct 8 2015 /nix/var/nix/gcroots/profiles -> /nix/var/nix/profiles
<clever> so you can do that without having root
<clever> and you typicaly have +w to the directory named after your user
<clever> sheenobu: so the profiles are all kept in an area where the GC finds roots
<clever> sheenobu: thats why i used -p /nix/var/nix/profiles/per-user/root/rpi3-netboot in my netboot setup
<clever> sheenobu: nix-env handles that by symlinking ~/.nix-profile to the name of the profile under /nix/var/nix/profiles/
<clever> sheenobu: oh right, and if you dont keep the generations in an area like /nix/var/nix/profiles/, they might get eaten by garbage collection

2017-01-11

<clever> id think it can only be done if the git repo is on github
<clever> similar rules also apply if you -A foo, but it returned { foo.bar = derivation; }
<clever> yeah, if the default.nix returns a single derivation, or an attrset containing primites, and one derivation, it just picks the derivation directly
<clever> sheenobu: that will build the an_attribute attr from the given default.nix, and then use the result as the root of the generation
<clever> sheenobu: nix-env -p $HOME/.nix-home -f /path/to/something/default.nix -A an_attribute --set
<clever> pxc: the xeon router is also running a full hydra install, but i have had issues where the UPS barely lasts 10minutes, then i loose all internet
<clever> pxc: and my internet speeds go way over 100mbit
<clever> pxc: all of my current arm machines are 100mbit ethernet, running over usb
<clever> model name : Intel(R) Xeon(TM) CPU 3.20GHz
<clever> pxc: a random server that came out of a rack, dual-socket motherboard, 3gig of ecc ram, 3 gigabit ethernet ports
<clever> pxc: yep
<clever> sheenobu: nixos-rebuild also uses --set in the same way
<clever> sheenobu: it will entirely replace the contents
<clever> sheenobu: and in my case, i'm using --set, so nix-env will never use buildEnv to imperatively merge the new stuff with the old generation
<clever> [root@router:/tftproot/try2]# nix-env -p /nix/var/nix/profiles/per-user/root/rpi3-netboot -f not-os/release.nix -A rpi_image -I nixpkgs=./nixpkgs/ --set
<clever> sheenobu: i recently also used nix-env for network boot images, one min
<clever> yeah
<clever> deleting a generation after rollback would prevent that
<clever> once for each time i --update'd and --rollback'd in the past
<clever> sheenobu: i ran into this issue on my router, nix-channel --update has broken it a few times, and now i have to --rollback 3 or 4 times to undo a single --update
<clever> so rollback goes to the generation before the current, not the one it was just on
<clever> pxc: but if i then do a second update+rollback, it creates 6, then switches back to 5
<clever> pxc: one issue i have found, is that if say i'm generation #4, and i do an update+rollback, i create a 5, then switch back to 4
<clever> so all you can see is the latest commit in each channel
<clever> Ptival: but those commits are currently not logged: https://github.com/NixOS/nixos-channel-scripts/issues/10
<clever> Ptival: any commit that has been in a non-small channel should have everything in the cache
<clever> evangeline: you can manauly try loading kvm-intel, and then check dmesg for the error
<clever> evangeline: that only affects its presense within a nix-build sandbox
<clever> it could be used by tools like nix-prefetch-git possibly
<clever> dont know, i havent seen it do that before
<clever> no
<clever> which will only exist on a nixos machine
<clever> when i strace locale, i can see that its checking in this directory
<clever> open("/run/current-system/sw/lib/locale/locale-archive", O_RDONLY) = 3
<clever> nix-env -iA nixpkgs.glibc.bin
<clever> siarheit_: locale is in glibc.bin, not glibc's top-level package
<clever> but libraries need to go into nix-shell -p
<clever> tools you want to run from $PATH, you can just install
<clever> siarheit_: the gcc used by nix doesnt look in the profile managed by nix-env, so things you nix-env -i wont help it any
<clever> siarheit_: your not supposed to install libraries like glibc, only use them under nix-shell
<clever> though i try to keep the result symlink and build dir one up
<clever> you can also exclude .git and any .o files youve built via nix-shell
<clever> sphalerite: builtins.elem maybe
<clever> and i can see how they may miss it under qemu, the default ram is 128mb, but the failure is at 257mb
<clever> gchristensen: there are hardening flags on memtest already, but it appears that somebody didnt test it fully enough
<clever> gchristensen: but its in the middle of a mass-rebuild
<clever> gchristensen: i have narrowed the problem down to what i believe was the hardening overhaul of nixpkgs
<clever> thats only a temporary fix, it will change back to root.root next time it mounts
<clever> jarlg: what group owns the mount point?
<clever> mrkgnao: you need to open a shell with freetype using nix-shell -p freetype
<clever> mrkgnao: nixos will never search for libraries in the list managed by nix-env
<clever> and the plastic was in the way enough that it didnt seat properly, and wasnt even appearing in the os
<clever> it just wasnt the right snap :P
<clever> i pushed the gpu in until i heard a snap
<clever> they made it a sliding lock, not the normal one that bends to the side and snaps in place
<clever> unlmtd[m]: i did break a pcie-16x locking tab, lol
<clever> yeah
<clever> i spent 6 hours shuffling hardware trying to fix a problem that didnt exist
<clever> gchristensen: memtest86+ on nixos unstable is broken, it gives false errors
<clever> gchristensen: http://imgur.com/a/uiacx
<clever> oops
<clever> gchristensen: Bisecting: 17291 revisions left to test after this (roughly 14 steps)
<clever> they also have bad ram
<clever> then on a random guess, i memtest'd 2 laptops
<clever> i put the nas ram back into the nas, and ran memtest, still toast
<clever> still bad!
<clever> so i put the 16gig of ram and the ssd's into the nas, and ram memtest
<clever> motherboard maybe?
<clever> i stole the ram from my NAS, thats also bad!
<clever> i swapped the sticks around to try and figure out which was good and bad, it said both where toast
<clever> gchristensen: memtest86 said the ram in my desktop was bad
<clever> gchristensen: guess what i spent 6 hours on last night? lol
<clever> lambdame: your supposed to just use "nix-shell -p gcc"
<clever> things like binutils and gcc aremt meant to be installed on nixos

2017-01-10

<clever> leothrix: i believe you want systemd.services.foo.serviceConfig.ExecStart = lib.mkForce "bar"; if you want to bypass nixos's attempt at merging multiple definitions
<clever> jp302: use pkgs.fetchurl
<clever> sphalerite: and if xsession exists, all control is transfered to that and this script stops being an issue
<clever> sphalerite: because xprofile gets sourced and the script continues, the user can inject variables into this context, and alter how the script behaves
<clever> sphalerite: you can also use xprofile (line 98) or xsession (line 103) to imperatively override things for testing
<clever> sphalerite: and 128-134 is about where it runs it
<clever> sphalerite: line 112-115 is where it decides between the default, and the one chosen in the display manager

2017-01-09

<clever> sphalerite: this script gets ran by the display manager after it has set the uid correctly, and it is ready to launch the chosen desktop manager
<clever> sphalerite: the last time i debugged xorg heavily, it was common to just mmap /dev/mem directly
<clever> sphalerite: something in the activation scripts sets that up on boot
<clever> sphalerite: i think the bigger issue, is that systemd doesnt allow it
<clever> sphalerite: setuid does work on nixos, see sudo and su (run type su on a nixos box)
<clever> sphalerite: bbl
<clever> sphalerite: i should probably use branches more when i know things are going to break
<clever> sphalerite: need to finish that as well
<clever> sphalerite: latest one is when i added a bunch of half-finished stuff to allow nix-daemon on an rpi
<clever> ertes: i think the reason, is that the pager hasnt read all input, and nix-env is blocking on a write, in the middle of iterating the data
<clever> sphalerite: nixpkgs c9d1d430ec34d667ce9d0b86f843801d1cf3b753 is the last one to pass tests, i'll fix it when i get a chance
<clever> sphalerite: all x86 jobs vanished on dec 22nd
<clever> sphalerite: ah i see, a recent change in unstable broke it
<clever> sphalerite: and you will probably want some -A, maybe -A runner
<clever> sphalerite: warning: Nix search path entry ‘/root/nixpkgs-channels’ does not exist, ignoring
<clever> sphalerite: ive only been testing it on nixos-unstable, try that first
<clever> eacameron: TMPDIR, TEMP, TMP, and TEMPDIR all point to the dir for the build, which nix will clean up when things are done
<clever> ah, havent seen that one
<clever> guacamole_: if you have enough ram to dedicate to each guest, yeah
<clever> bluetooth or usb otg can solve that
<clever> surprisingly useable, though the keyboard can be an issue
<clever> yep
<clever> often, its been easyer to just run the android app on a cellphone
<clever> i have to vnc into a windows 7 vm running under xen, with vnc running over a custom vpn
<clever> same
<clever> guacamole_: and the new version lacks a connect button!
<clever> guacamole_: yeah, teamviewer has been very bad at this, i fixed teamviewer client on nixos a few months ago, then they updated it, old version stops working entirely (not permited)
<clever> guacamole_: one tip, nix doesnt delete the invalid .tar.gz file, so you can just open it in less and see whats going on
<clever> guacamole_: half of the time, that changing hash is caused by a 404 page with the current time in it

2017-01-08

<clever> ToxicFrog: and i'm over in NB
<clever> living room: 17.56c(63.61f), outdoor: -12.25c(9.95f), server: 21.38c(70.47f)

2017-01-07

<clever> and now python is a dep, that never appears in the users profile
<clever> so it knows exactly which build of python to use
<clever> eacameron: which is why its recomended to always do #!/nix/store/foo-python-2.6/bin/python
<clever> a storepath can never exist without its deps
<clever> nix-store -r downloads all dependencies
<clever> eacameron: just skip nix-shell, since you know you only need the bin in path
<clever> eacameron: it might be simpler to just prepend /nix/store/foo/bin to $PATH then
<clever> that downloads without putting it into your profile
<clever> try with nix-store -r instead
<clever> though it probably wont download then, nix-store -r /nix/store/foo first to dl
<clever> so maybe nix-shell -p '"/nix/store/foo"'
<clever> eacameron: the arguments to -p just wind up inside the buildInputs array of a nix expression
<clever> eacameron: hmmm, not sure, maybe if you quote it weirdly

2017-01-06

<clever> that*
<clever> but if thay support was extended to nix itself, you could then add a 2nd file, not managed by nix, and go nuts
<clever> currently, only hydra supports a : seperated list in NIX_REMOTE_SYSTEMS
<clever> and i could just plug another 20 in without having to touch any config
<clever> then hydra will dynamicaly gain/loose slaves as they turn on/off
<clever> and if one of them stops responding, remove it
<clever> copumpkin: i was planning on having a daemon within my hydra box, that would listen for new rpi's booting up, and add them to machines.provisioned
<clever> copumpkin: hydra supports a : seperated list of /etc/nix/machines files (the config option is better in more recent modules)
<clever> extraEnv.NIX_REMOTE_SYSTEMS = lib.concatStringsSep ":" [ "/etc/nix/machines" "/etc/nix/machines.provisioned" ];
<clever> copumpkin: oh, that reminds me of something else i was planning, reguarding the self-healing of k8s
<clever> yeah
<clever> but just mkswap on boot would allow it to dynamicaly recover from any changes to the hdd
<clever> but then you run the risk of it eating every hdd you boot it on
<clever> so nobody can ever extract things after it has died
<clever> you could potentialy even program it to random luks the hdd, and mkswap it every time it boots
<clever> so the hdd could be 100% swap
<clever> and the os never has to exist on the guest hdd
<clever> copumpkin: if your using qemu or xen, you can just pass it the kernel/initrd paths relative to the host
<clever> but then you need some way to update the files remotely, or use your vm framework
<clever> copumpkin: you could skip a lot of the network stuff, and just have a /boot folder with grub, kernel, and initrd
<clever> but ive since branched out and just added random ideas to it, while keeping it minimal
<clever> and they would be operating potentialy without internet access
<clever> copumpkin: was originaly making this for a system that had ~8 servers working together as a unit, and i was thinking that 1 of them could serve the other 7
<clever> copumpkin: and lines 66-73 are the default script embeded into the binary, it cant change as easily, but it just fetches a bigger script, which must be signed
<clever> copumpkin: line 80 of ipxe.nix makes a special build of ipxe, that embeds the public certs into it, along with a default script, so it doesnt run untrusted code by default
<clever> the requester (hydra) will send over a build of curl/git for the target machine, and then that does the download
<clever> copumpkin: like 56-62 handles signing the files, but that cant safely be done inside nix-build, since the private key is now in /nix/store
<clever> and ipxe has support to dynamicaly append to the initrd for you
<clever> copumpkin: this downloads the kernel, initrd, and rootfs over tftp, then verifies signatures on each, public/private keypair crypto
<clever> copumpkin: ive covered that as well in the past
<clever> then you dont need dhcp support in the initrd
<clever> copumpkin: the same could be done with not-os's initrd, to embed the squashfs right into it
<clever> copumpkin: this section takes the standard nixos initrd (havent tried that one on not-os) and appends the rootfs file to it
<clever> copumpkin: when embeded, it will take a lot longer for it to download the initrd and even start linux, but it can just boot without an extra step in the initrd
<clever> copumpkin: but you can also embed the root image into the squashfs
<clever> copumpkin: and currently, the initrd downloads the root.squashfs over tftp after booting: https://github.com/cleverca22/not-os/blob/master/stage-1.nix#L141
<clever> copumpkin: the rpi them tftp'd its firmware from this dir, then the kernel+initrd, and booted
<clever> copumpkin: this command was building the entire not-os image, including the raspberry pi firmware, and sticking it in a directory named after the rpi serial#
<clever> [root@router:/tftproot/try2]# time nix-build -j4 not-os/release.nix -A rpi_image -o ../9080d9b6 --show-trace -I nixpkgs=/tftproot/try2/nixpkgs/ && ls -ltrhL ../9080d9b6/
<clever> copumpkin: let me grab the command i was using for testing a few weeks ago
<clever> only issue is the purity problems in darwin, how it needs some things in /System that arent open i think
<clever> copumpkin: a similar design on the xnu kernel would massively help expand the darwin build farm
<clever> yeah
<clever> copumpkin: its using the unmodified nixos kernel, so it should
<clever> remote builds via /etc/nix/machines or hydra will automaticaly nix-copy-closure --from it out when the build is done
<clever> a tmpfs, and potentialy swap
<clever> copumpkin: its running entirely from a squashfs in ram, and has the nix sandbox enabled
<clever> copumpkin: yep, i recently modified it to do exactly that on one of my raspberry pi's
<clever> copumpkin: https://github.com/cleverca22
<clever> copumpkin: heh, just sat down at the pc!
<clever> which just sets hardware.{opengl.driSupport32Bit,pulseaudio.support32Bit} and inserts steam into systemPackages
<clever> ToxicFrog: it would be trivial to make a programs.steam.enable = true; option for configuration.nix

2017-01-05

<clever> eacameron: the latest "stable" version should be in nixpkgs
<clever> eacameron: it should be in nixpkgs as well
<clever> eacameron: either a tar with the nix files, or a checkout of the nix expressions from github
<clever> and if you used a version hydra has previously built, it will be in the cache
<clever> then nix will eval it against the current arch, and compute that storepath
<clever> use the nix expression
<clever> eacameron: http://hydra.nixos.org/jobset/nixops/master#tabs-jobs grab the build for the arch you want, and whcih version you want, then grab its path from the info tab
<clever> eacameron: it says x86_64-darwin in the job name, so its a mac only build
<clever> eacameron: that path is specific to the build you linked
<clever> eacameron: i'm guessing some of it comes from donations: https://nixos.org/nixos/community.html
<clever> and previously, hydra had to upload an entire ~80gig closure (all of nixpkgs builsd) to cache.nixos.org when a channel updates
<clever> the hdd on hydra was slowing down importing builds from slaves
<clever> that change solves 2 major bottlenecks
<clever> it streams them directly to cache.nixos.org
<clever> hydra no longer keeps any of the outputs it builds
<clever> that will download the given path to /nix/store from the cache
<clever> recent-ish, it was maybe 5+ months ago?
<clever> eacameron: just do "nix-store -r /nix/store/8pqsibn4mgjfl4qm5gq8wyz94wpg1l2y-nixops-1.5pre2118_2d8b282"
<clever> eacameron: the recent S3 changes broke that

2017-01-03

<clever> yeah
<clever> and expiry on the cache would be more important if that happens
<clever> gchristensen: priority could be set on the PR stuff to run less often
<clever> gchristensen: so when i added new perl files, git didnt know of them, and they got nuked
<clever> by git*
<clever> gchristensen: biggest road-block i had when editing the perl, is that the build scripts nuke anything not tracked byt
<clever> rly: last i heard, somebody said it would take another year of work to get that hydra stuff going
<clever> replacing travis with hydra would solve a number of problems
<clever> gchristensen: and dont contribute back to the cache
<clever> gchristensen: one anoyance with the travis stuff, any mass-rebuild related products cant be shared between PR's

2017-01-02

<clever> i need to get that build farm stabalized
<clever> berce: http://hydra.earthtools.ca/machines gcc has been restarted, with any luck you may see it building xorg in a day or 2, lol
<clever> ah, its still having trouble bootstrapping gcc
<clever> let me check my hydra and see what its doing
<clever> then either make a PR or refine the override
<clever> its sometimes faster to edit a copy of nixpkgs
<clever> all on armv6
<clever> berce: i did have slim + xterm working on the raspberry pi at one point
<clever> xorg*
<clever> dont see arm changes in this checkout
<clever> its an old checkout from when i was doing arm stuff, didnt commit any of it
<clever> let me check a git diff
<clever> berce: oh that part, i think i just edited the default.nix for xorg
<clever> berce: i just changed services.xserver.videoDrivers i think
<clever> gchristensen: somebody just blanket set types on everything, and they broke the kexec option
<clever> gchristensen: ive also been meaning to file a PR for https://github.com/NixOS/nixpkgs/issues/20796#issue-192336611
<clever> gchristensen: yep
<clever> gchristensen: pong

2016-12-30

<clever> i would just do "git checkout" in the nixpkgs dir as normal, and then switch it back to master when your done
<clever> so now the state i .git os "corrupt", and your lacking the files that matched up
<clever> sphalerite: ah, i think i know what happened, 'git checkout' knows what the state of files is (via .git state), and only checked out files that differ between the current state, and nixos-unstable
<clever> there are 2 branches with the same name, and different uses
<clever> also, you want the nixos-unstable branch of nixpkgs-channels, not from nixpkgs
<clever> sounds like it didnt get everything
<clever> i saw an issue with some talk on it, cant remember which one it was
<clever> what files did it make?
<clever> with -I nixpkgs will cover both lines 5 and 6 at once, so you cant miss one of them
<clever> or build it with -I nixpkgs=/path/to/nixos-unstable
<clever> sphalerite: you can always switch nix-channel back to release after it netboots, if you wish to install release into the target machine
<clever> sphalerite: i fixed the store being read-only, but that fix has only made it into nixos-unstable
<clever> sphalerite: are you using nixos release or unstable?
<clever> all 916 of those where normal chrome tabs just 10mins ago
<clever> and swap usage is down to 16%
<clever> 916, down to just 2 open windows
<clever> 817...
<clever> "one tab" has now converted 694 normal chrome tabs over
<clever> yes
<clever> 600
<clever> its up to 577 now
<clever> thats about half of them
<clever> eacameron: and now that it has stabalized, i have moved 443 tabs into the "one tab"
<clever> its a part of nix, that applies even if your not using nixos or nixpkgs
<clever> probably in the nix manual is my guess
<clever> its been at 100% for the past 20 minutes
<clever> still at 100% cpu usage
<clever> up to 70% swap usage!
<clever> id need 30 or 40gig of ram to stop it from swapping
<clever> yeah, chrome burns thru it so fast