<clever>
pie_: depends on if the problem is at build time or when running the built result
<clever>
DigitalKiwi: but with haskell and some muxing, you can run multiple things in the child proc at once, and not mix the outputs up
<clever>
DigitalKiwi: for example, with the perl framework, you can only run one thing at once
<clever>
DigitalKiwi: using a proper muxed rpc over the serial port also adds more options
<clever>
ghc is only needed to compile the test runner, which only changes rarely (when editing tests, or a mass-rebuild)
<clever>
and for those that dont want to do complex stuff, the default guest functions can support what we already have
<clever>
and the guest proc can be as complex or simple as it needs to be
<clever>
then, rather then have to smuggle files around thru echo and 9plan, you can just send a signal to the guest proc, and it can do complex actions on its own
<clever>
DigitalKiwi: what i want, is some haskell code, that runs in both the host and guest, and uses a binary rpc to coordinate between the 2 halves
<clever>
DigitalKiwi: and then parses the result to find the EOF and exit code
<clever>
DigitalKiwi: it basically does `(foo);echo '|!EOF' ?$` over a serial console
<clever>
jD91mZM2: ive seen a lot of people do that
<clever>
wedens: all of the $out's from contents get merged into /
<clever>
wedens: put the symlinks in $out/something of a derivation, and put that into the contents, i think
<clever>
wedens: what are you needing to do?
<clever>
wedens: thts why i never use runAsRoot
<clever>
wedens: the build cant get real root, so its using qemu to get emulatoed root
<clever>
> builtins.elemAt [ "a" "b" "c" ] 2
<clever>
[200~> builtins.elemAt [ "a" "b" "c" ] 2
<clever>
Maise: just buildPhase = "./build.sh";
<clever>
Maise: so you just want ./build.sh
<clever>
Maise: the unpackPhase copies $src to . for you, and cd's into the dir
2019-10-24
<clever>
pingiun: so you want to run `unpackPhase`
<clever>
pingiun: the unpackPhase will cpy $src to .
2019-10-22
<clever>
sondr3: pkgs.runCommand, examples can be found all over nixpkgs, though configuring emacs to use the result might be tricky
<clever>
yep
<clever>
its just a regular old symlink
<clever>
rm result
<clever>
it will remain in /nix/store until you both remove result and collect garbage
<clever>
same there, all it does is build things and make a result symlink
<clever>
theres nothing to really undo with `nix-build`
<clever>
ah, for that, you want either `sudo nix-channel --update ; nix-env -iA nixos.chromium` or remove it, add it to systemPackages, and do the previous
<clever>
Cement: in general, sudo nixos-rebuild --upgrade switch
<clever>
Cement: ?
<clever>
hpfr[m]: anything the nixos-rebuild would have built (but was already built), and anything it needs in the future (sources for something it will build soon)
<clever>
have you gotten a cross-compiler to produce a bit perfect replica of a native binary?
<clever>
that relies on the build actually being reproducible
<clever>
so it wont share products between native and cross
<clever>
which compiler you use affects the hash of $out
<clever>
it wont mix native and cross to suit the host arch
<clever>
ah, no
<clever>
li_matrix: if you set system to x86, but crossSystem to arm, and attempt to run the build on an arm machine, it will find the "nearest" x86 machine to do the job
<clever>
li_matrix: not on its own, but you can configure it for cross-compiling
<clever>
hpfr[m]: only what the current rebuild needs will be rooted, and only once the main build has started, IFD's and the eval mess things up a bit
<clever>
li_matrix: sorta, a derivation has an arch its supposed to run on, and if the current machine cant run that arch, its forced to use a remote build machine
<clever>
hpfr[m]: yeah, nothing the build needs can be gc'd during a build
<clever>
just adding lib is the right one then
<clever>
hpfr[m]: is this a package or configuration.nix?
<clever>
hpfr[m]: stdenv.lib is another way to access lib
<clever>
2016-03-05 19:24:22< Sonarpulse> I did a diff <(pp-aterm $(nix-instantiate ...) <(ditto)
<clever>
2015-09-14 22:21:18< Mathnerd314> McEnroe_: why do you need the configuration.nix? just use pp-aterm -i $(nix-store -q --deriver /nix/var/nix/profiles/system-<n>-link)
<clever>
i believe it was pp-aterm
<clever>
elux: so you need to `NIX_PATH=nixpkgs=. nixos/maintainers/scripts/gce/create-gce.sh`
<clever>
elux: that just builds whatever <nixpkgs> from NIX_PATH maps to
<clever>
evils: that happens randomly if nix-daemon was stopped
<clever>
though i had no encrypted datasets
<clever>
evils: ah, thats pretty similar to the testing i did
<clever>
so its near imposible to debug when it stops working, lol
<clever>
but while it does boot, all directory listing operations fail
<clever>
evils: i have gotten grub to boot from zfs, without encryption
<clever>
evils: that would require grub to support the encryption, which i dont think it does
<clever>
evils: biggest detail is if /boot is on zfs or ext4
<clever>
evils: yeah, it also depends heavily on how complex the tests are
<clever>
part of why nix just defaults to not testing things
<clever>
evils: yeah, you kind of need to know how the tests work and how to make them pass, and what they are doing, to get things fully working
<clever>
hpfr[m]: you could try to make the override only apply to xorg, or you could PR the fix to nixpkgs, so hydra.nixos.org builds things for you
<clever>
hpfr[m]: checked the same thing, and its not a direct dep, but it may be an indirect dep (via something else)
<clever>
hpfr[m]: wacom is probably doing it, if you temporarily comment out wacom, what happens?
<clever>
hpfr[m]: any overrides that modify qt?
<clever>
hpfr[m]: are you sure the binary cache is enabled?
<clever>
hpfr[m]: all of those k things depend on qt directly, the bigger question is why qt differs
<clever>
hpfr[m]: is the machine set to use kde/plasma?
<clever>
evils: :q!
<clever>
Shouou: before the nodejs could compile in nix, this package was just extracting the js from a darwin installer, then running a linux electron against it