| 2 Dec 2025 |
 aloisw | Ah, so you want more a targeted --option substitute false than more convenient --rebuild? | 20:11:05 |
 522 it/its ⛯ΘΔ | i basically want "give me an output directory that was built on this device right now", yeah | 20:12:03 |
| 522 it/its ⛯ΘΔ | so "don't give me what's in the nix store if it's in there already, don't fetch it from caches" | 20:12:20 |
 K900 | I feel like --check should even build twice by default | 20:12:27 |
| K900 | And --rebuild should build or rebuild, yeah | 20:12:34 |
| 522 it/its ⛯ΘΔ | there's a cppnix flag to let you specify a number of times to build + rebuild iirc | 20:12:48 |
| 522 it/its ⛯ΘΔ | not in lix tho | 20:12:51 |
| aloisw | In reply to @k900:0upti.me
And --rebuild should build or rebuild, yeah IIRC they are the same, just inconsistently named. | 20:13:37 |
| 522 it/its ⛯ΘΔ | yeah | 20:13:43 |
| 522 it/its ⛯ΘΔ | one's nix build and one's nix-build | 20:13:50 |
| K900 | Yes but they should be consistently named and also do different things | 20:14:02 |
| 522 it/its ⛯ΘΔ | https://nix.dev/manual/nix/2.28/release-notes/rl-1.11.html?highlight=--option%20build-repeat | 20:15:02 |
| 522 it/its ⛯ΘΔ | okay so build-repeat N is moreso for hydra | 20:15:41 |
| aloisw | In reply to @k900:0upti.me
Yes but they should be consistently named and also do different things What different things? Basically I see 3 possibilities: rebuild or fail (current behaviour, probably garbage), always do a local build (522's suggestion, makes sense but both names are shit for that), and ensure a rebuild (potentially substituting or building before if it didn't exist). | 20:20:41 |
| K900 | --rebuild - ignore existing paths and substitutes, do a clean build, even if not currently in the store
--check - do two clean builds, diff them, keep both outpaths if different | 20:23:30 |
| K900 | * | 20:24:27 |
| aloisw | Yeah I think --rebuild is a garbage name for that. | 20:25:21 |
| K900 | I think it's suboptimal but overall whatever it's fine | 20:26:00 |
| aloisw | I guess there would also be a fourth option of ensuring it has been built locally at least once, but not sure how useful that is. | 20:29:14 |
| 522 it/its ⛯ΘΔ | another way to look at it is have flags for "don't look in the nix store for the direct derivation being built" and "which substitutors should we use for the direct derivation?"
(which would also let you easily ask if 2 caches agree on the output of a given .drv without needing to implement fetching code yourself, if that's useful) | 20:29:52 |
 raitobezarius | i didn't see it but | 22:09:56 |
| raitobezarius | https://git.lix.systems/lix-project/lix/issues/485 | 22:10:20 |
| raitobezarius | it's part of 2.95 milestone | 22:10:26 |
| raitobezarius | that is, --rebuild/--check will automatically produce the first derivation from now on and perform the check right after | 22:10:41 |
| raitobezarius | (this is independent from the naming discussions on which I think I agree) | 22:11:31 |
| raitobezarius | interesting | 22:12:37 |
| raitobezarius | i feel like we don't have an issue for it | 22:12:42 |
| raitobezarius | i feel like the generalized flag for this idea one that uses the deriver concept | 22:14:28 |
| raitobezarius | nix-build --requires-deriver local or something | 22:14:41 |
 xored | can someone explain to me why lix is this weird? ```[root@shiva:~]# cat /etc/resolv.conf
This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
Do not edit.
This file might be symlinked as /etc/resolv.conf. If you're looking at
/etc/resolv.conf and seeing this text, you have followed the symlink.
This is a dynamic resolv.conf file for connecting local clients to the
internal DNS stub resolver of systemd-resolved. This file lists all
configured search domains.
Run "resolvectl status" to see details about the uplink DNS servers
currently in use.
Third party programs should typically not access this file directly, but only
through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
different way, replace this symlink by a static file or a different symlink.
See man:systemd-resolved.service(8) for details about the supported modes of
operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0 trust-ad
search .
[root@shiva:~]# nix-build -E '(import <nixpkgs> {}).runCommand "test" {outputHashMode = "recursive"; outputHash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";} "cat /etc/resolv.conf"'
this derivation will be built:
/nix/store/qnd72abhlx97l63pppg9n23nwcnm00fl-test.drv
building '/nix/store/qnd72abhlx97l63pppg9n23nwcnm00fl-test.drv'...
This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
Do not edit.
This file might be symlinked as /etc/resolv.conf. If you're looking at
/etc/resolv.conf and seeing this text, you have followed the symlink.
This is a dynamic resolv.conf file for connecting local clients to the
internal DNS stub resolver of systemd-resolved. This file lists all
configured search domains.
Run "resolvectl status" to see details about the uplink DNS servers
currently in use.
Third party programs should typically not access this file directly, but only
through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
different way, replace this symlink by a static file or a different symlink.
See man:systemd-resolved.service(8) for details about the supported modes of
operation for /etc/resolv.conf.
options edns0 trust-ad
search .
nameserver 169.254.1.1
nameserver 64:ff9b:1:4b8e:472e:a5c8:a9fe:0101```
apparently there's a thing called pasta and I saw some resolvconf rewrite in the code, whatever the case, if my host is ipv6 only I get no dns in the sandbox, looks like a bug
| 23:02:25 |
