!UNVBThoJtlIiVwiDjU:nixos.org

Staging

395 Members
Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.11 | Review Reports: https://malob.github.io/nix-review-tools-reports/127 Servers

Load older messages


SenderMessageTime
26 Jun 2026
@hexa:lossy.networkhexa478605f6e9ca15:28:20
@emilazy:matrix.orgemilyyou can cancel the Darwin on that I suppose15:28:37
@whispers:catgirl.cloudwhispers [& it/fae]i had to do no non-trivial local rebuilds for those on *-linux15:28:40
@hexa:lossy.networkhexaare you sure?15:28:55
@emilazy:matrix.orgemilywell we certainly want ^ I assume15:29:13
@hexa:lossy.networkhexaok, done15:29:19
@emilazy:matrix.orgemilyand I assume we'll want https://github.com/NixOS/nixpkgs/pull/535508 once I confirm it builds15:29:31
@emilazy:matrix.orgemily(~100 builds away)15:29:37
@emilazy:matrix.orgemilyor we could preemptively merge it and let Hydra race to see :P15:30:15
@hexa:lossy.networkhexanuh-uh15:30:25
@emilazy:matrix.orgemily I also have a bunch of commits to fix e.g. update scripts breaking because of the x86_64-darwin drop, but those shouldn't cause a billion rebuilds, so can merge during the cycle 15:31:07
@emilazy:matrix.orgemilyand the remaining big-rebuild cleanups I have lying around can just catch the train for the next cycle15:31:39
@emilazy:matrix.orgemily pretty excited to see how fast a cycle goes with new queue runner + no x86_64-darwin 15:36:26
@emilazy:matrix.orgemily what if aarch64-darwin finishes half-way through and we need to bring x86_64-darwin back to give the builders more work? 15:37:19
@emilazy:matrix.orgemily btw, it looks like we override supportedSystems for staging-next https://hydra.nixos.org/jobset/nixpkgs/staging-next#tabs-configuration 15:37:59
@emilazy:matrix.orgemilythat's presumably going to need to be fixed15:38:02
@hexa:lossy.networkhexaremoved15:39:51
@hexa:lossy.networkhexabecause what we have in staging as a default looks fine15:40:03
@grimmauld:m.grimmauld.deGrimmauld (any/all) Okay, i have a hook for OMPNUMTHREADS almost ready 16:33:55
@hexa:lossy.networkhexatested?16:34:22
@grimmauld:m.grimmauld.deGrimmauld (any/all) Okay, i have a hook for OMP_NUM_THREADS almost ready 16:35:27
@grimmauld:m.grimmauld.deGrimmauld (any/all)It sets the env var, it doesn't override the env var if it is already set, and numpy/scipy builds16:35:47
@grimmauld:m.grimmauld.deGrimmauld (any/all)doing a bit more testing rn16:36:10
@hexa:lossy.networkhexa you should check, e.g. with --option cores 2 and perf top that the host isn't dominated by omp threads/gomp calls 16:37:48
@emilazy:matrix.orgemilyok, had to push a fix but everything https://github.com/NixOS/nixpkgs/pull/535508 touches builds16:38:35
@emilazy:matrix.orgemilyand perhaps someone might like to hit the button on https://github.com/NixOS/nixpkgs/pull/535513 and https://github.com/NixOS/nixpkgs/pull/535511 as well (though those can land any time)16:39:16
@emilazy:matrix.orgemilyshould be good to start this cycle with that merged from my PoV16:39:27
@grimmauld:m.grimmauld.deGrimmauld (any/all) I mean, not much more we can do than setting OMP_NUM_THREADS, right? If the env var is there, it should be fine. And confirming the env var is there in the check processes is trivial and that i did do 16:39:34
@hexa:lossy.networkhexatrue16:39:55
@emilazy:matrix.orgemilythere's some logic somewhere that caps it to 6416:40:05

Show newer messages


Back to Room ListRoom Version: 6