<copumpkin>
niksnut: any hunches about the workers not getting cleaned up in --check mode?
<shlevy>
zimbatm: just trying to build tensorflow
<zimbatm>
ah ok :)
<copumpkin>
shlevy: you're learning!
<copumpkin>
erm, your machine will be
<shlevy>
copumpkin: My colleague's machine will be!
<gchristensen>
copumpkin: boo, hiss :)
<copumpkin>
:P
<pstn>
Is there a specific reason for not setting nix.daemonNiceLevel to 19?
<pstn>
(as a new default for everybody)
<niksnut>
copumpkin: no
Sonarpulse has joined #nixos-dev
<niksnut>
copumpkin: I've pushed a fix
<copumpkin>
nice :)
<copumpkin>
so we can still observe purity :D
ma27 has quit [Ping timeout: 256 seconds]
<copumpkin>
okay, I'm baffled
<copumpkin>
even with a nix build of it, my "fix" for builtinFetchurl seems to not work anymore
<shlevy>
Looks like the tensorflow build is building a vendored copy of llvm :'(
<copumpkin>
of course it is
<copumpkin>
google loves vendoring
<shlevy>
And now building curl...
<copumpkin>
I wish google would just keep its software to itself ;)
* gchristensen
muttering, "and languages"
<shlevy>
What we really need is a spy
<shlevy>
A googler committed to the nix cause
<shlevy>
who can influence them in the right direction
<copumpkin>
niksnut: I think part of the pain of trying to do stuff in builtinFetchurl is that it seems tricky to get log messages out to see them. writeFull(STDERR_FILENO, "foo\n"); doesn't seem to spit anything out even with -vvvvv. Is there a better place
<copumpkin>
I'm trying to understand why the rewrite I thought was working doesn't seem to work anymore
<niksnut>
copumpkin: doesn't printError work?
* copumpkin
tries
<shlevy>
welp time to rebuild openjdk
<copumpkin>
niksnut: if it is working, I'm not seeing it :/
<copumpkin>
niksnut: I literally have it sitting right in front of the builtinFetchurl call and am realizing a builtin:fetchurl derivation and not seeing it get printed with -vvvvv
<copumpkin>
I think it's time to buy a new computer
<copumpkin>
this one is haunted
<vcunat>
gchristensen: can you restart nix daemon on t2-4? There's a job hanging for eight ours, blocking 17.09-small channel from glibc security update: https://hydra.nixos.org/build/67749807
<vcunat>
*eight hours
<Mic92>
shlevy: we have some people working at google.
<Mic92>
maybe not enough
<copumpkin>
oh shit, that'
<copumpkin>
s why I'm haunted
<copumpkin>
I'm using the daemon
<niksnut>
there is some special handling going on in builtins
<niksnut>
logger = makeJSONLogger(*logger);
<copumpkin>
so no matter what my nix build is doing, it's not getting used
<copumpkin>
*frustrated sigh*
<copumpkin>
niksnut: yeah, I'm doing this from build.cc though so I'm not actually in the builtin yet. The issue is just the daemon I mentioned above
<copumpkin>
just wasted a couple of hours on that
<copumpkin>
(I just upgraded from single user to multi-user last night so was not used to it)
<copumpkin>
niksnut: can I force 1.12 to write directly to store (as root or whatever) and ignore the daemon?
<copumpkin>
or how do you test nix build stuff with a daemon install?
<Mic92>
niksnut: unset NIX_DAEMON
<Mic92>
i mean copumpkin
<niksnut>
right
<copumpkin>
that stopped working in 1.12 I think
<copumpkin>
doesn't it use writability of the store as a measure?
<copumpkin>
yeah, even with unset NIX_DAEMON it's using the daemon
<copumpkin>
yeah, sudo + unset NIX_DAEMON still tries to use the socket
<LnL>
chown $USER /nix/var/nix/db
<copumpkin>
feels awkward if I'm just trying to test my fix in the nix build
<copumpkin>
but I'll try that, thanks
<Mic92>
chown -$
<Mic92>
chown -$
<Mic92>
chown -R
<Mic92>
damn key
<LnL>
ah yes
<copumpkin>
anyway, end result is that I think my #1805 fix is actually valid
<copumpkin>
and I just upgraded to multi-user install overnight and that's what made me think it was b0rked
<LnL>
that's what I was saying earlier
<copumpkin>
dammit ,I missed that message from you :)
<copumpkin>
niksnut: why does builtins:fetchurl even use an isolated subprocess?
<copumpkin>
it seems like it could be integrated with the parent
<LnL>
testing stuff with build-remote is even more annoying, I had to rebuild switch to my development version on 2 machines
<Mic92>
copumpkin: can't you use dtrace to track this down?
<Mic92>
on linux I have sysdig and bcc at my fingertips
<copumpkin>
nah I've figured it out now
<copumpkin>
at least the one I thought I'd fixed last night
<copumpkin>
it turns out I had fixed it, and then I hid my fix behind the daemon
<copumpkin>
was just wondering why there's a subprocess because Nix is leaking build users
<copumpkin>
niksnut: if you can tell me the right place to rewrite the strings in build.cc, I can experiment with doing it your way, which as I said I like better too.
<copumpkin>
I'm just having trouble following the control flow and being confident that it won't confuse some other obscure corner of the code if I change the outputs in the drv
<Sonarpulse>
fpletz: how does 735d3588f3add9d5f0f39cdb62c194080b395672 look to you?
<Sonarpulse>
its a change to fetchPatch I need for ghc cross stuff
<fpletz>
Sonarpulse: imho the logic that an empty string adds the prefixes is a bit weird but I can think of nothing fancier right now, so :+1:
<fpletz>
Sonarpulse: did you check if the hashes stay the same?
<Sonarpulse>
fpletz: cool, thanks!
<Sonarpulse>
fpletz: pretty sure, but I'll double check
<fpletz>
yeah, they should, but just to be sure :)
<fpletz>
thanks!
<Sonarpulse>
you got any good tricks for checking that for fixed output derivations?
<Sonarpulse>
other than edditing the hash and looking for an error?
<copumpkin>
funny you should ask that
<Sonarpulse>
:D
<copumpkin>
that's exactly what I'm trying to fix in nix right now :P
<copumpkin>
#1805
<copumpkin>
(to make --check work properly on them)
<copumpkin>
niksnut, gchristensen: this is related to that question I raised a few weeks ago, btw
<fpletz>
copumpkin: awesome!
<fpletz>
Sonarpulse: not sure if nix-prefetch-url -A would work on those, but the patches argument to mkDerivation is probably not accessible anyway iirc
<Sonarpulse>
fpletz: it is accessible, but it won't work because of the postBuild stuff
<Sonarpulse>
got bitten by that already :D
<fpletz>
oh, ok :)
<vcunat>
same problem for glibc patches
<Sonarpulse>
fpletz: tested with and without the a+b prefixes
<FRidh>
What do you think about a Nix option for specifying paths inside store paths that may provide setuid executables. E.g., `permit-setuid-paths = "/bin/ping"`. Of course one could still create malicious executables that way, but you should not just run arbitrary executables from the store.
<LnL>
isn't that possible already with build-sandbox-paths
<copumpkin>
FRidh: as in an --option?
<FRidh>
copumpkin: yes
<FRidh>
We should not use it for nixos, but for other purposes it may be convenient.
<copumpkin>
what's a use case for that look like? a single nix-build invocation with --option permit-setuid-paths could run a ton of builds
<FRidh>
I happen to have a case where I need to create and a setuid executable
<gchristensen>
seems scary
<gchristensen>
and like an invariant I'd really like to avoid breaking
<FRidh>
in this case it's a custom solution for deploying Nix --out-links with builds
<FRidh>
but again, it's minor thing to just add setuid after the build
<catern>
what is the issue with just copying and setting setuid on the copy?
<catern>
imo setuid should not be enabled in nix in any way, it is a relic of history and should be eliminated
<copumpkin>
I could imagine some sort of special derivation type that just takes another derivation and setuids certain executables in it while symlinking the others, if the source derivation is explicitly marked as trusted somehow
<copumpkin>
but that seems like a bit of a UX PITA
<copumpkin>
"builtin:setuidwrappers" as a primitive builder type?
<copumpkin>
would check against a list of trusted derivations and refuse to setuid otherwise
<gchristensen>
please no :o
<FRidh>
heh
<copumpkin>
then we "just" need to figure out how to distribute that list of trusted derivations :)
<gchristensen>
nosuid on /nix/store is really valuable
<copumpkin>
just noodling
<copumpkin>
trust of the nix store is an ongoing thorn in our sides :)
<copumpkin>
both for secret data in it and things like setuid
<FRidh>
Created a Nix 1.12 multi-user installation with store and config at a custom location. Users can do builds here and then sync the out-links and store paths to the rest of the network. No more issues with binaries that don't work on certain machines because of different OS/libraries. Hopefully some day we get Nix on all machines.
<gchristensen>
copumpkin: it has a simple trust model, which I think is part of why it is so valuable
<gchristensen>
if we complicate it, we open up a lot of potential problems
MichaelRaskin has joined #nixos-dev
<LnL>
heh, the setuid wrappers are too safe to use them in the sandbox
orivej has quit [Ping timeout: 248 seconds]
vcunat has quit [Ping timeout: 255 seconds]
pie__ has joined #nixos-dev
ma27 has joined #nixos-dev
<andi->
gchristensen: was there a failing build output of openjdk earlier? Just now came back to the computer.
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
<copumpkin>
niksnut: now I'm just confused :) it seems like some of the hash rewrites might be getting lost with the current code structure, but I must be missing something