| 9 Nov 2025 |
|  ghpzin (moved to @ghpzin:envs.net) changed their display name from ghpzin to ghpzin (moved to @ghpzin:envs.net). | 15:04:11 |
| 10 Nov 2025 |
 ElvishJerricco | Hm, somehow https://github.com/NixOS/nixpkgs/pull/442965 broke cross compiling libcap
/nix/store/50qdx59fp8w8bzaq5z8825d3kr3d4cx3-aarch64-unknown-linux-gnu-gcc-wrapper-14.3.0/bin/aarch64-unknown-linux-gnu-gcc -m64 -s -o $WORK/b001/exe/mknames -rdynamic /build/go-link-625829632/go.o
aarch64-unknown-linux-gnu-gcc: error: unrecognized command-line option '-m64'
| 08:41:42 |
 K900 | Is Go calling it with -m64 | 08:43:02 |
| K900 | That would be on brand | 08:43:10 |
| ElvishJerricco | here's the full build log, if anyone wants to take a look and help me figure out what to do about it: https://gist.github.com/ElvishJerricco/5e6d898075589d671765ccb4effc41f0 | 08:44:22 |
 Paul Meyer (katexochen) | not sure if that is related but we merged a fix for that PR in https://github.com/NixOS/nixpkgs/pull/458867 | 08:48:28 |
| ElvishJerricco | that does not appear to have helped | 09:10:02 |
| ElvishJerricco | So, I can see in the log that it's doing CC="aarch64-unknown-linux-gnu-gcc" GOOS= GOARCH= go run ..., but how could that ever work? | 11:10:04 |
| ElvishJerricco | Hypothesis: When you do GOARCH= go run ..., it was previously using some linker other than $CC, and it was successfully building a binary for the build platform. But now with the PIE change, it's trying to use $CC for its linker, and expecting that to be a valid linker for the build platform, i.e. in this case an x86_64 linker that it can pass -m64 to. So even if it wasn't making the -m64 mistake, it would still fail trying to link an x86_64 binary with an aarch64 linker. | 11:15:57 |
| ElvishJerricco | Does that sound plausible? | 11:16:05 |
| ElvishJerricco | Ok, yea, that's exactly what's happening, and fixing it requires a patch. | 15:45:04 |
| ElvishJerricco | Which I guess means I can't get this fix into staging-next | 15:45:46 |
| ElvishJerricco | well, I guess if I add the patch conditionally (only when we're cross compiling), it's not a mass rebuild for non-cross, so it could go to staging-next? | 15:50:38 |
| ElvishJerricco | is that even worth it? | 15:51:07 |
| K900 | Doable | 16:00:36 |
| K900 | Whether worth it is debatable | 16:00:42 |
| ElvishJerricco | oh dammit, I did not realize we were substituteInPlace'ing the broken line already to fix cross | 16:02:57 |
| ElvishJerricco | so I've sent an email to the maintainer fixing the cross CC problem while it's not actually cross-buildable because our substitution isn't in there :P | 16:03:29 |
 leona | we will have another staging-next cycle starting probably wednesday or thursday. IMO it would be okay to fix by then (if you have a patch so quickly) | 16:12:12 |
| K900 | Are we skipping 25.05 then | 16:13:48 |
| leona | i thought that was the idea | 16:14:04 |
| K900 | I have not checked | 16:14:15 |
| K900 | tbh | 16:14:17 |
| leona | we could also do 25.05, but then the consequence would be to go through all commits/PRs that were merged to staging (since the current staging-next) and decide which of them should be ported to staging-25.11 | 16:14:50 |
| leona | it's possible, but feels awful | 16:15:08 |
| leona | that's kinda the problem with the current workflow | 16:15:19 |
| leona | I don't know though how many and what changes are in staging and staging-25.05 | 16:15:39 |
| ElvishJerricco | Well, here's a PR to staging with the patch unconditional https://github.com/NixOS/nixpkgs/pull/460394 | 16:30:26 |
 Vladimír Čunát | I'm clearly in favor of another staging-next. | 17:08:51 |
| K900 | ocaml merge conflict on master -> next again | 17:15:15 |
