| 14 Apr 2026 |
 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 |
| vcunat | 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 |
| vcunat | For security issues I'd say you could even go directly to master. | 16:27:34 |
| vcunat | I assume most of that are relatively cheap plugins. | 16:27:59 |
| vcunat | * I assume most of that are relatively cheap plugins, too. | 16:28:10 |
| klea (she/her) | I believe yes. | 16:28:28 |
| vcunat | * 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 |
| K900 | Just merge to staging-nixos | 18:55:09 |
| tfc | But new prs will not see the change that we have now in staging, or am i wrong? The next prs depend on that | 19:30:45 |
 Ramses 🇵🇸 | You can duplicate the commit in staging-nixos, and git will figure that out later when staging-nixos gets merged into master and then into staging | 19:33:15 |
| emily | git cherry-pick -x like it's a backport | 19:34:09 |
| Ramses 🇵🇸 | It should just skip it | 19:33:57 |
| tfc | Perfect, thank you for the explanation | 19:56:34 |
