| 21 Dec 2024 |
|  @stablejoy:matrix.org joined the room. | 06:43:25 |
 K900 | I think I brought this up before, but should we enable build-ids for everything | 07:36:51 |
 p14 | In reply to @k900:0upti.me
I think I brought this up before, but should we enable build-ids for everything Rationale? What are build-ids a function of and does it affect reproducible builds? (Presumably they don't, but would love to understand more what's going on and what they enable). | 11:03:43 |
| K900 | build-ids are basically a hash of the file | 11:11:21 |
| K900 | They're used for debug info matching | 11:11:28 |
| p14 | I see. Is there a pool of debug info somewhere I can easily utilise? | 11:12:08 |
| K900 | We don't build debug info for everything | 11:12:44 |
| K900 | But many things have it cached | 11:12:48 |
| K900 | You can use nixseparatedebuginfod | 11:12:52 |
| p14 | That's pretty cool; I'm wondering how does it connect thing being debugged to the derivation containing the separate debug info. Thinking aloud, presumably it does something like nix-store --query --deriver <path> and then look inside the derivation for the output named 'debug'. | 11:16:29 |
|  Dimitar joined the room. | 19:45:27 |
 Philip Taron (UTC-8) | I'd like to post this | 21:45:12 |
 Tristan Ross | In reply to @philiptaron:matrix.org
I'd like to post this On Discourse? | 21:47:20 |
| Philip Taron (UTC-8) | Yessir. | 21:47:27 |
| Tristan Ross | In reply to @philiptaron:matrix.org
Yessir. Sounds good | 21:48:30 |
| Tristan Ross | I'm thinking we can do a meeting sometime after the new year so we can figure things out for what the SC wants. | 21:50:31 |
| Philip Taron (UTC-8) | The sad (but also great) fact of the matter is that I'm most available over the next couple weeks, since I'm off of work. | 21:57:53 |
| Philip Taron (UTC-8) | Posted: https://discourse.nixos.org/t/community-team-updates/56458/11?u=philiptaron | 21:58:56 |
| Tristan Ross | Oh | 22:02:36 |
| Tristan Ross | Yeah, I'm available on Tuesday to Thursday this week | 22:03:56 |
| Tristan Ross | In reply to @philiptaron:matrix.org
Posted: https://discourse.nixos.org/t/community-team-updates/56458/11?u=philiptaron I thought you were meaning a different discourse post lol | 22:04:12 |
| Philip Taron (UTC-8) | 😬 | 22:04:42 |
| Tristan Ross | It's fine lol | 22:07:04 |
| Philip Taron (UTC-8) | I kept "who authored this" in there, so that if there's "hell no we aren't doing that" it would be clear where the stones ought to be thrown. Don't expect that, though. | 22:08:11 |
| Tristan Ross | Yeah lol | 22:08:42 |
| 22 Dec 2024 |
| Tristan Ross | There's a few things that I've been thinking of:
- Docs wise, try and promote using
packages.${system}.${name} over devShells due to runPhase and easy propagation of dependencies. inputsFrom is an option if a dev shell needs more stuff than just the package itself needs.
cpu attribute which tunes everything from FPU, CPU model, architecture, etc. Generic names could be supplied which sets all options.- CC without wrappers, possibly a shell hook which extends
CFLAGS or other things and adds the necessary flags we need.
stdenv without inheriting CC. Randy Eckenrode came up with this originally but I am thinking this might not be a bad idea. Tools like meson, cmake, etc could propagate cc which automatically should inject the hook.
| 04:27:06 |
| Tristan Ross | * There's a few things that I've been thinking of:
- Docs wise, try and promote using
packages.${system}.${name} over devShells due to runPhase and easy propagation of dependencies. inputsFrom is an option if a dev shell needs more stuff than just the package itself needs.
cpu attribute which tunes everything from FPU, CPU model, architecture, etc. Generic names could be supplied which sets all options. Support for different compilers would be better since it could have an attr set within each attribute that specifies what it should be for different compilers.- CC without wrappers, possibly a shell hook which extends
CFLAGS or other things and adds the necessary flags we need.
stdenv without inheriting CC. Randy Eckenrode came up with this originally but I am thinking this might not be a bad idea. Tools like meson, cmake, etc could propagate cc which automatically should inject the hook.
| 04:27:57 |
 Morgan (@numinit) | My $0.02 is that I'd definitely use option #2, especially when doing cross compiles | 04:29:20 |
| Tristan Ross | Yeah, #2 is something which I've been trying to work on for some time. I had a PR which adds a cpuModel attribute that is capable of it but it's been sitting stale from little to no reviews and constantly getting blocked with merge conflicts. | 04:31:32 |
| Tristan Ross | I likely would start fresh for doing #2 and drop the CPU model PR I originally made. Hopefully people could review that one and we could actually get it. | 04:32:10 |
