 | Lix | 1104 Members |
| Lix user channel. Feel free to discuss on-topic issues here and give each other help. For matrix.to links to the rest of the Lix channels, see: https://wiki.lix.systems/books/lix-organisation/page/matrix-rooms | 295 Servers |
| Lix | 1104 Members |
| Lix user channel. Feel free to discuss on-topic issues here and give each other help. For matrix.to links to the rest of the Lix channels, see: https://wiki.lix.systems/books/lix-organisation/page/matrix-rooms | 295 Servers |
| Sender | Message | Time |
|---|---|---|
| 2 Dec 2025 | ||
 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.meIIRC 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.meWhat 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 theinternal DNS stub resolver of systemd-resolved. This file lists allconfigured search domains.Run "resolvectl status" to see details about the uplink DNS serverscurrently in use.Third party programs should typically not access this file directly, but onlythrough the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in adifferent way, replace this symlink by a static file or a different symlink.See man:systemd-resolved.service(8) for details about the supported modes ofoperation for /etc/resolv.conf.nameserver 127.0.0.53 [root@shiva:~]# nix-build -E '(import <nixpkgs> {}).runCommand "test" {outputHashMode = "recursive"; outputHash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";} "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 theinternal DNS stub resolver of systemd-resolved. This file lists allconfigured search domains.Run "resolvectl status" to see details about the uplink DNS serverscurrently in use.Third party programs should typically not access this file directly, but onlythrough the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in adifferent way, replace this symlink by a static file or a different symlink.See man:systemd-resolved.service(8) for details about the supported modes ofoperation for /etc/resolv.conf.options edns0 trust-ad nameserver 169.254.1.1 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 |
 niklaskorz | big font time | 23:02:39 |
| xored | * can someone explain to me why lix is this weird? 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:03:12 |
| niklaskorz | thanks :D | 23:03:18 |
| xored | yeah I hate element's input man | 23:03:24 |
| xored | tl;dr on the sandbox the dns is all messed up | 23:03:42 |