<gchristensen>
hm not sure I'd like my builds to be able to do dns lookups in the sandbox
<domenkozar>
what if that was limited to /etc/hosts?
<domenkozar>
so you can only do it for 127.0.0.1?
<gchristensen>
would it leak my hostname?
<gchristensen>
would it leak ipv6 vs. ipv4 support? (localhost can point to one or the other or both) (these aren't arguments against it specifically, just curious)
<domenkozar>
I would imagine it uses /etc/hosts in reverse
<domenkozar>
so it would be deterministic and no leak anything afaik.
pie_ has joined #nixos-dev
<gchristensen>
neat
<gchristensen>
protocols and services ...
<gchristensen>
I'm thinking more and more this shouldn't be in Nix
<gchristensen>
but implemented as part of your build
<domenkozar>
that would require special nix.conf for each user :/
<domenkozar>
if you refer to extra sandbox files
<gchristensen>
don't make it impure :)
<domenkozar>
gchristensen: why do you think it shouldn't be in Nix
<domenkozar>
if it's deterministic?
<gchristensen>
brb
__Sander__ has quit [Quit: Konversation terminated!]
romildo has joined #nixos-dev
vcunat has joined #nixos-dev
__Sander__ has joined #nixos-dev
michaelpj_ has quit [Ping timeout: 240 seconds]
<gchristensen>
well the problem domenkozar is those files change not infrequently, and adding them via nix seems a bit strange, when it could be handled just fine by adding the protocols and services files in your build
<gchristensen>
so I think the lifecycle of those files don't match the lifecycle of the Nix program. additionally, they _change over time_ and your build maybe won't work properly if those files change between builds, so I think the data appropriately belongs as an input to your build
<domenkozar>
gchristensen: does it change that often?
<domenkozar>
I see, it's in iana-etc package
<gchristensen>
it certainly changes "periodically" but here's the definite kicker: your /etc/services and /etc/protocols is not the same as mine :)
<domenkozar>
I think we could have /etc/nsswitch setup statically (I really care about reverse dns)
<domenkozar>
gchristensen: my point is, it worked so far
<domenkozar>
by adding a few lines we can improve support for some tests that are currently disabled
<gchristensen>
aye
<gchristensen>
is it possible to set it up inside the build, though?
<gchristensen>
like maybe we could have a package with an activation hook which sets up rdns
<domenkozar>
next step could be for nix to expose setting these as attributes, but we'd have to think about security, etc
<gchristensen>
true
<gchristensen>
its not clear to me why the solution is in Nix though
<domenkozar>
I prefer to improve determinism globally for nix except per package
* domenkozar
remembers the days when LOTS of packages needed -lgcc_s
<gchristensen>
sure ... but we could put it in stdenv
<domenkozar>
I bet dogecoin eelco will be against adding a dns package there
<gchristensen>
haha fair
<domenkozar>
I see your point, don't get me wrong :)
<gchristensen>
I don't know the solution :P this is above my pay grade
<domenkozar>
lol
<domenkozar>
dammit, haskell people tell me it's easier to disable tests, nix people tell me we should modify stdenv
<domenkozar>
all I wanted was to run tests :P
<gchristensen>
haha
<gchristensen>
it sounds like the _first_ step is to try it in via what nix already provides, in your package
<domenkozar>
not sure I can
<domenkozar>
can't bind to 53
<domenkozar>
port 53
<domenkozar>
can't modify /etc/nsswitch.conf
<gchristensen>
ahhhhhhhh
<domenkozar>
best I can think of is nix.chrootDirs
<domenkozar>
but then I'll get reports sometimes tests fail
<domenkozar>
when folks won't bootstrap nix correctly
<__Sander__>
what about running the testcases in a VM?
<__Sander__>
in a Nix expression
<__Sander__>
by using the NixOS test driver facilities?
<gchristensen>
that seems promising
<__Sander__>
that's one of the main reasons the NixOS test driver was invented
<__Sander__>
I, for example, use it quite extensively to test disnix
<gchristensen>
fwiw it isn't uncommon for people to put custom stuff in services, and from there it wouldn't be unreasonable for test cases to also expect custom things in it. I reckon this is why I think it makes it not really a good part of Nix core
<vcunat>
right, providing DNS seems heavy enough to use a container or VM for the test
<Sonarpulse>
sphalerite: any luck recently getting rid of RPATHs?