| 14 Apr 2026 |
 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 |
 vcunat | Sounds OK to me. | 13:09:30 |
| vcunat | 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 |
| vcunat | Sure, but at least on aarch64 only. | 13:11:31 |
| Yureka (she/her) | right | 13:11:52 |
| vcunat | (and aarch64-darwin probably haven't managed to build much) | 13:11:52 |
| vcunat | * (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 |
| vcunat | It's surely fishy, though. Their change causing scipy test regressions. | 13:16:44 |
| vcunat | * 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 |
| vcunat | 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 |
| Yureka (she/her) | Indeed but we can still report it to scipy with the hint that the failure was introduced by this openblas change | 13:20:02 |
| emily | makes sense | 13:20:20 |
| emily | since the original issue was to NumPy too | 13:20:26 |
|  klea (she/her) joined the room. | 16:23:40 |
| klea (she/her) | I noticed https://github.com/vim/vim/security/advisories/GHSA-2gmj-rpqf-pxvh which affects vim, and I was wondering where I should put a PR against to upgrade to the latest version of vim, since https://github.com/NixOS/nixpkgs/pull/508392 got closed with no PR against another branch, and don't know if it's severe enough for staging-next or something. | 16:25:36 |
