| 18 Oct 2025 |
 Alyssa Ross | which nobody has ever cared about until a month or two ago | 12:21:44 |
| Alyssa Ross | (in Nixpkgs) | 12:21:49 |
| Alyssa Ross | or it does work with musl, but doesn't work with cross compilation to musl, which again isn't something anybody has generally bothered to test | 12:22:19 |
 matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | Okay but in this case, do you think they're shipping mesa with valgrind? | 12:22:36 |
| Alyssa Ross | easy to find out | 12:22:53 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | Our mesa is super heavy | 12:23:05 |
| Alyssa Ross | but I suspect probably not because Alpine tries to be small | 12:23:07 |
| Alyssa Ross | and that means less optional dependencies enabled by default | 12:23:18 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | Yes so I think there's a happy balance between conditionals and patches, and that not everything has to be an upstream patch | 12:23:47 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | like in this case valgrind is pretty heavy and maybe not all platforms should include valgrind | 12:24:04 |
| Alyssa Ross | if there's a principled criteria for that, sure | 12:24:18 |
| Alyssa Ross | but there's no fundamental reason we should include valgrind for GCC builds and not LLVM ones | 12:24:44 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | Sure, my discovery has highlighted two things:
- An issue with valgrind that needs to be fixed upstream
- Maybe valgrind is really heavy and we don't need it in mesa for all platforms
| 12:25:44 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | The reason Alpine has things working with mesa across the board is because they're compiling with less deps in general, so we're probably not going to have working musl for years unless we did the same | 12:26:24 |
| Alyssa Ross | we have a "working musl" | 12:26:36 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | Not always, I know my issue here is LLVM related only, but I've had similar circumstances | 12:26:57 |
| Alyssa Ross | yes, packages are broken sometimes | 12:27:21 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | Like let's say we want to compile Blender with Musl, alpine seems to have that working, but we probably won't due to our enablement of every dep and feature | 12:27:24 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | And it may be that upstream patching is needed, but it's also the case that we could just compile a more minimal blender. | 12:28:13 |
| Alyssa Ross | which you can do with overrides | 12:28:31 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | Ah okay that's the solution then | 12:28:39 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | if something is for some reason not optional, enough to make it able to be compiled with musl, then that is the bug | 12:28:54 |
 dramforever | we don't have to do everything in upstream nixpkgs | 12:28:57 |
| Alyssa Ross | as a user, you probably don't actually want silent differences in feature support on different platforms for non-fundamental reasons every time somebody didn't feel like fixing something properly | 12:29:08 |
| dramforever | like this is the thing you need to lay off the gas on | 12:29:08 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | A lot of what I have found is not optional and not fixable outside of nixpkgs | 12:29:33 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | So in that case it does need to be done | 12:29:42 |
| dramforever | you can just maintain a fork of nixpkgs that works for musl | 12:29:51 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | https://github.com/NixOS/nixpkgs/pull/452738 | 12:29:58 |
| dramforever | and then push stuff either into nixpkgs or upstream | 12:30:01 |
