| 14 Apr 2026 |
 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 |
| Yureka (she/her) | This is of course another openblas rebuild | 13:10:45 |
| Vladimír Čunát | Sure, but at least on aarch64 only. | 13:11:31 |
| Yureka (she/her) | right | 13:11:52 |
| Vladimír Čunát | (and aarch64-darwin probably haven't managed to build much) | 13:11:52 |
| Vladimír Čunát | * (and aarch64-darwin probably haven't managed to build much yet) | 13:12:04 |
 emily | have we reported that we're still seeing failures upstream to OpenBLAS btw? | 13:15:05 |
| Yureka (she/her) | No | 13:15:22 |
| Yureka (she/her) | But there are no failures in the openblas test suite with their upstream fix anymore | 13:15:33 |
| emily | might incentivize them figuring out "root cause likely to be some missing or improper declaration in the inline assembly" | 13:15:44 |
| Yureka (she/her) | only failures in the scipy test suite | 13:15:37 |
| emily | (from https://github.com/OpenMathLib/OpenBLAS/pull/5691) | 13:15:48 |
| Yureka (she/her) | Would still be good to report to them igs but no time | 13:15:52 |
| emily | they originally adjusted it for https://github.com/numpy/numpy/issues/30816 | 13:16:16 |
| emily | so I guess they're probably interested in downstream failures too | 13:16:25 |
| Vladimír Čunát | It's surely fishy, though. Their change causing scipy test regressions. | 13:16:44 |
| Vladimír Čunát | * It's surely fishy, though. Their changes causing scipy test regressions. | 13:16:53 |
| Yureka (she/her) | not too surprising if scipy uses openblas for those calculations | 13:17:05 |
| emily | messing around with volatile is never going to be a very reliable way to make broken code compile right 🫠 | 13:17:16 |
| Vladimír Čunát | An alternative could be to let scipy upstream figure this out, but from what's been discussed here it does sound more likely to be an openblas issue. | 13:19:38 |
