| 10 Apr 2026 |
 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 |
| Vladimír Čunát | I got back to it because it's still failing on Hydra (and about a thousand jobs which depend on it):
https://hydra.nixos.org/build/326357571/nixlog/1/tail | 13:03:35 |
| Yureka (she/her) | ok. I'll come up with something | 13:04:27 |
| Vladimír Čunát | I suppose the Hydra's HW isn't very relevant for your fix, as it's nothing rare, and we'd like it to work on all common HW? | 13:07:10 |
| Yureka (she/her) | I mean currently it fails on Hydra and on my HW, but not on K900's | 13:07:34 |
| Vladimír Čunát | (I have direct access to it if need be.) | 13:07:36 |
| Yureka (she/her) | The problem is I can not test every single possible hw | 13:07:53 |
| Yureka (she/her) | This (reverting the initial culprit) will restore it to working state on Hydra, my machines and K900's machines, but possibly leave some other machines in a broken state | 13:08:48 |
| Yureka (she/her) | But this is the best I can offer | 13:08:53 |
| Vladimír Čunát | Sounds OK to me. | 13:09:30 |
| Vladimír Čunát | I suppose the worst part is about blocking 1k other jobs. | 13:09:50 |
| Yureka (she/her) | https://github.com/NixOS/nixpkgs/pull/509964 | 13:10:26 |
