zzamboni1 has quit [Remote host closed the connection]
jtojnar has quit [Remote host closed the connection]
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<niksnut>
hm, the "gdb" package does not contain bin/gdb on darwin...
<dtz>
lol! D:
<dtz>
it had one job... xD
<dtz>
lldb? O:)
<LnL>
heh, basically it's empty
<niksnut>
*** This configuration is not supported in the following subdirectories:
<niksnut>
zlib gdb sim
<dtz>
lol
prooftechnique_ is now known as prooftechnique
propumpkin is now known as contrapumpkin
<contrapumpkin>
niksnut: neither of them can really work sensibly
<contrapumpkin>
unless you use nix-darwin
<contrapumpkin>
and even then it's tricky/iffy
<contrapumpkin>
a nastier version of the setuid problem
<contrapumpkin>
so we've never really put much effort against them
<contrapumpkin>
we could adopt some sort of hybrid hydra approach but it's a bit of a mess
<contrapumpkin>
and you probably wouldn't want hydra signing binaries for correctness :)
<contrapumpkin>
the hybrid approach, for the record, would be something like: create a build on hydra only that if explicitly approved by <key set of people> will actually apply an apple-endorsed signature to the generated binaries
<contrapumpkin>
that's the only way I can see it working without a local signing cert (the nix-darwin route) which largely kills the point of the signature mechanism in the first place
<contrapumpkin>
(although we could also integrate nix with the macOS keychain to improve that story a little bit)
<LnL>
well everytime you sign something you need to authenticate
<LnL>
and I only have some wip changes for that on a branch
<contrapumpkin>
I have a couple of fears about that: the macOS keychain's way of authenticating programs is lacking
<contrapumpkin>
and is basically unsafe if you call it from a script
<contrapumpkin>
because it authenticates the binary, not the binary+script
<contrapumpkin>
so if you call it from python, for example, and it asks you if you want to allow python to access the keychain item, it'll let /usr/bin/python access the keychain item
<contrapumpkin>
which is probably not what you want
<contrapumpkin>
same with /usr/bin/security or our nix package of the same tool
<contrapumpkin>
I sort of wish they'd kill the keychain access operations in /usr/bin/security, because they're never safe
<LnL>
yeah, true
<copumpkin>
anyway, *shrug* :)
<copumpkin>
I don't know what the right answer is
<copumpkin>
a hydra with a signing cert is probably not the worst answer, but would require some work on the hydra admin side
<copumpkin>
since most people aren't building their own LLVM/GDB
<copumpkin>
and just want a debugger
<LnL>
that's kind of impure tho
<copumpkin>
oh definitely
<LnL>
how would that work with caches / local builds
<copumpkin>
it wouldn't, really. I'd probably create a passthru.signed = builtins.signMacBinaries [ "bin/lldb" ] self; on the lldb derivation and then arrange the top-level attributes to point at .signed unless you ask for the unsigned one (since the unsigned one is rarely useful, and if you're debugging the lldb build yourself, you might need a local certificate to test the binaries)
<copumpkin>
could even use the new plugins mechanism :P
<copumpkin>
it's optimizing for the common case basically
<copumpkin>
which is someone just wanting nix-shell -p lldb
<copumpkin>
and wanting a working debugger
<LnL>
I agree, just not sure how I feel about more build impurities
<niksnut>
contrapumpkin: well, gdb did work for me at some point
<niksnut>
I may have done a manual chown or something though
<contrapumpkin>
how long ago? they started requiring a signed binary + entitlement a few major versions ago
<contrapumpkin>
(the binary always worked, but the OS won't let you attach to other processes unless you're signed)
<contrapumpkin>
(at least until the binary disappeared :P)
<prooftechnique>
Anyone seeing lots of CoreFoundation-related breakage on Darwin? Mainly trying to build Hoogle and some other tools
<prooftechnique>
I've been trying to mess around with adding cf-private and CoreFoundation to buildInputs as is done in some other packages, but I think I don't understand Nix scoping well enough to do it properly
<prooftechnique>
In particular, it complains that "file system sandbox blocked stat()" for the CoreFoundation dirs
elasticdog has quit [Ping timeout: 268 seconds]
elasticdog has joined #nix-darwin
elasticdog has quit [Ping timeout: 276 seconds]
elasticdog has joined #nix-darwin
jtojnar has joined #nix-darwin
<contrapumpkin>
prooftechnique: I haven't, but cf-private should largely not be necessary in 99% of cases
<contrapumpkin>
I think domenkozar got rid of most of it recently
<prooftechnique>
contrapumpkin: Can you build ghcWithHoogle on Darwin? I'd be delighted to find out that there's just some piece I'm missing to get it working.
<johnw>
prooftechnique: I use ghcWithHoogle on Darwin
<prooftechnique>
johnw: What version of macOS? I'm seeing the issue on 10.13.3
<prooftechnique>
I'm fully expecting this to be another "High Sierra breaks everything" situation