| 17 Sep 2021 |
 hexa | yep | 12:20:43 |
 lukegb (he/him) | Oh, I should've merged the opencv fix into staging first | 12:20:52 |
| lukegb (he/him) | (https://github.com/NixOS/nixpkgs/pull/138237) | 12:21:12 |
| hexa | i guess you still can | 12:21:23 |
| lukegb (he/him) | it's always fun seeing whatever random package stdenv rebuild steps actually end up attributed to | 19:16:06 |
| lukegb (he/him) | this week, it's ssb-patchwork (for x86_64-linux) https://hydra.nixos.org/build/153417098 | 19:16:17 |
| 20 Sep 2021 |
| hexa | this staging-next run is really uneventful, we need more like these :) | 12:32:45 |
 Vladimír Čunát | Yes, though I can still see a couple thousand build regressions: https://hydra.nixos.org/eval/1706256?compare=trunk | 13:02:23 |
 trofi | nix-review-tools says at least on linux most failures are around qtwayland and hardened_kernel. | 13:24:16 |
| hexa | https://shells.darmstadt.ccc.de/~hexa/1706256.html | 16:30:40 |
| hexa | I'm going to take a look at the python stuff when I come back from the supermarket | 16:31:12 |
| Vladimír Čunát | Most of regressions seem to be darwin and linux-hardened. | 16:47:52 |
| hexa | In beautifulsoup4 it complains about not knowing is8859-15 and windows-cp1252 | 17:19:40 |
| hexa | the failing sphinx job I can't find | 17:19:50 |
| hexa | pytest-timeout … decided to disable two failing tests, because of the value of unblocking 700 more jobs https://github.com/NixOS/nixpkgs/pull/138726 | 17:20:10 |
|  Nick Hu joined the room. | 17:22:26 |
|  Alyssa Ross joined the room. | 17:26:39 |
| Nick Hu | I just merged a version update of gdb 10 -> 11; I have tested the binaries myself, and I think it should be fairly non-contentious. The reason it's in staging is mass rebuilds, but I can't see this having a huge knock-on effect on its reverse-dependencies. What's the process for stabilization? | 17:26:47 |
| Alyssa Ross | nickhu: every so often a version of staging becomes the new staging-next. After that, staging next is worked on for a while to fix any regressions, and let a full Hydra build complete, and then it's merged into master and the cycle begins again. | 17:29:10 |
| Alyssa Ross | So in a few weeks, your gdb update will land in master after going through this process | 17:29:39 |
| Alyssa Ross | Staging is not a place to get extra testing for a package, or to try something out. Its purpose is to group mass rebuilds together. | 17:30:07 |
| Nick Hu | Right, I understand that from the documentation. Let me rephrase my question: is there anything more I should do for this change? | 17:30:18 |
| Alyssa Ross | So the stabilization workflow is largely automatic, except for when build failures are identified | 17:30:31 |
| Alyssa Ross | no, you don't need to do anything else | 17:30:38 |
| Nick Hu | It doesn't really make it clear who is responsible for the stabilization process | 17:30:41 |
| Nick Hu | In reply to @qyliss:fairydust.space
no, you don't need to do anything else Great, thanks! | 17:30:51 |
| Alyssa Ross | everybody and nobody is responsible for it | 17:30:55 |
| Alyssa Ross | Go to https://github.com/NixOS/nixpkgs/compare/master...staging-next and click the button to see the current staging-next PR | 17:31:16 |
| Nick Hu | In reply to @qyliss:fairydust.space
everybody and nobody is responsible for it Just like the old workflow then 😀 | 17:31:37 |
| Alyssa Ross | there, you can see conversation about what needs to be done for this round, and a link to Hydra to see what's failing, etc. | 17:31:37 |
