<angerman>
I think I found the key part to nixops: `{ lz = { config, pkgs, lib, ... }: { deployment.targetHost = "..."; nixpkgs.system = "x86_64-linux"; }; }` setting `nixpkgs.system`. the virtualbox and other environments do that by default.
<angerman>
> error: all build users are currently in use; consider creating additional users and adding them to the ‘nixbld’ group on ‘root@nix-docker’
<angerman>
great.
pxc has joined #nix-darwin
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nix-darwin
{^_^} has joined #nix-darwin
hamishmack has quit [Quit: hamishmack]
hamishmack has joined #nix-darwin
cransom has quit [Ping timeout: 256 seconds]
<LnL>
qmm: that looks like a network issue, maybe try a few times
<LnL>
angerman: I think the image currently only has 2 or 4 users so you can’t use a larger number in the machines config
<LnL>
angerman: I’m planning to increase that
zzamboni has joined #nix-darwin
zzamboni has quit [Client Quit]
zzamboni has joined #nix-darwin
zzamboni has quit [Quit: Leaving.]
zzamboni has joined #nix-darwin
zzamboni has quit [Client Quit]
zzamboni has joined #nix-darwin
zzamboni has quit [Quit: Leaving.]
zzamboni has joined #nix-darwin
zzamboni has quit [Remote host closed the connection]
zzamboni has joined #nix-darwin
zzamboni has quit [Client Quit]
zzamboni has joined #nix-darwin
zzamboni has quit [Client Quit]
zzamboni has joined #nix-darwin
zzamboni has quit [Remote host closed the connection]
zzamboni has joined #nix-darwin
zzamboni has quit [Client Quit]
zzamboni has joined #nix-darwin
zzamboni has quit [Ping timeout: 256 seconds]
zzamboni has joined #nix-darwin
<LnL>
whaaa, my uninstaller works :D
zzamboni has quit [Remote host closed the connection]
zzamboni has joined #nix-darwin
zzamboni has quit [Remote host closed the connection]
zzamboni has joined #nix-darwin
zzamboni has quit [Ping timeout: 248 seconds]
zzamboni has joined #nix-darwin
<qmm>
LnL: it works now. this is the very time i've had ghcjs installed on my computer. i'm so happy, i might cry
<qmm>
it's been nearly 5 days since i decided i would like to install this software
<qmm>
i do wonder why the server returned an http 500 error, but only in hopes that the service isn't like that in the future
<LnL>
:/
<LnL>
if you can use that channel for everything, the releases get security updates and fixes but package versions stay more or less the same
<LnL>
you'll have the best chance of things working there, we're down to ~450 darwin failures on 17.09
<qmm>
yeah. it's a little sad since that kind of experience makes me take a pause about asking teammates to depend on nix, unfortunately. however, i'm willing to admit i'm new and maybe this will be an easier way for me to install stuff going forward
<qmm>
i can tell a lot of work has gone into the project
<qmm>
it would be unwise i think for me to dismiss this project after a little speedbump the first week
<qmm>
i need to read through the rest of the documentation when i have time over the next few weeks
<qmm>
anyway, just wanted to report your suggestion did work on my machine. thank you so much for taking the time to help me. it means a lot
<LnL>
darwin is a bit of a second citizen, things sometimes break because people can't test it, etc.
<LnL>
and ghcjs isn't one of the most stable builds AFAIK
<LnL>
what a lot of projects do is lock the version of nixpkgs in the source and update it to a revision that works
<qmm>
taking note of that for the future
<LnL>
I even have an alias that returns the last good nixpkgs commit for a build with the hydra api
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
peacememories has joined #nix-darwin
peacememories has quit [Client Quit]
zzamboni has joined #nix-darwin
pxc has quit [Ping timeout: 256 seconds]
zzamboni has quit [Remote host closed the connection]
philr has joined #nix-darwin
zzamboni has joined #nix-darwin
<acowley>
I'm hitting a few situations where I get an "Argument list too long" from clang++. Is there an existing work around, or should I modify the wrapper to use a response file for all the nix-provided paths?
zzamboni has quit [Ping timeout: 255 seconds]
<acowley>
One build that failed has > 600 extra flags, for example
<acowley>
Which doesn't actually seem like *that* many in a nix world, which is why I have a small hope there's already a workaround.
philr has quit [Ping timeout: 260 seconds]
<acowley>
Cleaning up the response file is a bit tricky
<acowley>
Need a fork to do the cleanup
<acowley>
Now to see if it can handle a big build
<acowley>
Such a ridiculous effort. The nix-shell takes ~2 minutes to enter.
<acowley>
I think this is going to work. But not just yet: posix_spawn failed: Argument
<acowley>
list too long
<acowley>
Other than the cleanup ugliness, I wonder if we should switch the main clang wrapper to use response files
<acowley>
Anywho, will pick this up again in an hours
<LnL>
Sonarpulse: ^ did something change with compiler flags since the cross changes?
<LnL>
I traced the sierra test failure back to that, it also failed because of the number of arguments
<acowley>
So close! My compile now fails after ~4 minutes of churning away.
<acowley>
I think my response file wrappers work, so that's nice.
<acowley>
But there are so many flags in flight that somewhere in the bowels of the build something is trying to start another process and blowing up due to the number of arguments
<acowley>
Hm. The place where it's now stuck with that error doesn't look problematic.
<dtz>
wow re:response file wrappers that's neat
<dtz>
that does seem like an awful lot of flags, though :3
<acowley>
They're not interesting flags, just paths (i.e. -isystem and -L)
<acowley>
The silly thing is that our existing wrapper carefully expands response file arguments to filter arguments for some purpose, so then I go back and rebuild response files with what we want to pass to the unwrapped compiler.
<acowley>
Unfortunately, something else in the wrapper is tripping this limit now that I've coddled the exec to the compiler.
<acowley>
In fact, it might be that expansion that's dying now
<acowley>
Yeesh
<acowley>
If I have to write a response file wrapper for the nixpkgs expand-response-params helper program........
<dtz>
LOL
<dtz>
D:
<acowley>
I am becoming convinced something is actually wrong with our clang wrapper at the moment
<acowley>
I'm seeing that error with 265 flags
<acowley>
That's small enough to fit on a screen
<acowley>
yep
<acowley>
Same line using /usr/bin/clang++ does not barf, but can't find an include file
<acowley>
So the clang++ that clang-wrapper is calling into has a limitation
<acowley>
And switching to clang-5 to see if it also has this issue is not easy
<acowley>
I think I'm sunk. I don't see anything obviously weird in the clang derivation, but it just behaves differently than my Apple-provided one.
<acowley>
Hm, no that's not right. I can't easily compare nixpkgs clang to the Apple one.
<acowley>
27k characters in this line. That can't be a limit, can it?
hamishmack has quit [Quit: hamishmack]
<LnL>
no idea
<johnw>
it seems the tests for nixUnstable cannot run in my shiny new nix-darwin distributed build setup
<johnw>
I get: chmod: changing permissions of '/private/tmp/nix-test/store': Operation not permitted
<LnL>
yeah tmp isn't namespaced :/
<LnL>
ssh foo -- sudo rm -r /tmp/nix-test
<johnw>
trying
<LnL>
only happens when the tests fail/abort I think