<clever>
but that only works if both sets of drivers are in the same fork of linux
<clever>
in theory, i could make a kernel that has both the rpi gpu stuff, and the Cubox stuff compiled in, and the DT tells it which one to fire up, and what address the hardware is at
<clever>
the idea behind DT, is that you could have 1 kernel that works on many boards, and the DT tells it what hardware is available
<clever>
yep
<clever>
berce: pkgs.dtc contains the utils to convert between text<->blob
<clever>
they shouldnt be, but some kernel driver guys are naughty
<clever>
nix-shell -p ghc --pure
<clever>
rly: the nixos or nixpkgs in -iA nixos.ghc is the name of a channel from nix-channel --list
<clever>
sphalerite: nox-review?
<clever>
maybe run one nix-shell inside the other nix-shell?
<clever>
except, that will put it inside itself, and now it has a infinite cycle
<clever>
Cypi: normaly id say to put foo into the buildInputs with an override
<clever>
Cypi: you gave it conflicting options, so i'm not sure what its going to do
<clever>
Cypi: and you cant mix -E and -A
<clever>
Cypi: -p just makes it run -E 'with import <nixpkgs> {}; runCommand "foo" { buildInputs = [ somepackage ]; } ""'
2016-12-13
<clever>
digitalmentat: double-check to see if you have a 2nd /boot filesystem thats not mounted?
<clever>
digitalmentat: is /boot mounted correctly?
<clever>
but -delete saves a couple processes
<clever>
it seperates the files with \0
<clever>
and that xargs command would have failed if there was spaces in the path, i always use find -print0 | xargs -0 to fix that
<clever>
so you dont need xargs there
<clever>
eacameron: oh, and find has a -delete
<clever>
eacameron: also, you dont need to inherit src;, you can also cp -r ${src}/* $out/ as another way of doing it
<clever>
eacameron: yeah
<clever>
cant*
<clever>
eacameron: which means you cany add things to it on line 34 until you +w it
<clever>
eacameron: the $out/craft you copied came from the nix store, so its read-only
<clever>
gchristensen: a basic QX app with 1 button compiles down to 739kb, including the images for its themes
<clever>
goibhniu: possibly
<clever>
i did some pretty crazy things against that codebase, without server access
<clever>
but unminified, you can track down the leaks and make it run great
<clever>
the minification got in the way of me fixing that
<clever>
the game i saw it used on, didnt, and leaked memory like nuts
<clever>
so you must delete things when your done with them
<clever>
gchristensen: and it has a minor problem, they implement c++ destructors, on javascript objects, and to do that, all objects are kept in a global array
<clever>
similar to the gcc linker just deleting unused code
<clever>
it will dynamicaly inspect the code to see which classes you use
<clever>
this is a fairly flexible framework
<clever>
that was after all of the game logic was added
<clever>
gchristensen: yeah, i have previously played a game that used this framework, it was a solid 6mb of javascript after minification
<clever>
it even has a window manager, check the window tab
<clever>
gchristensen: between the imgur and the last link, which would you prefer?
<clever>
jazzencat: the problem has nothing to do with nixos, its because you used GPT and skipped the bios boot partition
<clever>
jazzencat: i said that you need a dedicated bios boot partition
<clever>
/nix/store/0pfy69722ghxdbfnyfsv9arhbgz09ala-grub-2.x-2015-11-16/sbin/grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
<clever>
jazzencat: most of the log isnt saved, it just goes to stdout
<clever>
nixos will concat each instance of systemPackages for you
<clever>
ixxie: and then add both of those to imports
<clever>
ixxie: yet another option, make 2 modules, one with envionment.systemPackages = with eclipses; [ eclipse-platform eclipse-scala-sdk-40 ];, one with the other
<clever>
ixxie: you can also do with eclipses; with pkgs; [ eclipse-platform eclipse-scala-sdk-40 other stuff ];
<clever>
jazzencat: i think ef02 is the bios boot partition, that is for booting GPT drives on non-efi machines
<clever>
without that, an MBR only tool may think its a blank disk, and will offer to format it
<clever>
so tools that cant handle gpt will still say the disk has something
<clever>
in addition to gpt tables, it has an MBR table claiming the entire disk is in use
<clever>
i have gpt on all of my recent non-efi systems
<clever>
gpt on its own isnt an indicator of the firmware support
<clever>
eacameron: they should be identical as far as nix is concerned
<clever>
eacameron: looks like .git* was removed, and 2 files where added so nixpkgs knows which commit it came from
<clever>
jazzencat: boot.loader.grub.efiInstallAsRemovable = true; lets you skip the last requirement, to modify the firmware variables
<clever>
jazzencat: for EFI to work correctly, the boot partition must be fat32, with the right type, on GPT, and the path to the bootloader has to be set in a firmware variable
<clever>
eacameron: and diff -r them
<clever>
eacameron: try fetching the url that works, and the url that doesnt, then unpack both to different directories
<clever>
to do the same thing every time, even if wiped and reinstalled
<clever>
yep, thats the goal of nix
<clever>
and i confirmed the commit in that url is the latest nixpkgs-unstable
<clever>
eacameron: looks like it should be valid, assuming that file now exists
<clever>
eacameron: what is it set to on your end?
<clever>
/etc/ssl/certs/ca-certificates.crt
<clever>
clever@c2d ~ $ echo $SSL_CERT_FILE
<clever>
nekroze: you will need to import it, call it with an IP, then put the resulting value into the imports list
<clever>
eacameron: the nixpkgs-unstable builds for x86 and mac
<clever>
gchristensen: the funny part, is that gdb confirms its correct, fairly deep inside the QT library, but it messes up at the last step, as it leaves QT
<clever>
lol
<clever>
gchristensen: and c++ strikes again, one of my pointers is just magicaly turning into 0xcc0000002 after passing thru a few functions
<clever>
i havent gotten around to re-opening it
<clever>
chrome segfaulted when i ran out of disk space a few days ago (nix-build and 400mb tars)
<clever>
gchristensen: that might be enough ram for me to open chrome without it crashing
<clever>
in theory, i could rip the bloody ram off the mobo and it wont crash....
<clever>
the entire root filesystem could fit on the L4 cache!!
<clever>
gchristensen: and as a random example, i have a not-os image that has a 40mb squashfs, and can function as a nix build slave
<clever>
gchristensen: its insane, because i used to run servers with only 64mb of ram
<clever>
gchristensen: but if the gpu isnt active, then the cpu will benefit from that L4 cache
<clever>
gchristensen: taktoa's laptop has a GPU on the cpu, including the gpu memory, as 128mb? of L4 cache
<clever>
gchristensen: they didnt multiplex the video output, they made a framebuffer-less 3d GPU, that renders into the framebuffer memory of a weaker 2d GPU
<clever>
gchristensen: i have heard of a non-apply vendor that did 2 GPU's in a laptop
<clever>
gchristensen: even then, wait until the user is trying to recover it before you bring the wifi up
<clever>
gchristensen: why is the wifi even active that early in the boot??
<clever>
a systemd unit could automate that
<clever>
all you have to do with that one, is ssh in and run justdoit
<clever>
gchristensen: this is also reminding me of how some malware and c&c servers work, the kexec tar could join an irc channel
<clever>
and then you can monitor its comign back on via that
<clever>
gchristensen: so on bootup, it sends an http request out to a server
<clever>
gchristensen: one thing ive thought of, is to add some signaling, thru a 3rd party
<clever>
gchristensen: looks pretty simple :)
<clever>
gchristensen: nice
<clever>
for nix
<clever>
and emacs doesnt actualy have an AST
<clever>
causing it to get stuck in a feedback loop and grow to infinite size
<clever>
but most of the projects for that have a dynamicaly sized terminal emulator, and try to make it longer when you render at the bottom
<clever>
i also looked into options like running a tty over a websocket, so you could jusr run a "real" editor like emacs on the server, and have it render in the browser
<clever>
so people can reuse the same code nix used, and there is no need to keep the AST stuff in sync
<clever>
the idea from nixexpr, is to seperate the AST and the AST->expression stuff into 2 parts, and make nixexpr the main parser in nix
<clever>
domenkozar: with just the addition of a systemd unit, it could automaticaly install a base nixos to the hdd, and reboot into it, leaving you a bare system for nixops to target
<clever>
which also means, you dont need physical access
<clever>
yeah
<clever>
my kexec idea runs entirely from a ramdisk, so the hdd can be umount'd and fully partitioned
<clever>
domenkozar: then nixops can upload that tar, and repartition the drive, and install nixos, in a fully automated manner
<clever>
domenkozar: in theory, if you have a server with a linux kernel that has kexec enabled, the hoster obeys the MBR, and you have root
<clever>
domenkozar: in the current form, you just upload a tar to a server, put some ssh public keys in /ssh_pubkey, unpack the tar to /, and run /kexec_nixos as root, and it will behave like it had booted from the ISO
<clever>
yep
<clever>
and the nixos is the name of a channel from the defexpr, so it has to be dropped in nix-build
<clever>
nix-build needs a path given, like '<nixpkgs>'
<clever>
AtnNn: nix-env loads a default expression from ~/.nix-defexpr/