| 5 Sep 2021 |
 hexa | manual completed on the pr | 19:45:06 |
| 7 Sep 2021 |
 lukegb (he/him) | I think I made staging happy again | 16:48:22 |
| lukegb (he/him) | I manually merged staging-next into staging, but that actually also merged in the revert (whoops) | 16:48:39 |
| 8 Sep 2021 |
 trofi | How do you find a top derivation that blocks other derivations to build on staging-next? guix has guix weather tool that dumps a histogram on you. Does hydra have an equivalent? | 17:10:58 |
 Vladimír Čunát | There is an external tool suitable for this, but I can't recall an immediate link. | 17:16:27 |
| Vladimír Čunát | * There is an external tool suitable for this, but I can't immediately recall a link or name. | 17:16:47 |
| trofi | Is this a good room to coordinate fixes for staging-next like https://github.com/NixOS/nixpkgs/pull/135414? If not which one should it be? | 20:28:40 |
| lukegb (he/him) | Yeah, this is a good place for that. I think :p | 20:30:19 |
| Vladimír Čunát | Yes. Another one is the particular staging-next PR: https://github.com/NixOS/nixpkgs/pull/135477 | 21:42:47 |
| Vladimír Čunát | * Yes. Another good place is the particular staging-next PR: https://github.com/NixOS/nixpkgs/pull/135477 | 21:43:23 |
| lukegb (he/him) | I'm fixing the linuxPackages_5_13 breakage on staging-next | 22:50:18 |
| 10 Sep 2021 |
| lukegb (he/him) | aws-sam-cli and awscli2 are broken (Python dependencies)
ceph is broken (Python backports creating colliding init pycache entries?)
or-tools is broken because mypy-protobuf is broken (missing a dep on grpcio-tools) | 12:34:58 |
| lukegb (he/him) | Basically all the pending builds for staging are x86_64-darwin... | 14:48:15 |
| hexa | python backports packaging is fixed by adding them to the same pythonNamespace (via jonringer) | 17:35:33 |
| 11 Sep 2021 |
 asbachb | Are merges from staging to staging-next allowed? bottles is now broken on master for several month and is currently only on staging. | 18:58:34 |
 jonringer | No, as that defeats the point of stabilization, if you include breaking changes | 19:07:28 |
| asbachb | it's an end user program | 19:07:59 |
| jonringer | If that's the case, the fix should have been merged into staging next or master | 19:08:45 |
| asbachb | The problem is that it needed a fix that was just available in staging. | 19:09:15 |
| asbachb | But the PR needed quite some time for merging so the fix for the lib is now on staging-next and the bottles fixed is in staging. | 19:09:53 |
| jonringer | Then it will have to target staging. The staging next paradigm is to limit stressing the infrastructure beyond what it can handle | 19:11:21 |
| lukegb (he/him) | This staging-next cycle's been open for a while, but I'm hoping it'll settle down relatively soon so we can get started on the next one | 19:11:52 |
 sterni | asbachb: you can also just PR the change into master once staging-next is merged | 19:38:11 |
| asbachb | sterni: from staging-next to master or via a new PR? | 20:37:53 |
| sterni | if it's already merged into staging, I'd just wait, less hassle | 20:40:59 |
| asbachb | It's a little bit annoying as building myself takes several hours due to the dependencies. | 20:41:27 |
| sterni | sure, but the staging(-next) workflow ensures that staging (and to an extent) staging-next are the only branches where this happens | 20:42:49 |
| trofi | what is the rough criteria to merge staging-next into master? zero build failures on both? or when staging-next is stirctly better? | 21:09:42 |
| asbachb | I wonder if it makes sense to provide the binaries for staging next somehow. Maybe this would also encourage more people to help fixing. | 21:14:42 |
| asbachb | But testing a fix maybe waiting several hour for the dependencies to build it quite annoying. | 21:14:57 |
