| 1 Sep 2021 |
 niksnut | yes | 16:43:18 |
 Robert Hensing (roberth) | In reply to @roberthensing:matrix.org
nix flake update <inputName> would make most sense to me can it be changed to this? | 16:44:10 |
| Robert Hensing (roberth) | so it's all by default, or the closure of specified inputs | 16:44:49 |
| Robert Hensing (roberth) | you know what, this is probably better to discuss on github, so the discussion is more discoverable | 16:50:54 |
| niksnut | In reply to @roberthensing:matrix.org
can it be changed to this? No because nix flake update takes an optional flakeref (like nix flake update /path) so this would be ambiguous. | 19:48:36 |
| Robert Hensing (roberth) | right. I've never wanted to do that. Most package managers just operate on the working directory | 20:43:41 |
 Las | I never realized that the flake URI parameter to nix flake update was the flake whose inputs you wanted to update, and not the URI of the input you wanted to update... | 20:47:04 |
| Las | This is honestly quite counterintuitive | 20:47:26 |
 Jan Tojnar | yeah, for example npm has --prefix option for that | 23:23:09 |
| Jan Tojnar | * yeah, for example, npm has --prefix option for that | 23:23:20 |
| 2 Sep 2021 |
| niksnut | In reply to @Las:matrix.org
This is honestly quite counterintuitive Except that it's what every other nix command does, so it would be very inconsistent if nix flake update suddenly did something else. | 07:14:57 |
 tomberek | I made a similar mistake in assumption, but the consistency is nice and more powerful once I understood it. Perhaps a warning output clarifying what is being updated? | 07:17:20 |
| Jan Tojnar | yeah consistency is nice but not at the cost of ergonomy | 13:58:53 |
| Jan Tojnar | if 99% of time you want to update stuff in the current directory, the consistency is rather annoying | 13:59:37 |
| 3 Sep 2021 |
|  Rev. CornWallace III (novus ordo seclorum) changed their display name from cw (just got delta) to cw (novus ordo seclorum). | 07:40:59 |
| 6 Sep 2021 |
|  Bramfatur left the room. | 13:31:12 |
 trofi | Does nix implement network sandbox? Updated nixUnstable today and now getting fetch failrues:
nix build -f . libssh2 --keep-going
warning: error: unable to download 'https://www.libssh2.org/download/libssh2-1.10.0.tar.gz': Couldn't resolve host name (6); retrying in 352 ms
6 is probably a ENXIO. I'm not sure which process gets a rejection. Probably a nix-daemon itself? I suspect it's due to systemd resolved's nameserver 127.0.0.53.
| 21:42:53 |
| trofi | Disabling sandbox with sandbox = false fixes downloader. | 22:08:42 |
 sterni | trofi: https://github.com/NixOS/nix/issues/5089 | 23:27:46 |
| 7 Sep 2021 |
| trofi | Aha, thank you! | 06:37:20 |
| Las | In reply to @trofi:matrix.org
Does nix implement network sandbox? Updated nixUnstable today and now getting fetch failrues:
nix build -f . libssh2 --keep-going
warning: error: unable to download 'https://www.libssh2.org/download/libssh2-1.10.0.tar.gz': Couldn't resolve host name (6); retrying in 352 ms
6 is probably a ENXIO. I'm not sure which process gets a rejection. Probably a nix-daemon itself? I suspect it's due to systemd resolved's nameserver 127.0.0.53.
Access to the network has always been restricted, except in fixed-output derivations | 09:15:59 |
| trofi | How that restriction is implemented? Is it some systemd unit magic? Or some in-daemon code? I only found a few seemingly irrelevant filesystem syscall filters. | 10:15:21 |
| Las | trofi: Linux namespaces | 10:48:04 |
| Robert Hensing (roberth) | trofi: sounds like https://github.com/NixOS/nixpkgs/pull/135689 but that's nix 2.3 🤔 | 11:00:49 |
 John Ericson | sterni: i did some stuff with the strong context | 19:02:05 |
| John Ericson | make it support more ! | 19:02:09 |
| John Ericson | it's possible that makes a difference | 19:02:19 |
| sterni | hm maybe I should check on your branch what kind of context "${foo.drvPath}" yields | 19:03:07 |
| John Ericson | sterni: yeah | 19:04:37 |
| sterni | John Ericson: behavior is unchanged:
nix-repl> :p builtins.getContext "${pkgs.hello.drvPath}"
{ "/nix/store/6zfl66ni351nk0i2wa7ssbaacgysrcm5-hello-2.10.drv" = { allOutputs = true; }; }
Intuitively I feel like this should be { path = true; }, but not sure if something relies on this behavior?
| 22:08:53 |
