| 1 Mar 2024 |
 @johannes.kirschbauer:scs.ems.host | * Some background, currently i use a patched nix. It seems my patch spontaneously produces segfaults with clangStdenv only.
Q: why is the nix build system not reproducible ^^ | 11:31:17 |
| @johannes.kirschbauer:scs.ems.host | * Some background, currently i use a patched nix. It seems my patch spontaneously produces segfaults with clangStdenv only.
Q: why is the build of nix itself not reproducible ^^ | 11:31:41 |
| @johannes.kirschbauer:scs.ems.host | * Some background, currently i want to build a patched nix. It seems my patch spontaneously produces segfaults with clangStdenv only.
Q: why is the build of nix itself not reproducible ^^ | 11:35:05 |
|  tomberek set a profile picture. | 15:21:19 |
 Marc Jakobi | Download Vollmacht_fuer_Paketabholung.pdf | 19:10:38 |
 @jade_:matrix.org | In reply to @johannes.kirschbauer:scs.ems.host
just having fun today: using "nix#nix-clangStdenv" i get SIGSEGV (Address boundary error). But using "nix#nix" is fine.. no segfault.
I just dont understand whats the difference in this convoluted flake.nix file in the cpp nix repository.
Apart from that i would expect either both or none of the outputs to have segfault. gcc vs clang build | 19:17:24 |
| @jade_:matrix.org | segv doesn't tell you anything, please coredumpctl debug if this is Linux and give the back trace (type bt into gdb) | 19:18:08 |
| @jade_:matrix.org | thank you | 19:18:11 |
 Alyssa Ross | C++ is not ABI-compatible between GCC and Clang, so you can't build some things with GCC, some with Clang, and then link them together. | 19:19:04 |
| Alyssa Ross | If you override Nix to build with Clang, boost will still be built with GCC | 19:19:14 |
| Alyssa Ross | So it's not expected to work. | 19:19:29 |
| Alyssa Ross | If the Nix flake is doing this, it should stop. | 19:20:17 |
| Alyssa Ross | ah, but it looks like it actually overrides stdenv in an overlay, so I guess that should work? | 19:21:10 |
| Alyssa Ross | It's very hard to read | 19:21:12 |
| Alyssa Ross | Ah, no, the overlay only applies the custom stdenv to Nix | 19:22:26 |
| Alyssa Ross | So it won't work | 19:22:28 |
| Alyssa Ross | cc Ericson2314 | 19:22:30 |
| Alyssa Ross | (It might not actually be ABI compatibility that's the problem — I just remember that it's definitely not expected for this to work) | 19:31:41 |
 John Ericson | Alyssa Ross: if you are using --gcc-toolchain as we are on Linux, isn't it supposed to be ABI compatible? | 21:27:53 |
| John Ericson | (more precisely, it is using at least parts of libstdc++ and friends so the ABI is the same?) | 21:28:49 |
| John Ericson | I don't fully get it but I always do clang development builds (mainly out of habit) and don't think I had a problem yet | 21:29:28 |
| Alyssa Ross | hmm, maybe it is? | 21:31:15 |
| Alyssa Ross | I'm not sure | 21:31:26 |
 @qyriad:matrix.org | clangStdenv links libgcc and libstdc++ on Linux, as is the default for Clang on Linux | 23:37:45 |
| Alyssa Ross | I definitely remember it being a problem before, but maybe it wasn't always this way. | 23:39:51 |
| 2 Mar 2024 |
 @delroth:delroth.net | hi there - what is the current "tech stack" recommendation for writing new documentation for currently undocumented projects in the Nix ecosystem? in this case, mostly internal facing (github.com/nixos/infra), if it changes anything | 03:23:33 |
| @delroth:delroth.net | (my ideal requirements: proper multipage support with navigation, markdown or at least not docbook, preferably a stylesheet that's not straight out of the 90s) | 03:25:40 |
| @delroth:delroth.net | (this sounds like something which should be documented, maybe with templates, btw :P but I didn't find anything after some quick research) | 03:26:31 |
 danielsidhion | In reply to @delroth:delroth.net
hi there - what is the current "tech stack" recommendation for writing new documentation for currently undocumented projects in the Nix ecosystem? in this case, mostly internal facing (github.com/nixos/infra), if it changes anything There is no recommendation 🥲
We have at least 3 different toolchains used throughout all our docs and want to find a way to reduce that amount (ideally to 1 toolchain), but afaik we haven't yet put the effort to see what things would fit our needs the best | 05:05:46 |
| danielsidhion | I literally got started on this exploration today. I want to make some internal nixpkgs docs (all the readme.md files) more visible, so I'm on a similar path as you | 05:07:55 |
