| 10 Apr 2026 |
 K900 | 18k of them | 12:20:47 |
| K900 | I guess we're not that far in yet | 12:20:59 |
 Yureka (she/her) | orrr | 13:03:27 |
| Yureka (she/her) | the other scipy failures are also because of the remaining volatile | 13:03:38 |
| Yureka (she/her) | Redacted or Malformed Event | 13:03:39 |
 sampointon | Could someone with a Mac try a build of gts with NIX_CFLAGS_COMPILE=--std=gnu17? At this point I'm suspicious of any C FTBFS as being fallout from the autotools bump and the new C23 assumption, but it's only happening on Apple platforms and I don't have one of those | 13:08:02 |
| Yureka (she/her) | So the only way I can get scipy to build on my macbook is to revert 3f6e928d34aca977bd5d4191e6d2c2338a342db5 "Declare result as volatile to keep compilers from optimizing it out" fully | 13:16:58 |
| Yureka (she/her) | Redacted or Malformed Event | 13:17:12 |
| Yureka (she/her) | but I don't know if that causes other issues on other platforms | 13:17:30 |
| K900 | Fun | 13:20:20 |
 Randy Eckenrode | Adding env.NIX_CFLAGS_COMPILE=-std=gnu17 makes it build for me. | 13:22:25 |
| sampointon | Cheers. I'll put together a PR and see if it makes sense to unconditionally set it or if the Linux rebuild damage would be too much | 13:24:42 |
| Randy Eckenrode | I didn’t check the source, but the error looked similar to others that were due to the removal of support for K&R-style function declarations. | 13:45:38 |
| Randy Eckenrode | * | 13:46:02 |
| Randy Eckenrode | man-db also fails, which is technically an improvement. It previous hung in one of its tests IIRC. | 15:37:50 |
| 12 Apr 2026 |
|  leona changed their profile picture. | 12:15:43 |
| sampointon | I think the zeroconf failure on x86_64 Linux is a flaky test. I can't reproduce it locally and previous staging-next iterations have seen the same failure (test_run_coro_with_timeout), which then clears up next run but comes back a few later | 13:50:43 |
| sampointon | Looking at the test code, it's also not exactly testing zeroconf, but actually really asyncio, and it looks suspiciously like it could fail in weird ways if a timeout unexpectedly does/doesn't occur. So I think it's more likely that the test is wrong rather than something being badly wrong with asyncio | 13:51:48 |
| sampointon | https://github.com/NixOS/nixpkgs/pull/509275 - in principle this could go via staging for the next cycle as well, but there's no guarantee it wouldn't be annoying flake again on the next run of this cycle | 14:30:07 |
| 13 Apr 2026 |
 Sandro | the rebuild count is inflated because of home assistant, go send it | 12:08:46 |
 Vladimír Čunát | I see no successful build of that package yet, so I don't think the rebuild amount is really relevant:
https://hydra.nixos.org/eval/1824377?compare=unstable&filter=.zeroconf. | 12:14:17 |
|  Harinn joined the room. | 12:18:16 |
| 14 Apr 2026 |
| Vladimír Čunát | Have I missed any followups around scipy failures? I haven't managed to find anything on nixpkgs git+github. | 12:49:38 |
 hexa | weren't they openblas induced? | 12:50:08 |
| Yureka (she/her) | No. I haven't submitted anything because I don't know a good solution. | 12:50:13 |
| Yureka (she/her) | Yes | 12:50:30 |
| Vladimír Čunát | I suppose we could've gotten confused to hope that this one will fix it but i t did not:
ab103ee39931 openblas: backport fix for ARM64 non-SVE DDOT kernel (#508576)
| 12:55:21 |
| Yureka (she/her) | This fixes openblas' own tests, and most but not all of the scipy tests | 13:00:04 |
| Yureka (she/her) | but this is all only broken on machines with certain asimd extensions | 13:00:21 |
| Yureka (she/her) | I can submit a PR to restore this code to the state we had before (with openblas 0.3.30), but presumably this is then broken on yet another code path | 13:03:16 |
