<clever>
you need to use .overrideAttrs to keep that magic working
<clever>
camsbury: nativeBuildInputs and buildInputs are handled specially in stdenv.mkDerivation, and i think that special magic doesnt work if you further edit them with .overrideDerivation
<clever>
and if you need several, you have to chain them in the right order
<clever>
which one you need, depends on what your trying to change
<clever>
and then at the lowest level, .overrideDerivation happens after stdenv.mkDerivation, so it cant change cross-compile level things
<clever>
so its harder to change haskell specific stuff (and overrideCabal wont work on the result), but its easier to change non-haskell things
<clever>
.overrideAttrs happens after generic-builder.nix, but before stdenv.mkDerivation
<clever>
overrideCabal happens before the haskell generic-builder.nix, so you can mutate the args passed to mkDerivation, before generic-builder.nix acts on them
<clever>
.env is haskell specific
<clever>
at the highest level, you have .override, which is added by callPackage, it can change the args originally passed into the function (like the { stdenv, hello, cmake }:)
<clever>
.overrideAttrs works on the haskell derivations too, but happens at a later stage, and breaks the more haskell features of it, sorta
<clever>
and .env is less haskell-y of a derivation, so normal .overrideAttrs works
<clever>
i try to override the .env instead, since its only needed on the shell side
<clever>
camsbury: if you put the string from the above nix-build, into a default.nix, you can just nix-build without any args
<clever>
slack1256: i would just setup build slaves, which is in the nixos manual
<clever>
and `cabal configure` just uses Setup.hs without you noticing
<clever>
ive been meaning to add a cabal (bash function) to the .env, so this whole thing becomes invisible
<clever>
and the defaultMain inside the default Setup.hs, is just going to do the exact same thing as the cabal binary from cabal-install
<clever>
you can also `ghc Setup.hs -o Setup` and `./Setup configure` if you want to make it slightly faster
<clever>
Setup.hs will link against the Cabal library, which nix always provides
<clever>
and then wont behave the same as mkDerivation does at nix-build time
<clever>
if you just install cabal-install, it can potentially be the "wrong" version
<clever>
error: Package ‘avr-libc-2.0.0’ in /nix/store/bssxqlhb7liba974sx8yz3d0arjzvp9s-nixos-19.03pre166449.be445a9074f/nixos/pkgs/development/misc/avr/libc/default.nix:25 is not supported on ‘x86_64-unknown-linux-gnu’, refusing to evaluate.
<clever>
ive not done avr stuff on nixos yet, havent had to modify the firmware since switching
<clever>
there should be an avr-libc package somewhere
<clever>
hmmm, none of those look like the right choice
<clever>
,locate avr io.h
<clever>
veverak: i think the rpi can boot from usb mass-storage now, so you can just dd the original .img you started with, to that usb stick
<clever>
and then another nixos-rebuild switch will just use it
<clever>
veverak: you can then use nix copy again, in the reverse direction, to copy the build product back to /
<clever>
veverak: this should work even that early on
<clever>
veverak: and this then builds it, inside /mnt/nix/store/
<clever>
veverak: `nix-instantiate '<nixpkgs/nixos>' -A system` will give you a .drv file for the whole nixos build
<clever>
veverak: ah, it could just be that you ran out of space then
2019-02-21
<clever>
or maybe it was TMPDIR, or one of those
<clever>
NemesisD: just export TMP=/tmp/ i think
<clever>
NemesisD: that tmpdir is managed by systemd, and is a percentage of your ram, i try to always keep the build temp on /tmp, which is part of the / fs
<clever>
ar1a: that works on both outputs, and .drv files
<clever>
selfsymmetric-pa: this step should fail 100% of the time
<clever>
cp -p epdfinfo /home/matt/.local/bin/
<clever>
but the new key is only usable from the result, and emacsPackagesNg cant internally refer to it
<clever>
ikitat: that is added to your nixos config, and line 14 will run as one of the last steps, when creating the storepath that /run/current-system points to
<clever>
ikitat: add it as a normal build slave in /etc/nix/machines
<clever>
the singlequotes stop bash from eating the double, so nix gets "value" as a nix level string
<clever>
--argstr arg value, is just --arg arg '"value"'
<clever>
--arg, not --argstr
<clever>
> /tmp/foo
<clever>
immae: just use /tmp/foo as a path at the nix level, unquoted
<clever>
lejonet: of note, root is trusted by default, so you can always just `nix copy --to ssh://root@laptop /nix/store/foo` and ignore fixing the cfg
<clever>
illegalprime: yeah, nixos-unstable is just the latest rev of master to pass a set of tests
<clever>
illegalprime: pkgs.pkgsCross.aarch64-multiplatform.glibc builds perfectly on a recent nixos-unstable
<clever>
evanm: yeah, i believe you need to use a new nixpkgs, to fix the new darwin problems
<clever>
illegalprime: its fetching 90% of it from the cache, and only building a single glibc
<clever>
illegalprime: trying the same build here...
<clever>
illegalprime: you can directly run `nix-shell /nix/store/foo.drv` to open a given derivation in the shell, but that still wont help you know which one to edit
<clever>
i just write things for nix, since nix works on every distro
<clever>
i basically ignore all other distros when packaging things now
<clever>
Phillemann: and you cant use normal env vars like ${out} why?
<clever>
Phillemann: looking closer, it wont directly pass $out to make
<clever>
Phillemann: the $out env var will always be available
<clever>
i cant see any reason for it to be doing that
<clever>
thats strange....
<clever>
ProofTechnique: i cant see anything that would indicate quoting, can you add /etc/offlineimaprc to the gist?
<clever>
ProofTechnique: can you pastebin your nix expression?
<clever>
Phillemann: i usually just run ls on the result symlink, find what sub-path its at, and then hard-code the nix to use $out/lib/libfoo.so
<clever>
Phillemann: at build-time, it will be somewhere under $out (an env var)
<clever>
Phillemann: embeding the absolute path of the .so would be better, not sure why more arent doing it
<clever>
Phillemann: thats how nearly all python things handle it, but i dont like that, because people keep missing it and random_python_library#42 then fails when imported
<clever>
and its 4am here, i should get some sleep
<clever>
eyJhb: i have shared folders without it
<clever>
eyJhb: i dont have the extension pack enabled, so it mostly comes from the cache
<clever>
eyJhb: yeah, that looks like it should work
<clever>
eyJhb: what does `sudo nix-channel --list` report?
<clever>
you could try switching to nixos-unstable?
<clever>
eyJhb: master is only ~14 hours ahead of nixos-unstable
<clever>
"19.03pre166449.be445a9074f"
<clever>
$ nix eval nixpkgs.lib.version
<clever>
yeah, i think it would be worth a bug on nixpkgs
<clever>
without messing up vim for any other users on the machine