| 14 Apr 2026 |
 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 |
| 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 |
| Vladimír Čunát | Do I see right this amount?
Rebuild: linux 521, darwin 497
| 16:27:20 |
| klea (she/her) changed their display name from klea to klea (she/her). | 16:27:22 |
| Vladimír Čunát | For security issues I'd say you could even go directly to master. | 16:27:34 |
| Vladimír Čunát | I assume most of that are relatively cheap plugins. | 16:27:59 |
| Vladimír Čunát | * I assume most of that are relatively cheap plugins, too. | 16:28:10 |
| klea (she/her) | I believe yes. | 16:28:28 |
| Vladimír Čunát | * For security issues I'd say you could even go directly to master with such rebuild amount. | 16:28:30 |
| klea (she/her) | Ack, will do a PR. | 16:28:38 |
| klea (she/her) | Done. https://github.com/NixOS/nixpkgs/pull/510019 | 16:36:20 |
|  tfc joined the room. | 17:31:58 |
| tfc | hello! quick question: we merged this test driver change to staging (https://github.com/NixOS/nixpkgs/pull/509654), although it should have gone to staging-nixos.
now there are some other pull requests that depend on this and should also go to staging-nixos, so it's a bit annoying that i chose the wrong branch for the first one.
what to do with this ideally? revert in staging and re-open PR based on staging-nixos?
| 17:33:34 |
 K900 | No need to revert | 17:41:02 |
| tfc | i don't completely understand the staging dynamics across the different branches. shall we then base the upcoming PRs on staging then, too? | 18:42:04 |
| K900 | No | 18:55:05 |
