| 19 Dec 2024 |
 Alexandros Liarokapis | * Hi All. Is this correct?
let mapOffset(h, t, i) = i + (if i <= 0 then h else t - 1)
dep(h0, t0, A, B)
propagated-dep(h1, t1, B, C)
h0 + h1 in {-1, 0, 1}
h0 + t1 in {-1, 0, -1}
----------------------------- Take immediate dependencies' propagated dependencies
propagated-dep(mapOffset(h0, t0, h1),
mapOffset(h0, t0, t1),
A, C)
| 14:57:47 |
| Alexandros Liarokapis | eg if propagated-dep(0, 1, C, D), dep(0, 1, B, C), dep(0, 1, A, B) then this results in propagated-dep(0, 1, B, D), propagated-dep(0, 1, A, D) | 15:02:06 |
|  yannis changed their display name from yannis to yannis|pto. | 21:24:10 |
| 20 Dec 2024 |
|  🐰 xiaoxiangmoe joined the room. | 13:59:03 |
 Tristan Ross | Since LLVM is getting UEFI toolchain support, we might be able to get a cross compiled stdenv set up for that. It would have to use LLVM libc though. | 19:55:36 |
 Philip Taron (UTC-8) | Good news for https://github.com/NixOS/nixpkgs/pull/353050 | 20:05:35 |
| Tristan Ross | In reply to @philiptaron:matrix.org
Good news for https://github.com/NixOS/nixpkgs/pull/353050 That's what I had in mind | 20:14:42 |
| Tristan Ross | pkgsCross.x86_64-uefi will be a thing | 20:15:06 |
 K900 | It really shouldn't be | 20:15:40 |
| K900 | Building arbitrary things for a UEFI target is generally not useful | 20:15:48 |
| Tristan Ross | True but it's possible using LLVM lol | 20:16:19 |
| K900 | It isn't | 20:16:41 |
| K900 | If you think just having a compiler target allows you to compile arbitrary things, that's not the case | 20:17:01 |
| K900 | And neither is having a libc, really | 20:17:09 |
| Tristan Ross | A lot of things would require patches to work but at least having a toolchain would be possible | 20:18:03 |
| Tristan Ross | I don't expect a whole lot to work | 20:18:48 |
| K900 | If you want to burn cycles on silly targets that LLVM supports just because LLVM supports them, do MSVC | 20:19:10 |
| K900 | At least that might actually be useful in like five years | 20:19:19 |
| 21 Dec 2024 |
|  stablejoy left the room. | 05:08:19 |
|  @dmiskovic:matrix.org left the room. | 05:14:00 |
| stablejoy 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 |
