<clever>
so i would have to plug both machines directly into a router
<clever>
also, my existing wifi from the ISP doesnt even allow wifi clients to talk to wired clients
<clever>
so you can only access the router, and no other machine on the LAN
<clever>
and then there are more hostile networks, that actualy protect you from the guy next to you
<clever>
:D
<clever>
and then how do i ensure the client can use the host as a binary cache?, when i dont know what ip it will be on the network?
<clever>
the 2nd request from ipxe may not be as choosy
<clever>
but its more messy, and that only works for the first request from the bios
<clever>
yeah, ive done that as well
<clever>
ArdaXi[m]: i need to control the dhcp server to catch netboot requests
<clever>
ArdaXi[m]: just connect the 2 laptops with a cat5, run "justdoit", and the entire install is done
<clever>
ArdaXi[m]: but i have a new laptop on-route, and i'll be away from home when i get it, so having the entire system contained within the old laptop helps
<clever>
ArdaXi[m]: my old netboot setup is spread over 2 or 3 machines, gentoo runs the tftp, nixos runs the dhcp+bind, gentoo runs the apache
<clever>
ArdaXi[m]: it also puts justdoit into the resulting netboot image, so typing "justdoit" into the shell will do the entire install, insta-nuking whatever OS was in the way
<clever>
ArdaXi[m]: and sets up NAT between the wifi and ethernet, so the laptop becomes a router
<clever>
ArdaXi[m]: this does the full iPXE setup on my laptop, serving it over the ethernet jack
<clever>
TweyII: qt does a lot of things, some similar to what cmake does
<clever>
TweyII: cmake will hijack the configure phase to use cmake
<clever>
TweyII: unzip will mutate the unpack handler, so it can unpack zips
<clever>
TweyII: pkg-config will mutate the function that iterates over buildInputs, so every input winds up in the pkgconfig search path
<clever>
TweyII: the hooks for a/b/c will get sourced as d starts the build, and then d can also optionally define its own hook, for things that depend on d
<clever>
TweyII: if a derivation sets $setupHook, the stdenv setup.sh will copy that file to $out/nix-support/setup-hook and apply substituteAll so things like @out@ get replaced with $out
<clever>
TweyII: so they are free to modify the env vars and functions of the stdenv
<clever>
TweyII: a setup hook is simply sourced when going thru the list of buildInputs
<clever>
sphalerite: just keep in mind that while the total memory can go a lot higher, each process is limited to 3gig
<clever>
sphalerite: i cant see why not
<clever>
it might be slightly broken, try "mkdir -pv kernel/x86/microcode" then re-run cpio
<clever>
what output did cpio give?
<clever>
so run it within a new empty one
<clever>
and it unpacks to the current dir
2017-10-23
<clever>
joko: you would either checkout a nixpkgs you like from git, or double-check that you like where the channel is, then point -I nixpkgs= at that, and then it will persist until overriden again
<clever>
joko: and if you did change that, nixos-rebuild -I nixpkgs=/foo switch, would "temporarily" override it, but change what is "current", so it then sticks
<clever>
joko: in this case, 56 refers to a fixed-output derivation, but you can also just refer to ${<nixpkgs>} which will indirectly refer to the current nixos's nixpkgs
<clever>
joko: at this point, nix-build, nixos-rebuild, and nix-shell will always use that copy, and never look at the channels
<clever>
joko: line 48 then sets NIX_PATH to use that
<clever>
joko: line 56 bakes a given nixpkgs into the system, which will appear at /run/current-system/nixpkgs at runtime
<clever>
how big is a pointer? i wont tell you which cpu, you must give the right answer for every platform!
<clever>
sphalerite: llvm will bake the wrong struct into that bitcode
<clever>
sphalerite: for example, one of the structs passed to signal handlers, contains various cpu registers at the time of the signal, so segfault can be handled right
<clever>
sphalerite: there is still the problem that llvm and the project your building, needs to know what structs and such to build against
<clever>
kuznero: i would just do meta.platforms = [ "x86_64-darwin" "x86_64-linux" ]
<clever>
sphalerite: i dont know of any way to fix that right now
<clever>
sphalerite: but now the arm is incapable of building anything for itself, and must force jobs out to an x86 to get anything done
<clever>
sphalerite: you can sorta fix that, by using config.nix to force everything to be cross-compiled
<clever>
and then it takes 24 hours to build hello-world
<clever>
it will eval it in native mode, and want a glibc + gcc that where built natively
<clever>
then i boot it up, and nix-env -iA nixos.hello
<clever>
sphalerite: if i build the entire nixos image with a cross-compiler
<clever>
sphalerite: the main issue there, is that the purity of nix doesnt really play nicely with that
<clever>
yeah, it should see its already in the store and just use that
<clever>
depending on if $src was fetched with the arm curl or the x86 curl
<clever>
you have 2 different ways of building the same $out
<clever>
sphalerite: but the $out hash is
<clever>
sphalerite: so the .drv hash isnt protected against changes in curl that fixed-output gives
<clever>
sphalerite: the fixed-output derivations refer to the curl nix was built against
<clever>
kuznero: so when a linux util scans, it can detect that it is still supported on darwin
<clever>
kuznero: and in each version, make sure to set meta.platforms to cover both i think
<clever>
in if (stdenv.system == "x86_64-linux") then linux64 else mac64
<clever>
kuznero: for example, put both derivations into a let block, followed by
<clever>
kuznero: id put an if statement in the file, to select between 2 derivations
<clever>
kuznero: OSX doesnt let you change the interpreter, and the rpath goes by a slightly different name
<clever>
sphalerite: with the older nix thats in 16.09, all binary cache stuff is handled by perl scripts
<clever>
with nixUnstable, all binary caches are handled directly in c++ within nix, and local?root=/mnt handles this type of store
<clever>
that is what local?root=/mnt replaced
<clever>
sphalerite: this allows the nix inside the chroot to treat a bind mounted store as a binary cache
<clever>
sphalerite: there is also another thing, let me find it
<clever>
and with those entries removed, it fails to find them
<clever>
kuznero: and the --shrink-rpath on line 18 cant detect that, so it removes things you just put into the rpath
<clever>
kuznero: the problem, is that dotnet is using dlopen() to open some of its libraries
<clever>
sphalerite: you will need to do "nix-shell -p nixUnstable", and if it gets root, it may upgrade the db.sqlite, which then means you have to keep using nixUnstable
<clever>
kuznero: but it may also break things, so try with it off and see if that helps
<clever>
kuznero: the automatic shrink is still of use, it can remove things you added but didnt actually need
<clever>
sphalerite: something like nix copy --to local?root=/mnt
<clever>
sphalerite: one sec
<clever>
which may break the rpath after your test --version
<clever>
kuznero: it turns off the fixup hook that shrinks the rpath
<clever>
kuznero: also, there is a function in lib to deal with line 12 for you
<clever>
it doesnt even have a copy of nixpkgs in the channel anymore
<clever>
ive stripped everything i can out of the host debian, lol
<clever>
no free space on /tmp again
<clever>
sphalerite: my 3rd attempt at building gcc died while building the info docs
<clever>
sphalerite: ondemand was probably already doing its job
<clever>
sphalerite: then it would cut the clock rate down to 600mhz, and now it cant decode video in realtime
<clever>
sphalerite: i had an old laptop, where i used to watch videos on an external monitor with the display closed, the laptop would overheat because it expected airflow thru the keyboard
<clever>
sphalerite: try stopping all load, let it cool down, and then see if the freq goes up
<clever>
sphalerite: the cpu will just silently ignore requests to go faster, and run at a lower speed
<clever>
sphalerite: thermal throttling is often without logs
<clever>
sphalerite: thermal throttling may also be at play, what is the temp?
<clever>
MagneticDuck: nix will accept several types of hashes, and will just silently convert them
<clever>
infinisil: if it cant find the file, then sandboxing is of
<clever>
infinisil: when nix is installed on ubuntu for ex, it wont have a nix.conf
<clever>
MagneticDuck: nix-store --query --hash
<clever>
infinisil: single-user nix can work without it on most distros
<clever>
kiloreux: /etc/nix/nix.conf
<clever-afk>
one option is to keep all the hardware stuff in hardware-configuration.nix and let nixos-generate-config remake that on the new machine
<clever-afk>
tanonym: yes
<clever>
sphalerite: another more nasty/hacky thing, attach gdb to a random process in the shell, and use gdb to eval system("make -j4"); in the remote process!
<clever>
at 11%, its probably faster to restart
<clever>
sphalerite: thats always safe, but depending on how long its been running, may cost more time then it would have saved
<clever>
heading out now, i'll be back in a few hours
<clever>
joko: which can be passed to nix-repl
<clever>
joko: -I nixpkgs=/path/to/nixpkgs
<clever>
sphalerite: id just leave it be
<clever>
joko: does erlang_nox exist in your version of nixpkgs?
<clever>
sphalerite: which is a \0 seperated list
<clever>
sphalerite: you would want to peek within /proc/<PID>/environ of the make process, to get the real env vars
<clever>
sphalerite: that likely wont have vars set by setup.sh and setup hooks
<clever>
sphalerite: the env vars would all be wrong
<clever>
joko: and what error does that file give?
<clever>
joko: that could be done, they all appear in /proc/cmdline
<clever>
seequ: thats the bug i mentioned to sphalerite a few minutes ago
<clever>
seequ: does it still produce a result link and give directions?
<clever>
joko: its only partialy written right now, but you can "nix-build dummy.nix" then run qemu-kvm with the right args (including -append from the pxe config) to boot the resulting image
<clever>
joko: also, did you notice the dummy.nix i made for testing?
<clever>
joko: ah, sure
<clever>
joko: for which changes?
<clever>
joko: that will just re-download the entire thing from the binary cache