| 15 Jan 2025 |
|  SomeoneSerge (matrix works sometimes) changed their display name from SomeoneSerge (utc+3) to SomeoneSerge. | 19:02:17 |
|  Slushee joined the room. | 20:02:55 |
| 16 Jan 2025 |
|  FliegendeWurst joined the room. | 09:37:03 |
| 20 Jan 2025 |
| FliegendeWurst | I'm building a library with Python bindings (syndication-domination), and I use (python3Packages.python.pythonOnBuildForHost.withPackages (ps: [ps.pybind11])) to create a cpython .so module.
Why is the resulting file called syndom.cpython-312-x86_64-linux-gnu.so when cross-compiling Linux x64->aarch64?
(It is a proper "ARM aarch64" so according to file)
Should I just handle it as a quirk of this particular package and rename it, or should I patch pybind11 instead? | 12:56:12 |
 lzcunt | I can't seem to get the regression in https://github.com/NixOS/nixpkgs/pull/370683 to be fixed, does it make sense to simply guard the langCC changes to only mlibc platforms? (musl fails, mlibc which is added in a different PR doesn't) | 18:05:54 |
| lzcunt | CC Tristan Ross (not sure if you'd enjoy a ping so hopefully this doesn't ping): not sure if this works with LLVM libc but this patch might also be needed for LLVM libc on a gcc toolchain. If you ever try building llvm libc with gcc, could you please see if this is needed or works or breaks anything? | 18:10:18 |
 Tristan Ross | In reply to @sananatheskenana:matrix.org
CC Tristan Ross (not sure if you'd enjoy a ping so hopefully this doesn't ping): not sure if this works with LLVM libc but this patch might also be needed for LLVM libc on a gcc toolchain. If you ever try building llvm libc with gcc, could you please see if this is needed or works or breaks anything? GCC is broken with LLVM libc because it doesn't support [[gnu::naked]] on certain architectures lol. | 18:18:26 |
| Tristan Ross | Building LLVM libc pretty much is only supported with pkgsLLVM | 18:19:53 |
| lzcunt | Ok then, what do you reckon about only enabling langCC for mlibc because it needs it but seemingly that option breaks musl? (libstdc++ linker tests fail with musl) I don't think fixing an issue with musl which I don't know a lot about is in scope of my mlibc adventures | 18:22:44 |
| Tristan Ross | I think it's also breaking pkgsLLVMLibc outside of pkgsLLVM | 18:23:33 |
| Tristan Ross | OpenSSL is getting an infinite recursion in curl inside of cmake | 18:23:59 |
| lzcunt | I'll try looking at it tomorrow possibly, I has my own share of almost unfixable infinite recursion. I think I encountered a similar issue with openssl and zlib in python and it was python's weird dependency memes that needed special casing for openssl | 18:26:15 |
| lzcunt | * I'll try looking at it tomorrow possibly, I had my own share of almost unfixable infinite recursion. I think I encountered a similar issue with openssl and zlib in python and it was python's weird dependency memes that needed special casing for openssl | 18:26:28 |
| Tristan Ross | Yeah, the problem seems to be reading stdenv.cc.is* | 18:28:07 |
| lzcunt | oof | 18:28:42 |
| lzcunt | I'll close the langCC PR and add that commit (gated for only mlibc) to the mlibc PR, and leave a small comment for future reference on it | 18:30:53 |
| lzcunt | After that the mlibc PR will be ready for review - tho it's limited in usability until a couple small but key bugs in mlibc are resolved (I've reported it upstream already) and I need one of my PRs to be merged upstream so the package doesn't point at my fork | 18:32:32 |
| lzcunt | * After that the mlibc PR will be ready for review - tho it's limited in usability until a couple small but key bugs in mlibc are resolved (I've reported them upstream already) and I need one of my PRs to be merged upstream so the package doesn't point at my fork. quite a lot of packages only work when built statically due to some RTLD RPATH resolution shenanigans. | 18:34:21 |
| lzcunt | * After that the mlibc PR will be ready for review - tho it's limited in usability until a couple small but key bugs in mlibc are resolved (I've reported them upstream already) and I need one of my PRs to be merged upstream so the package doesn't point at my fork. quite a lot of packages only work when built statically due to some RTLD RPATH resolution shenanigans - I guess the managarm people never really thought about non-FHS distros a lot | 18:35:12 |
| lzcunt | * After that the mlibc PR will be ready for review - tho it's limited in usability until a couple small but key bugs in mlibc are resolved (I've reported them upstream already) and I need one of my PRs to be merged upstream so the package doesn't point at my fork. quite a lot of packages only work when built statically due to some RTLD RPATH resolution shenanigans - I guess the managarm people never really thought about non-FHS distros a lot. I also need to make it point to staging because it causes around 65k rebuilds :^) | 18:36:50 |
| 21 Jan 2025 |
|  emily 🐾 joined the room. | 00:01:45 |
| 22 Jan 2025 |
| emily 🐾 changed their profile picture. | 12:34:10 |
| 21 Jan 2025 |
|  oak 🏳️🌈♥️ changed their profile picture. | 22:35:44 |
| oak 🏳️🌈♥️ changed their profile picture. | 22:37:21 |
| 23 Jan 2025 |
|  roshanah joined the room. | 01:17:53 |
|  @paparodeo:matrix.org left the room. | 01:24:24 |
| 24 Jan 2025 |
 kuruczgy | Has anyone encountered issues with cross compiling an ISO with recent nixpkgs, or is it just my GHA acting up? https://github.com/kuruczgy/x1e-nixos-config/actions/runs/12941176672/job/36096781780?pr=63
(It's failing to compile screen, and it doesn't seem like a disk-full problem, so my next best guess is cross) | 12:03:17 |
 Alyssa Ross | Have you checked whether you can cross compile screen on its own? | 12:04:05 |
| kuruczgy | Not yet, I will have time to do some more thorough investigation in a couple hours hopefully, just wanted to quickly check if this was known issue already. | 12:06:11 |
| kuruczgy | Oh it is: https://github.com/NixOS/nixpkgs/issues/371238 | 12:06:59 |
