| 19 Nov 2021 |
 jonringer | sorry, misread | 23:07:42 |
| jonringer | I'll do it | 23:07:54 |
| jonringer | :) | 23:07:55 |
 Vladimír Čunát | I did it already. | 23:08:01 |
 Sandro | and it seems to be already up
| 23:08:06 |
| jonringer | In reply to @vcunat:matrix.org
I did it already. [15:07:53] jon@nixos ~/projects/nixpkgs (staging)
$ git merge origin/staging-next
Already up to date.
yep
| 23:08:18 |
| 20 Nov 2021 |
|  nykw joined the room. | 11:09:34 |
| 21 Nov 2021 |
| jonringer | nrdxp: tomberek : we are under 1000 x86_64-linux rebuilds. We should probably finish up this staging-next cycle. Once it's merged we need to do the branch off | 18:21:46 |
 trofi | Today's staging-next -> staging conflict merge: https://dpaste.com/DDUT9E898.txt. Something seemingly trivial around nixos/tests/custom-ca.nix | 18:21:48 |
| jonringer | one issue is qt5.qtwebengine seems to be broken. But I don't know a good path forward. compiler seems to segfault | 18:22:59 |
| jonringer | https://hydra.nixos.org/build/158729173/nixlog/1 | 18:23:15 |
| jonringer | nevermind, hydra shows a different error:
../../3rdparty/chromium/components/paint_preview/common/subset_font.cc:74:3: error: 'hb_subset_input_set_retain_gids' was not declared in this scope; did you mean 'hb_subset_input_set_flags'?
| 18:24:00 |
| jonringer | not familiar with qmake, but looks like it's some of the vendored chromium headers aren't being correctly added to the -I paths | 18:33:31 |
| jonringer | Was able to run qutebroswer fine with https://github.com/NixOS/nixpkgs/pull/146919 | 19:54:13 |
| jonringer | going to trigger an eval | 19:54:23 |
 tomberek | testing... that's a long build ^^^^^ | 22:20:07 |
 hexa | fyi https://github.com/NixOS/nixpkgs/pull/146944 | 23:48:03 |
| hexa | * fyi https://github.com/NixOS/nixpkgs/pull/146944 #soon | 23:48:10 |
| 22 Nov 2021 |
| Vladimír Čunát | I merged staging-next. /cc nrdxp tomberek | 18:31:58 |
 sterni | Vladimír Čunát: don't forget to close the PR, was a bit confused now | 18:42:44 |
| Vladimír Čunát | I don't know why it didn't auto-close. I re-checked that I merged the right commit and found nothing wrong. | 18:43:20 |
| Vladimír Čunát | It would be nicer to let it be shown as merged instead of closed. | 18:43:39 |
| sterni | I don't think there is a way to make it show merged unless it is merged via the web UI? | 18:44:18 |
| Vladimír Čunát | Normally it's detected and marked. I almost never use the merge button. | 18:44:58 |
| Vladimír Čunát | This workflow of mine certainly worked this weekend. | 18:45:26 |
| Vladimír Čunát | * This workflow of mine certainly still worked this weekend. | 18:45:35 |
| sterni | interesting | 18:45:41 |
| sterni | well maybe it's just slow then :) | 18:45:54 |
| sterni | or maybe it doesn't like that the merge commit is not empty because it resolves a conflict? | 18:46:09 |
| Vladimír Čunát | On my side it was without conflict. | 18:46:34 |
