| 13 Sep 2023 |
 Winter (she/her) | the only thing that differs is the order of the paths in the env vars | 23:29:08 |
| Winter (she/her) | however, something odd i noticed: | 23:29:19 |
| Winter (she/her) | in the "everything in nBI" case, the cmake generated C_INCLUDES variable in the Makefile contains a bunch of include paths that the "everything where they should be" case doesn't have | 23:30:03 |
| Winter (she/her) | but there's nothing different in the env vars that would cause that, afaict | 23:30:16 |
| Winter (she/her) | found it, i think | 23:47:01 |
| Winter (she/her) | wow i hate computers | 23:47:16 |
| 14 Sep 2023 |
 Artturin | In reply to @winterqt:nixos.dev
found it, i think What was it? | 02:04:43 |
| Winter (she/her) | In reply to @artturin:matrix.org
What was it? somewhat broken special casing in the thing i'm trying to build, plus weird (at least to me) setup hook behavior
i'm trying to figure the setup hook part out, so two questions:
we have two packages, A, and B. A has propagatedBuildInputs = [ B ]. B has a setup hook.
- what offset is used when you put A in buildInputs? it seems that it would be discarded because the calculated offsets are
0, 2.
- is it expected that if A was put into nativeBuildInputs, B's setup hook isn't ran?
| 13:02:47 |
 trofi | Will cross-post here for general amusement as well:
Fun fact: nix has headers-only nlohmann_json dependency in it's output closure and pipewire has python. Chances are https://github.com/NixOS/nixpkgs/pull/255192 will fix it (more words: https://trofi.github.io/posts/298-unexpected-runtime-dependencies-in-nixpkgs.html).
| 22:14:07 |
| 15 Sep 2023 |
| Artturin | In reply to @trofi:matrix.org
Will cross-post here for general amusement as well:
Fun fact: nix has headers-only nlohmann_json dependency in it's output closure and pipewire has python. Chances are https://github.com/NixOS/nixpkgs/pull/255192 will fix it (more words: https://trofi.github.io/posts/298-unexpected-runtime-dependencies-in-nixpkgs.html).
Could it cause https://github.com/NixOS/nixpkgs/issues/41340 | 01:19:42 |
| Artturin | * In reply to @trofi:matrix.org
Will cross-post here for general amusement as well:
Fun fact: nix has headers-only nlohmann_json dependency in it's output closure and pipewire has python. Chances are https://github.com/NixOS/nixpkgs/pull/255192 will fix it (more words: https://trofi.github.io/posts/298-unexpected-runtime-dependencies-in-nixpkgs.html).
Could it cause https://github.com/NixOS/nixpkgs/issues/41340 on large closures | 01:20:41 |
| Artturin | *
Could it cause https://github.com/NixOS/nixpkgs/issues/41340 on large closures
| 01:21:03 |
| trofi | Yup. I initially tried without deduping the argument and got failures on `qemu`. I'm sure it also makes the process forking slower. Would be nice if `nixpkgs` used response files for all of it`s unbounded argument lists :) | 05:46:22 |
| 16 Sep 2023 |
 p14 | I've got a pipeline of things I want to fix to make pkgsLLVM.pkgsStatic to work well, but review is going slow. I don't want to generate a mass of PRs which go unreviewed for a long time since that risks increasing the infinite TODO list for everybody. Any kind souls able to help me clear this review from the pipeline? I hope it is uncontroversial. https://github.com/NixOS/nixpkgs/pull/253116 | 09:07:47 |
| p14 | * [xpost from exotic nix targets] I've got a pipeline of things I want to fix to make pkgsLLVM.pkgsStatic to work well, but review is going slow. I don't want to generate a mass of PRs which go unreviewed for a long time since that risks increasing the infinite TODO list for everybody. Any kind souls able to help me clear this review from the pipeline? I hope it is uncontroversial. https://github.com/NixOS/nixpkgs/pull/253116 | 09:08:01 |
|  emily joined the room. | 12:38:24 |
| emily | stdenv/patch-shebangs fix: https://github.com/NixOS/nixpkgs/pull/255463 | 14:53:23 |
| 20 Sep 2023 |
| trofi | Quiz Question: how many arguments to a binary do you think you can pass as a maximum on Linux? :) (directly related to cc-wrapper abusing NIX_CFLAGS_COMPILE and friends). | 20:56:26 |
| 21 Sep 2023 |
| trofi | Spoilers (not a lot): https://trofi.github.io/posts/299-maximum-argument-count-on-linux-and-in-gcc.html | 18:38:01 |
|  dedmunwalk joined the room. | 23:09:44 |
| 24 Sep 2023 |
 Yureka (she/her) | In reply to @trofi:matrix.org
Spoilers (not a lot): https://trofi.github.io/posts/299-maximum-argument-count-on-linux-and-in-gcc.html I ran into similar issues when building Firefox and telegram desktop with musl libc | 14:46:32 |
| Yureka (she/her) | execve would fail because the environment was too large | 14:46:49 |
| trofi | I vaguely remember musl decided to do 128K long stacks (or similar). | 14:47:53 |
| Yureka (she/her) | Yeah, because that is also the max env size defined in Linux kernel headers | 14:48:31 |
| Yureka (she/her) | * Yeah, but also 128K or so is the max env size defined in Linux kernel headers | 14:48:57 |
| Yureka (she/her) | For compatibility reasons or something | 14:49:15 |
| trofi | Yeah, it's an arbitrary limit. Would be nice to increase it to 6M :) | 15:07:33 |
 problems | In reply to @yuka:yuka.dev
Yeah, because that is also the max env size defined in Linux kernel headers per variable that is | 15:25:41 |
| problems | a different maximum applies to the env as a whole, according to the article i think? | 15:26:16 |
| Artturin | In reply to @trofi:matrix.org
Yeah, it's an arbitrary limit. Would be nice to increase it to 6M :) better do it soon so we can use it in 3 years 😅 | 15:30:25 |
