!UNVBThoJtlIiVwiDjU:nixos.org

Staging

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

Load older messages


SenderMessageTime
9 Jul 2025
@vcunat:matrix.orgvcunatI can see that in some situations we could utilize possibility of manually adjusting what the channels point to.09:13:58
@vcunat:matrix.orgvcunat* I can see that in some situations we could utilize some possibility of manually adjusting what the channels point to.09:14:06
@vcunat:matrix.orgvcunat* I can see that in some situations we could utilize some possibility of (half-)manually adjusting what the channels point to.09:14:14
@vcunat:matrix.orgvcunatEven if the usual preconditions don't hold.09:14:29
@emilazy:matrix.orgemilydid we make a decision about Git12:45:11
@vcunat:matrix.orgvcunatI don't think we did.12:58:18
@vcunat:matrix.orgvcunatAnd I don't see a significant advantage in doing something unusual, but I might be missing something.12:59:15
@emilazy:matrix.orgemily hmm does the going straight into hte next staging count as unusual? 13:05:20
@emilazy:matrix.orgemily the only thing I thought of was we could repoint the Python stuff at a copy of the vulnerable git and land git/gitFull updates early 13:05:43
@emilazy:matrix.orgemilykind of gross though13:05:47
@emilazy:matrix.orgemily what's the shortest -next we've had recently? feels like they are getting longer and longer 13:13:19
@emilazy:matrix.orgemilyI guess probably one of the release branch ones :) but even in terms of just builds13:13:34
@vcunat:matrix.orgvcunatThey're longer in the period when we keep building two stables.13:30:36
@emilazy:matrix.orgemilyah, I meant a longer "recently" than that, but yes that makes sense13:31:02
@vcunat:matrix.orgvcunat Very often staging-* builds take roughly only a half of Hydra's time, contrary to what people would expect. 13:31:12
@emilazy:matrix.orgemilyI wonder if having stricter backporting rules for oldstable (e.g. only security updates, nothing else) would help13:31:48
@emilazy:matrix.orgemilyit's pointless to backport minor bumps and new features and non-critical bugfixes but maybe they add up to a meaningful proportion of builds? especially if people are just blanket backporting stuff to both stagings or whatever13:32:18
@vcunat:matrix.orgvcunatNot significantly, I believe.13:32:26
@vcunat:matrix.orgvcunatWell, I'd say that a large part is from kernel updates. Though NixOS tests. But it's mostly a gut feeling from lots of observations.13:33:08
@vcunat:matrix.orgvcunat* Well, I'd say that a large part is from kernel updates. Through NixOS tests. But it's mostly a gut feeling from lots of observations.13:33:18
@emilazy:matrix.orgemilyI wonder how many NixOS tests could be done with containers without kernels instead.13:34:31
@emilazy:matrix.orgemilye.g. nspawn13:34:34
@emilazy:matrix.orgemily would need auto-allocate-uids so that the derivations can get enough UIDs for unprivileged user namespaces I guess. and actually you'd need to pass through nsresourced, which could get funny. 13:35:11
@vcunat:matrix.orgvcunatThat's more impurity, though.13:35:12
@vcunat:matrix.orgvcunat* That would be more impurity, though.13:35:18
@emilazy:matrix.orgemily yes. but checkPhase already is impure in the same way, right? 13:35:33
@emilazy:matrix.orgemilywe would still want tests using full VMs to test stuff that is somehow kernel-relevant, but for random service modules it doesn't feel high-value13:35:56
@emilazy:matrix.orgemily(we could run every build in a VM with a pinned kernel but don't)13:36:20
@emilazy:matrix.orgemilysimilarly tests don't use the full bootloader flow by default even though that is less end-to-end coverage13:36:32
@emilazy:matrix.orgemilyanyway, just an idea. it would unfortunately be annoying to implement because of ^13:36:56

Show newer messages


Back to Room ListRoom Version: 6