<clever>
plopix: what about making a wrapper around the entire emacsWithPackages
<clever>
and that may not play nicely with the emacsWithPackages code
<clever>
it needs something like postInstall, that will use makeWrapper to modify $out/bin/emacs
<clever>
but you have no way to reference that derivation
<clever>
and that shellHook only applies if you directly run nix-shell on myEmacs
<clever>
once emacs is done compiling, they leave the picture entirely
<clever>
plopix: the change you did only puts stack and mu into the $PATH while emacs is being compiled
<clever>
gchristensen: and the cp needs -r
<clever>
gchristensen: also needs to chmod +w -R $out
<clever>
dash: but nixos-rebuild --fast both skips that, and does --show-trace
<clever>
dash: and it may not pass all of the args to the first nix build
<clever>
dash: behind the scenes, nixos-rebuild will first try to build nix, then use that nix to build nixos
<clever>
dash: try nixos-rebuild --fast instead
<clever>
dash: i think it does, but only for the nixos side, not for the nix side
<clever>
__monty__: they are all the same expression
<clever>
__monty__: one for each version of python
<clever>
romildo: so if you add (pkgconfig.override { vanilla = true; }) to your buildInputs, you will get an unpacked version
<clever>
romildo: i havent seen that bug before, but there is the optional on !vanilla in there
<clever>
__monty__: try the thunderbird package first, nix-env -iA nixpkgs.thunderbird
<clever>
romildo: and you have to add the deps the .pc wants to the buildInputs
<clever>
romildo: i remember something about pkg-config silently dropping things, if the dependencies listed in the .pc file cant be found
<clever>
disasm: is the problem happening under nix-build?
<clever>
viric: it might have been off back then
<clever>
viric: __impureHostDeps is another thing, its in build.cc again
<clever>
viric: i just remember that it worked with a zero byte sshc-onfig in the NIX_PATH
<clever>
viric: i'm not sure how that worked either, now that i think of it
<clever>
viric: it might even copy the unix socket intact into the store? not sure
<clever>
viric: my first guess is that because it came from NIX_PATH, maybe nix considers it a legal input to the build, and tries to copy it in
<clever>
viric: that leaks in i think, let me check
<clever>
it uses the NIX_PATH
<clever>
also, this doesnt use env vars at all
<clever>
it then acts as a proxy
<clever>
viric: the socat running as root is the "client" for ssh-agent, and root is an exception to the uid lockout (so you can use things under sudo)
<clever>
viric: i already have a gist that solves this
<clever>
viric, gchristensen: looks like it just does getEnv as the process initiating the build (the daemon)
<clever>
viric: not 100% sure though
<clever>
viric: i believe they come from the nix-store -r
<clever>
i usualy just throw \'s at the problem until it goes away, lol
<clever>
gchristensen: sed can also use a character other then /
<clever>
__monty__: the name must be config.nix, but otherwise, yes
<clever>
yeah, cygwin does something special to manage them within its FS's
<clever>
yeah, that should also help
<clever>
then uncomment it, and switch again, so nixos creates it properly
<clever>
try commenting out the user in configuration.nix and do a switch, so nixos deletes the user
<clever>
maybe, does the home directory exist?
<clever>
viaken: did you set isNormalUser on the user when you made it in configuration.nix?
<clever>
lets see, where did i save that RDP info....
<clever>
looks like i will need to start from setup-x86_64.exe
<clever>
so there wont be any confusion within hydra
<clever>
ah, good
<clever>
viric: also, what does builtins.currentSystem eval to under cygwin64?
<clever>
is the install as simple as just doing ./configure && make && make install on a nix checkout, and then initializing the store as usual?
<clever>
i was thinking of running ghc to build haskell packages
<clever>
ah, thats similiar to what i'm thinking
<clever>
viric: how well does nix work under cygwin64, and is it possible to have a nix based toolchain that can create executables that dont depend on cygwin at runtime?
<clever>
yeah
<clever>
and is hardened against such things, though it relies on where libstore puts /tmp/nix-build-foo
<clever>
channel unpacking its its own derivation, that can run fully in a sandbox
<clever>
joehh: that sounds like it only gets cleared on reboot
<clever>
joehh: every package gets its own directory, so the files can never clash, and it will never read something from another package
<clever>
joehh: nix doesnt allow that
<clever>
joehh: its at this path on my system, so you would need to apply a packageOverride to systemd, and then rebuild everything that depends on systemd
<clever>
cannot import ‘/nix/store/v2w72ydhc2sygmaqnzhfw7b04z3i54mv-nixpkgs-channels-25f4906da6387e132823417bc54ea86040fb9bd5-src’, since path ‘/nix/store/pkb1w9v39kz26fm109si5d6hxb699q32-nixpkgs-channels-25f4906da6387e132823417bc54ea86040fb9bd5-src.drv’ is not valid, at /tmp/dyno/nixpin.nix:5:3
<clever>
while evaluating the file ‘/tmp/dyno/nixpin.nix’:
<clever>
Nobabs27: a quick google says that i3 doesnt support setting the resolution, so you just need to arrange for the xrandr to run every time you login
<clever>
Nobabs27: yeah
<clever>
gchristensen: id say thats going to fail when garbage collection runs and eats things
<clever>
Nobabs27: lightdm is the display manager, there is also a desktop manager that runs after you login
<clever>
Nobabs27: the one that comes up after you login
<clever>
Nobabs27: are you using a desktop manager?
<clever>
it will only search what is available in the nixpkgs on your channels
<clever>
it has no way of knowing which one you just copied over and want to use
<clever>
dylanjust[m]: that gives it a different set of nixpkgs to search within
<clever>
dylanjust[m]: the nix-env search commands always search nixpkgs, not what has been copied over
<clever>
gchristensen: you can also "nix-env -i /nix/store/foo" directly on the path you copied
<clever>
oscarvarto: i run it on most of my systems
<clever>
yeah
<clever>
Dezgeg: ahh, so it takes a disk image and a cmd
<clever>
how did you run grub-fstest?
<clever>
Dezgeg: ive also heard that grub totally ignores the journal, so things may read back corrupted after an improper shutdown
<clever>
Dezgeg: ive also found that ls on zfs is far far far worse then a simple lookup
<clever>
so those inode warnings probably where on my end
<clever>
i had used a nixos-in-place variant, and couldnt change the FS to what i prefer
<clever>
Dezgeg: oh, and i think my netbook has an xfs / without /boot
<clever>
Dezgeg: ahh
<clever>
xfs and zfs have the same issue in grub
<clever>
i believe i was passing on information i heard from another user
<clever>
2017-07-30 20:42:14< clever> gchristensen: when /boot is on the same fs as /, grub has to navigate the horrors of /nix/store to find kernels, and spits out many warnings about invalid inodes
<clever>
and due to timezones, that was on the 30th here
<clever>
hmmm, thats barely a month ago
<clever>
Dezgeg: heh, can you pastebin it to remind me?, or give a date
2017-08-20
<clever>
Dezgeg: probly somebody else, i always go for a safe ext4 for /boot