| 24 Nov 2024 |
 trofi | Is meson build system on nix-2.25 intended to be used to buix nix on systems that don't yet have nix running? If it is how do you pass options to subprojects from the top level? This seems to fail (the option is in src/libstore/meson.options):
$ meson setup .. -Dsandbox-shell=/bin/sh
...
../meson.build:4:0: ERROR: Unknown options: "sandbox-shell"
| 11:56:26 |
| trofi | In reply to @trofi:matrix.org
nix-2.25.0 does not build against latest release of libgit2 as src/libfetchers/git-utils.cc:288:13: error: ‘git_mempack_write_thin_pack’ was not declared in this scope. It looks like it depends on unreleased feature: https://github.com/libgit2/libgit2/commit/f9c35fb50998d1c9d26293a18ade3d7c32f6ecb0. Is it intentional? I would hope for a silently disabled feature rather than hard build failure. I see people keep encountering libgit2 failures: https://github.com/NixOS/nix/issues/11925 | 12:04:20 |
|  Matej Urbas joined the room. | 13:11:54 |
| trofi | * Is meson build system on nix-2.25 intended to be used to buix nix on systems that don't yet have nix running? If it is how do you pass options to subprojects from the top level? This seems to fail (the option is in src/libstore/meson.options):
$ meson setup .. -Dsandbox-shell=/bin/sh
...
../meson.build:4:0: ERROR: Unknown options: "sandbox-shell"
UPDATE: meson setup .. -Dlibstore:sandbox-shell=/bin/sh does work (https://mesonbuild.com/Subprojects.html)
| 16:54:08 |
 Mic92 | In reply to @p14:matrix.org
I have nix build going in a loop and I'm unable to ctrl-C it. :(. It's just doing a lot of time in 'getting git revision count of /path/to/nixpkgs', and if the process gets killed, it just goes straight into the next nix build and my shell isn't having a change to see the CTRL-C for the shell while loop. Try nix build -f . instead. | 21:08:03 |
 p14 | In reply to @joerg:thalheim.io
Try nix build -f . instead. I ended up going this route, thanks! | 21:08:38 |
| 25 Nov 2024 |
 Robert Hensing (roberth) | In reply to @joerg:thalheim.io
Robert Hensing (roberth): did you not fix some json parsing error the other day? ported, but it seems to be not a complete fix | 08:19:32 |
| Robert Hensing (roberth) | not merged yet either | 08:19:39 |
|  @nullcube:matrix.org joined the room. | 09:59:30 |
|  @aloisw:julia0815.de joined the room. | 17:57:15 |
|  @aloisw:kde.org left the room. | 17:58:07 |
 John Ericson | emily: check out https://github.com/NixOS/nix/issues/11954 and https://github.com/NixOS/nix/issues/11955 re those CA derivation Nixpkgs PRs btw | 19:09:59 |
| John Ericson | I know finally understand what trofi was doing long ago in mkDerivation, and I agree that's the right thing to do for now | 19:10:24 |
| John Ericson | I think I have a decent plan for making things optimized in the CA world, but it should wait until after CA stabilization | 19:10:58 |
 emily | that quasi-derivation stuff makes me think about Ninja validations (probably because I was just talking about them rather than because they're super directly related, but they do involve tweaking build graph semantics), do you know about those? | 19:27:28 |
| John Ericson | emily: oh I don't know those | 19:28:23 |
| John Ericson | sounds like a good thing to read about ;) | 19:28:28 |
| John Ericson | * sounds like a good thing to read about :) | 19:28:32 |
| emily | In reply to @Ericson2314:matrix.org
emily: oh I don't know those https://ninja-build.org/manual.html#validations basically, we could extend the build graph with nodes that you can attach to another node that
(a) run after that node's completion and get to use its outputs;
(b) don't block the builds of things downstream of that node; but
(c) if they fail, the node they're attached to itself is considered to have failed | 19:29:35 |
| emily | in a world where we split up check phases from main derivations, this would mean that you could run LLVM's tests in parallel with building things that use that LLVM | 19:29:54 |
| John Ericson | oh interesting point via speculative execution | 19:30:03 |
| emily | and have it and everything downstream be considered to have failed if the tests fail | 19:30:07 |
| John Ericson | that's great | 19:30:11 |
| emily | currently lots of things are blocked on slow tests | 19:30:13 |
| emily | we could gain a huge amount of parallelization if tests were taken out of the critical path entirely like this | 19:30:24 |
| John Ericson | for tests I was just thinking "well, depend on the underlying builds at your own risk" | 19:30:33 |
| John Ericson | but yes this could be used with that | 19:30:40 |
| emily | yeah, but if you avoid depending on the underlying derivation it still means that tests become a blocking thing :) | 19:30:56 |
| emily | (this came up in the context of a long discussion about dynamic library stubs / relinking to avoid mass rebuilds from ABI-compatible library changes, https://discourse.nixos.org/t/why-does-the-nixos-infrastructure-have-to-be-hosted-in-a-centralized-way/46789/32 onwards but it's quite long) | 19:31:49 |
| emily | anyway, +1 to everything that gets rid of the phantom dependencies at the Nix level | 19:32:04 |
