| 10 Nov 2025 |
 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 |
 vcunat | I'm clearly in favor of another staging-next. | 17:08:51 |
| K900 | ocaml merge conflict on master -> next again | 17:15:15 |
 hexa | ❯ git log --oneline origin/master..origin/staging --no-merges --no-decorate --grep=CVE
1e7d8a4584ab python3Packages.django_4: 4.2.25 -> 4.2.26
6fd9ec48b661 xorg.xorgserver: 21.1.18 -> 21.1.20
d81ba7d1f23a lz4: apply fix for CVE-2025-62813
| 17:18:14 |
| hexa | ❯ git log --oneline origin/release-25.05..origin/staging-25.05 --no-merges --no-decorate --grep=CVE
2b13164ef7d0 lz4: apply fix for CVE-2025-62813
d81c0d0ae3c0 glib: apply patch for CVE-2025-7039
| 17:18:21 |
| hexa | ❯ git log --oneline origin/release-25.05..origin/staging-25.05 --no-merges --no-decorate
2b13164ef7d0 lz4: apply fix for CVE-2025-62813
98dba649eaa9 minio: 2025-09-07T16-13-09Z -> 2025-10-15T17-29-55Z
cd2ce1aab67a minio: 2025-07-23T15-54-02Z -> 2025-09-07T16-13-09Z
f250657e7d35 minio: 2025-07-18T21-56-31Z -> 2025-07-23T15-54-02Z
b75ed85e0e11 minio: 2025-06-13T11-33-47Z -> 2025-07-18T21-56-31Z
b746a7218c8f minio: 2025-05-24T17-08-30Z -> 2025-06-13T11-33-47Z
a6c9ae3da512 minio: 2025-03-12T18-04-18Z -> 2025-05-24T17-08-30Z
4bccb3507bf6 go_1_24: 1.24.9 -> 1.24.10
c0ea3dfb77f3 qt5: 5.15.17 -> 5.15.18
d81c0d0ae3c0 glib: apply patch for CVE-2025-7039
cd525dd017a3 unbound-full: 1.24.0 -> 1.24.1
1d8ef5fde841 unbound-with-systemd: 1.23.1 -> 1.24.0
776374ef65f9 jdk: 21.0.9+8 -> 21.0.9+10
| 17:18:51 |
| 11 Nov 2025 |
| ElvishJerricco | there's some texlive thing that's failing on staging-next and breaking asciidoc-full | 07:24:37 |
| vcunat | Yes, texlive seems quite broken. | 07:27:19 |
| vcunat | Lots of packages are affected; it's just less visible in nix-review-reports, because it happens for packages with various .name values. | 07:28:19 |
| vcunat | * Lots of packages are affected; it's just less visible in nix-review-reports, because it happens for derivations with various .name values. | 07:28:26 |
