| 7 Nov 2025 |
 Alyssa Ross | I can do that | 18:45:29 |
| 8 Nov 2025 |
 aloisw | The nix-drv-index numbers are not as trustworthy as the ones obtained by actual eval, since they don't take into account intermediate derivations that aren't accessible themselves. | 06:44:51 |
 Marcus | given the current release cycle, is https://github.com/NixOS/nixpkgs/pull/459886 ok to merge to staging? | 23:23:04 |
 K900 | The release notes look OK | 23:24:23 |
| K900 | But maybe hold off until branch-off anyway | 23:24:31 |
| K900 | Just to be safe | 23:24:34 |
| 9 Nov 2025 |
 samasaur | https://github.com/NixOS/nixpkgs/pull/459987 should fix swift on staging-next | 07:32:42 |
|  tom joined the room. | 08:07:31 |
| K900 | 
Download image.png | 10:14:06 |
| K900 | Can github please fucking not | 10:14:12 |
| K900 | @Wolfgang Walther there's no way to tell it to just stop checking those on automated merges, is there? | 10:15:23 |
| K900 | OK fuck this I give up | 10:17:45 |
| K900 | I retried it like five times | 10:17:53 |
 Wolfgang Walther | I doubt it. For example checking the rule "creation" times out. I'd say that "whether a new branch is created or not" should be independent from basically everything else. No matter how many commits are merged. Thus, I assume this is just github being github - and short of disabling all branch protection, I don't think we can do much.
Even if it worked, I'd not feel comfortable to add the nixpkgs-ci bot account, which does the periodic merges, as a bypasser to all rules. But that's a big if anyway. | 10:22:20 |
| Wolfgang Walther | This is something that should be brought up with GitHub. | 10:29:35 |
|  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 |
