| 10 Oct 2021 |
 balsoft | Yeah it evals and builds fine | 20:23:22 |
 tomberek | Well. You may be getting lucky that the references exist in your store already. It’s possible that can result in dangling references. | 22:05:57 |
| balsoft | That's true | 22:06:12 |
| balsoft | Maybe we should solve that with a simple stupid solution and just force all the references to be built in the addPath function? | 22:06:57 |
| 11 Oct 2021 |
| tomberek | Perhaps, but I’m not sure what semantics or evaluation properties need to be preserved. | 00:52:01 |
| balsoft | In reply to @tomberek:matrix.org
Well. You may be getting lucky that the references exist in your store already. It’s possible that can result in dangling references. Wait, how can referenced paths not exist in the store if these are runtime references, and the path is already in nix store? Doesn't nix do a pretty good job at making sure all the runtime deps are always in the store if the dependent is in the store? | 06:53:11 |
| balsoft | The only problem I can think of is that applying a filter can make some references obsolete | 06:54:11 |
| balsoft | E.g. if you have /nix/store/our-drv/foo -> /nix/store/bar, /nix/store/our-drv/goo -> /nix/store/doo and then you filter out foo, you now have a store path that references bar but never actually links to it in any way | 06:55:19 |
| tomberek | This check was overly restrictive and inaccurate, since it's not about having a context but about having references. We can't copy a path if it has references, since we don't propagate the references to the resulting path.
from PR - eelco. I'm not sure if that's a "we can't propagate" or "we don't (yet) propagate"
| 06:56:37 |
| balsoft | Ahhh, ok, I see | 06:56:52 |
| balsoft | In that case we should probably not propagate the references, but search for them again in the new filtered path | 06:57:43 |
| tomberek | * This check was overly restrictive and inaccurate, since it's not about having a context but about having references. We can't copy a path if it has references, since we don't propagate the references to the resulting path.
from PR - eelco. I'm not sure if that's a "we can't propagate" or "we don't (yet) propagate" or "shouldn't propagate because it's a bad idea"
| 06:57:44 |
| balsoft | In reply to @balsoft:balsoft.ru
E.g. if you have /nix/store/our-drv/foo -> /nix/store/bar, /nix/store/our-drv/goo -> /nix/store/doo and then you filter out foo, you now have a store path that references bar but never actually links to it in any way (to avoid this) | 06:57:59 |
| 12 Oct 2021 |
|  sebass joined the room. | 14:10:59 |
|  slby joined the room. | 18:26:25 |
| 13 Oct 2021 |
| tomberek | baloo: preloadNSS patch is causing a DNS lookup to "this.pre-initializes...", and in some cases takes 5 seconds to timeout. (this runs even for nix --version. I've not yet fully investigated, but I am on captive portal DHCP. Otherwise a fairly normal NixOS config. | 12:37:17 |
 baloo | Ha | 13:26:29 |
| baloo | Any chance you could strace nix —version and put that on a gist for me?
With your captive portal (just to make sure) | 13:29:10 |
| tomberek | baloo: https://gist.github.com/tomberek/0b2655fec8f0fdaabc233d5c880e74d5 | 15:09:22 |
| baloo | this is interesting, it looks like it actually gets a response | 15:11:31 |
| baloo | but ... | 15:12:33 |
 NinjaTrappeur | 
Download 56ac7c8db6d1afb677c98f717efdf1e3d2219c1aae8cc45c911c40d7b45af591-kAjR3I8.png | 15:12:35 |
| baloo | the request id is ... wrong | 15:12:40 |
| baloo | what | 15:12:44 |
| baloo | how is that possible | 15:12:47 |
| NinjaTrappeur | The --help output of Nix 2.4 looks pretty weird WRT. colors. | 15:12:48 |
| NinjaTrappeur | IS that done on purpose or is this a config issue of the doc output? | 15:13:05 |
| balsoft | In reply to @ninjatrappeur:matrix.org
IS that done on purpose or is this a config issue of the doc output? I think it's fixed now | 15:13:20 |
| balsoft | 
Download clipboard.png | 15:13:29 |
| baloo | https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.1 | 15:13:38 |
