| 24 Aug 2025 |
 tpw_rules | Artturin: if you would like to update your PR i will review it more thoroughly | 19:42:50 |
| tpw_rules | don't quite know how but both built | 20:15:04 |
| tpw_rules | and work under x86 emulation with a native qemu-user | 20:15:17 |
 Artturin | https://gist.github.com/Artturin/e79f1fcf125ebb138c0012008e719533 | 21:41:45 |
| Artturin | Red doesn't work, green does | 21:44:40 |
| 26 Aug 2025 |
|  RichInOverdraft changed their display name from rich to RichInOverdraft. | 12:16:19 |
| 27 Aug 2025 |
|  griff joined the room. | 14:51:57 |
|  chrillefkr joined the room. | 21:46:11 |
| 28 Aug 2025 |
 Grimmauld (any/all) | https://github.com/NixOS/nixpkgs/pull/432924#issuecomment-3232559996
can someone that knows cross/splicing things sanity-check this patch before i open a fixup PR? | 09:28:48 |
| Grimmauld (any/all) | targetPlatform vs hostPlatform is still a little confusing to me. I believe this is the correct fix to remove pam from buildPackages (but not in host packages), but a second set of eyes would be nice | 09:30:12 |
| Grimmauld (any/all) | the goal is to keep pam support when building linux cross, but remove it from buildPackages when building non-linux cross. It'll be removed from host packages using availableOn in the case of freebsd, but the python going into llvm pulls libuuid, which is in the compiler bootstrap, so targetPlatfrom checks seem appropriate to me here | 09:35:55 |
| Grimmauld (any/all) | * the goal is to keep pam support when building linux cross, but remove it from buildPackages when building non-linux cross from linux. It'll be removed from host packages using availableOn in the case of freebsd, but the python going into llvm pulls libuuid, which is in the compiler bootstrap, so targetPlatfrom checks seem appropriate to me here | 09:36:05 |
| Grimmauld (any/all) | * the goal is to keep pam support when building linux cross, but remove it from buildPackages when building non-linux cross from linux. It'll be removed from host packages using availableOn in the case of freebsd, but the build python going into llvm pulls libuuid, which is in the compiler bootstrap, so targetPlatfrom checks seem appropriate to me here | 09:36:16 |
| Grimmauld (any/all) | * the goal is to keep pam support on host when building linux cross, but remove it from buildPackages (when building non-linux) cross from linux. It'll be removed from host packages using availableOn in the case of freebsd, but the build python going into llvm pulls libuuid, which is in the compiler bootstrap, so targetPlatfrom checks seem appropriate to me here | 09:43:08 |
 dramforever | In reply to @grimmauld:grapevine.grimmauld.de
targetPlatform vs hostPlatform is still a little confusing to me. I believe this is the correct fix to remove pam from buildPackages (but not in host packages), but a second set of eyes would be nice if you're trying to use targetPlatform:
are you trying to make a compiler that requires rebuilding to change what machine it generates code for?
- yes: okay, use it. arrgh.
- no: do not use
targetPlatform
| 09:58:49 |
| dramforever | * if you're trying to use targetPlatform:
are you trying to make a compiler that requires rebuilding to change what machine it generates code for?
yes: okay, use it. arrgh.
no: do not use targetPlatform
| 09:59:09 |
 Alyssa Ross | hmm, it would be nicer if we could fix the infinite recursion | 10:00:19 |
| Grimmauld (any/all) | The inf rec is because availableOn somehow does weird output logic which then depends on stdenv? | 10:00:49 |
| Grimmauld (any/all) | at least as far as i understand | 10:01:03 |
| Alyssa Ross | I'm wondering if we can get away with just delaying the isClang check | 10:01:22 |
| Alyssa Ross | what even is this clangFixup thing | 10:02:03 |
| Grimmauld (any/all) | i mean, buildPackages does not need pam to build stuff. Pam is only ever required on a real system. So doing targetPlatform == hostPlatform checks might work | 10:02:27 |
| Alyssa Ross | Does mean a lot of rebuilds in buildPackages though | 10:02:38 |
| Grimmauld (any/all) | that, yes | 10:02:46 |
| Alyssa Ross | Yeah I think this is fixable in the FreeBSD mkDerivation | 10:03:37 |
| Grimmauld (any/all) | delaying the isClang check might work too, but that is too deep in the LLVM stack for me to properly understand what is going on there | 10:03:49 |
| dramforever | i'm looking at that as well but yes i think we should not disable pam support in buildPackages | 10:04:21 |
| Grimmauld (any/all) | i am all for it if it can be fixed in the freebsd mkderivation, but i don't know enough freebsd/stdenv wizardry to fix it there. I knew how to fix it in util-linux, but i won't make a claim about that being the best fix | 10:05:45 |
| Alyssa Ross | Yep, I have a fix. | 10:06:11 |
| dramforever | In reply to @grimmauld:grapevine.grimmauld.de
i am all for it if it can be fixed in the freebsd mkderivation, but i don't know enough freebsd/stdenv wizardry to fix it there. I knew how to fix it in util-linux, but i won't make a claim about that being the best fix okay i would like to clarify that i am saying that making util-linux depend on targetPlatform is not acceptable. that would make anyone cross compiling to rebuild everything in buildPackages that depends on util-linux | 10:07:23 |
