weechat doesn't build with sandbox turned off

[copumpkin]

Its cmake tries to be clever, finds our system Python.framework, and then fails when it tries to use it. With sandbox, it can't find Python.framework and then works. I don't see an obvious way to patch the stupidity out of cmake for this particular build. Perhaps it's time for someone to work on #25?

[wmertens]

Although I see 0 reason for disabling sandbox on Darwin...

On Mon, Feb 9, 2015, 7:11 AM Daniel Peebles notifications@github.com wrote:

Its cmake tries to be clever, finds our system Python.framework, and then fails when it tries to use it. With sandbox, it can't find Python.framework and then works. I don't see an obvious way to patch the stupidity out of cmake for this particular build. Perhaps it's time for someone to work on

25 https://github.com/copumpkin/nixpkgs/issues/25?

— Reply to this email directly or view it on GitHub https://github.com/copumpkin/nixpkgs/issues/50.

[copumpkin]

Yeah, but I also ideally don't want our correctness to depend on it being turned on. I run with it on by default, and think we should make the default be on for darwin, but it still feels cleaner for us to not have to rely on it.

[wmertens]

I dunno, it's pretty hard to prevent packages from finding things that are in their usual place... I'd rather have us spend time on more packages than on fixing things that can be prevented at such low cost...

On Mon, Feb 9, 2015, 7:50 AM Daniel Peebles notifications@github.com wrote:

Yeah, but I also ideally don't want our correctness to depend on it being turned on. I run with it on by default, and think we should make the default be on for darwin, but it still feels cleaner for us to not have to rely on it.

— Reply to this email directly or view it on GitHub https://github.com/copumpkin/nixpkgs/issues/50#issuecomment-73464620.

[copumpkin]

Talk it over with @shlevy :smile:! I was originally proposing that chroot status be part of the hash, which would give us a somewhat principled (i.e., not error-prone) way to avoid dealing with any of this stuff.

[wmertens]

So is there any reason to allow non-sandboxed builds on Darwin? Can't we just make it mandatory? @shlevy @edolstra?

On Mon Feb 09 2015 at 8:35:10 AM Daniel Peebles notifications@github.com wrote:

Talk it over with @shlevy https://github.com/shlevy [image: :smile:]! I was originally proposing that chroot status be part of the hash, which would give us a somewhat principled (i.e., not error-prone) way to avoid dealing with any of this stuff.

— Reply to this email directly or view it on GitHub https://github.com/copumpkin/nixpkgs/issues/50#issuecomment-73467869.

[shlevy]

Turning on sandbox by default is fine. Deciding that it's not worth fixing some divergence between sandboxed and not is fine. But IMO disabling non-sandboxed builds effectively changes the derivation model, given that the environment of execution is a big part of how builds work. If we're going to do that we should take time to do it right. And I'm not sure exactly what we gain by doing so.

In practical terms, while it's surely better than a million bind-mounts has anyone actually profiled the delta build time, including both setup and possible syscall overhead?

[wmertens]

@shlevy At what point would that number matter? If it's say, 5% slower, it's a no-brainer, but if it's 20% slower, would you prefer not using sandbox?

Personally I'm ok with 100% slower and that doesn't seem to be nearly the case...

On Mon, Feb 9, 2015, 3:17 PM Shea Levy notifications@github.com wrote:

Turning on sandbox by default is fine. Deciding that it's not worth fixing some divergence between sandboxed and not is fine. But IMO disabling non-sandboxed builds effectively changes the derivation model, given that the environment of execution is a big part of how builds work. If we're going to do that we should take time to do it right. And I'm not sure exactly what we gain by doing so.

In practical terms, while it's surely better than a million bind-mounts has anyone actually profiled the delta build time, including both setup and possible syscall overhead?

— Reply to this email directly or view it on GitHub https://github.com/copumpkin/nixpkgs/issues/50#issuecomment-73514889.

[copumpkin]

I see the sandbox as effectively giving us a NixOS-like filesystem structure in a non-NixOS system. Not sure if say it changes the entire model, unless I'm misunderstanding. Agree that we should test performance implications though :)

On Monday, February 9, 2015, Shea Levy notifications@github.com wrote:

Turning on sandbox by default is fine. Deciding that it's not worth fixing some divergence between sandboxed and not is fine. But IMO disabling non-sandboxed builds effectively changes the derivation model, given that the environment of execution is a big part of how builds work. If we're going to do that we should take time to do it right. And I'm not sure exactly what we gain by doing so.

In practical terms, while it's surely better than a million bind-mounts has anyone actually profiled the delta build time, including both setup and possible syscall overhead?

— Reply to this email directly or view it on GitHub https://github.com/copumpkin/nixpkgs/issues/50#issuecomment-73514889.

[shlevy]

One way to look at the derivation model is "run a process in a normal unix-type environment with a specific environment and set of arguments based on paths in a non-global namespace". Sandboxing changes the rules from a normal unix-type environment and makes it more complicated and less portable. Given that, I think there should be compelling reason to commit ourselves to using it.

nix works on non-NixOS linux boxes, which have worlds of impurities as well. If we don't need to diverge from simple and standard unix capabilities there, why do we need to here?

[wmertens]

Well there's /bin/sh which is not the bash version scripts might expect (array handling comes to mind in the one issue I saw about this). I've also had quite a few broken Darwin builds before the pure-darwin branch where it picked up libraries from /usr/local.

The same thing can happen on any distro, unless we go over each build with a fine-toothed comb. Basically we can try to fix all builds whenever we notice problems or we can turn on sandboxing/chroot and not worry.

Note BTW that the current chroot implementation on Linux is a bit slow due to creating a unique chroot per build, while that is in fact more than what is needed, a simple chroot valid for all builds would be fine in most cases too and that's portable.

On Mon Feb 09 2015 at 5:14:55 PM Shea Levy notifications@github.com wrote:

One way to look at the derivation model is "run a process in a normal unix-type environment with a specific environment and set of arguments based on paths in a non-global namespace". Sandboxing changes the rules from a normal unix-type environment and makes it more complicated and less portable. Given that, I think there should be compelling reason to commit ourselves to using it.

nix works on non-NixOS linux boxes, which have worlds of impurities as well. If we don't need to diverge from simple and standard unix capabilities there, why do we need to here?

— Reply to this email directly or view it on GitHub https://github.com/copumpkin/nixpkgs/issues/50#issuecomment-73536474.

[copumpkin]

Well we currently allow /bin/sh through the sandbox, unfortunately.

[wmertens]

oh right, and we can't really replace it with something else either :-( However, we could fast-track not having /bin/sh in the sandbox ;)

On Mon Feb 09 2015 at 10:22:34 PM Daniel Peebles notifications@github.com wrote:

Well we currently allow /bin/sh through the sandbox, unfortunately.

— Reply to this email directly or view it on GitHub https://github.com/copumpkin/nixpkgs/issues/50#issuecomment-73592816.