<gchristensen>
why 32 though? why not just be maxJobs?
<niksnut>
because then it will be way too low for many systems
<LnL>
gchristensen: I just used what nixos has
<niksnut>
e.g. if maxJobs = 1 and you run two nix builds in parallel, the second one will fail
<gchristensen>
when would it be too low if it won't run more jobs than build users? I feel like I'm missing an important thing
<LnL>
gchristensen: problem is that you can run with -j16 even if you only have 4 cores
<LnL>
that fails like that issue
<gchristensen>
new issue: if I run it with -j100 it fails on my server with 96 cores. is the issue nix, or is the issue the caller passing too high of a -j?
<copumpkin>
niksnut: so process signalling is the only reason we keep users around?
<LnL>
true
<copumpkin>
would be lovely to kill the need altogether
szicari has joined #nix-darwin
<gchristensen>
maybe the issue is Nix if we don't block until build users are available?
<niksnut>
yes
<niksnut>
copumpkin: no, the main reason is to isolate builds from each other
<gchristensen>
ok, then a band-aid of 32 users makes sense to me :)
<copumpkin>
niksnut: yeah but I don't get how it helps if we already have namespace isolation and the like
<niksnut>
copumpkin: I wouldn't rely on namespace isolation...
<copumpkin>
what does it prevent that would otherwise be allowed?
<copumpkin>
oh, so it's a backstop
<niksnut>
I think it's very dangerous to assume that processes with the same uid in different pid namespaces can't affect each other
<niksnut>
e.g. resource controls are global, iirc
<gchristensen>
that surely sounds like a safe position to take
<copumpkin>
fair enough
<copumpkin>
if we're using ephemeral users there's not much overhead anyway
<copumpkin>
I just wish we could avoid it on macOS :)
<disasm>
so I just tried removing all the stuff I installed in nix-env before I tried nix-darwin and got this error: error: derivation '/nix/store/frc6gyxs9nlh63x5ci1v6mgii0kz0j9p-user-environment.drv' specifies a sandbox profile, but this is only allowed when 'sandbox' is 'relaxed'
<LnL>
yeah, nix-env doesn't like sandboxing yet
<LnL>
I tried fixing that a few days ago, but ran into some issues with libSystem and impure stuff :/
<disasm>
how can I kill those packages? :) is there a way to temporarily disable the sandbox to run one command?
<LnL>
yes, the buildenv binary tries to load something from /usr/lib/system/ that's allowed in the sandbox
<niksnut>
copumpkin: oh, I forgot the most important reason, namely filesystem isolation
<niksnut>
you don't want builders messing with each other's output
<disasm>
yay! thanks :)
<copumpkin>
niksnut: but aren't the outputs the only RW bind mounts?
<copumpkin>
or are you still assuming no namespaces?
<gchristensen>
/build and friends
<copumpkin>
sure
<copumpkin>
but those are already separate aren't they?
<LnL>
err I mean not allowed :p
<disasm>
how do most folks handle dns for different internal domains on osx? I've been playing with /etc/resolver/<domain> but then for example, if I need a hostname like remote.domain.com to resolve not using the internal server to connect to the vpn I can't connect to the vpn. On NixOS I just used dnsmasq with a bunch of address, server and cnames listed in extraConfigs
<copumpkin>
LnL: does it work if we add the builder of a derivation to the dependency scanner?
jrolfs has quit [Ping timeout: 256 seconds]
<copumpkin>
it seems like it should
jrolfs__ has quit [Ping timeout: 250 seconds]
<LnL>
oh I've not tried to run resolve-system-dependencies manually
<copumpkin>
I just mean either adding impureDeps for the same path as builder
<copumpkin>
or doing that on the derivation side, since it seems like it might be the right thing to do in general
<LnL>
I'll have to take another look, I did fix the frameworks issue
zzamboni has quit [Quit: Leaving.]
peacememories has joined #nix-darwin
the-kenny has quit [Quit: WeeChat 1.9.1]
the-kenny has joined #nix-darwin
__Sander__ has quit [Quit: Konversation terminated!]
jrolfs has joined #nix-darwin
jrolfs__ has joined #nix-darwin
jrolfs__ has quit [Ping timeout: 260 seconds]
jrolfs has quit [Ping timeout: 248 seconds]
jrolfs__ has joined #nix-darwin
jrolfs has joined #nix-darwin
jrolfs__ has quit [Ping timeout: 264 seconds]
jrolfs has quit [Ping timeout: 268 seconds]
jrolfs has joined #nix-darwin
jrolfs__ has joined #nix-darwin
jrolfs has quit [Ping timeout: 252 seconds]
jrolfs__ has quit [Ping timeout: 256 seconds]
jrolfs has joined #nix-darwin
jrolfs__ has joined #nix-darwin
zzamboni has joined #nix-darwin
jrolfs__ has quit [Ping timeout: 240 seconds]
jrolfs has quit [Ping timeout: 248 seconds]
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zzamboni has quit [Quit: Leaving.]
zzamboni has joined #nix-darwin
jrolfs__ has joined #nix-darwin
jrolfs__ has quit [Ping timeout: 264 seconds]
<pikajude>
hmmm, that one rustc test on high sierra still fails for me
<pikajude>
how odd
zzamboni has quit [Quit: Leaving.]
<pikajude>
oh, it's because it's a known issue for high sierra
<johnw>
is there a better way to refer to my $HOME in this file?
<johnw>
rather than explicitly giving /Users/johnw?
<LnL>
depends on the context
<LnL>
nixpkgs uses builtins.getEnv "HOME"
<johnw>
and is there an equivalent to --leq for darwin-rebuild?
<LnL>
it's declarative, there's no way not to do a full rebuild
<johnw>
i mean, say I reference qemu
<johnw>
a dependency of qemu changes, but qemu's version has not
<johnw>
will qemu rebuild? -u it wouldn't, -u --leq it would
<LnL>
yes that rebuilds
<johnw>
k
<johnw>
i've switched to the "unstable" channel, to avoid a little extra churn
<LnL>
nix-env has some special magic that looks at the package names and checks if the version changed
<johnw>
I wonder why *-rebuild and nix-env don't share magic?
<LnL>
nix-env compares the current evaluation with ~/.nix-profile/manifest.nix
<LnL>
nix-build and *-rebuild always generates the same build regardless of the current active prfile
<johnw>
so, now my system is divided between packages installed by nix-darwin, and user packages installed by nix-env. Since my user pckages is where all the churn occurs, this is a much better separation. It means I can darwin-rebuild even when nix-env would have required 10+ hours to update
<ldlework>
How do people here handle opening say Emacs from places other than the shell, and having it have the proper PATH?
<ldlework>
on OSX
<ldlework>
Like from spotlight, etc
<johnw>
Idlework: you could make a wrapper in /usr/bin/ that sources /etc/bashrc (or sets the Nix shell variables) and then invokes the Emacs you want
<ldlework>
open -n -a ~/.nix-profile/Applications/Emacs.app
<ldlework>
hmm
jrolfs has joined #nix-darwin
jrolfs__ has joined #nix-darwin
<johnw>
I actually had to do this with Firefox yesterday
<johnw>
in order to get a plugin to see my Nix-based GnuPG agent
<LnL>
I always thought systemctl setenv would help there, but apparently not
<ldlework>
Hmm there was some reason I needed to use open but I'll try this
<johnw>
well, "open" has the benefit of opening at most 1 Emacs application
<johnw>
doing it directly like this may open severa/l
<johnw>
have you thought of using emacsclient instead?
<johnw>
to talk to a single Emacs that you keep running?
<ldlework>
I think I'm explicitly using open so that I get multiple instances
<ldlework>
I don't want a single emacs
<johnw>
oh, in that case, don't bother with open
<johnw>
just run the binary directly yoursefl
<LnL>
I think -n makes it open a new instance
<ldlework>
yeah
zzamboni has joined #nix-darwin
<ldlework>
So I am opening emacs from hammerspoon
<ldlework>
And it seems if I just use bash and execute the binary directly then hammerspoon hangs
<ldlework>
so I think open is helping with that
<johnw>
yes, open is like running it from bash with "&" at the end
<johnw>
running it directly will block until Emacs quits
<ldlework>
So how do we combine the best of both worlds?
<ldlework>
:)
<johnw>
so, basically open is using the environment variables present at login to your GUI session
<johnw>
the same as any Application would see
<johnw>
while bash is seeing what results from executing the bash scripts you get when you start a shell in your terminal
<ldlework>
oh the hammerspoon execute() takes a bool to run user environment scripts
<johnw>
nice!
<ldlework>
easy button :)
<johnw>
yay, ghc-mod restored
<johnw>
now if only idris and liquidhaskell worked again
<johnw>
oh, and poor threadscope; I haven't been able to build him in more than a year
<disasm>
think I'm going to fix openconnect on darwin. It looks like homebrew just grabs vpnc-script without installing vpnc. Should I create a separate package for vpnc-script and do something like if darwin use this, otherwise, use vpnc as buildInput.
<johnw>
I just noticed that when you "git clone", the sample hook scripts get rewritten to point to a particular store path's bash
<johnw>
that seems like a bad idea
jrolfs__ has quit [Ping timeout: 240 seconds]
jrolfs has quit [Ping timeout: 268 seconds]
jrolfs has joined #nix-darwin
<johnw>
LnL: I'm trying to start a build, but am getting: error: all build users are currently in use; consider creating additional users and adding them to the ‘nixbld’ group
<johnw>
do you know what this is about?
<LnL>
are you using -j
<johnw>
yes, -j12
jrolfs__ has joined #nix-darwin
<johnw>
intended it to use 4 for hermes, and 8 locally
<johnw>
I only have hermes in my buildMachines
<johnw>
do I need the localhost there too?
<johnw>
note that -j8 appears to work fine
<LnL>
yeah, the bootstrap script only creates 10
<johnw>
ah!
<LnL>
and if you "build" more stuff (including stuff like buildEnv) it will fail like that
<johnw>
if I get an 18-core iMac, I'll need to create like 24 of them :)
<LnL>
I created a pr for the nix installer, but I should also update my boostrap script