| 28 Oct 2021 |
 moritz.hedtke | In reply to @sandro:supersandro.de
It would be really grateful if there would be a good way to prevent this things other than keeping track which packages changed on which branch already I'm not knowledgeable with the exact processes but probably you're right and your original point is the best idea. | 20:40:32 |
 Sandro | 🤔 github already has a feature where it shows you which PRs also modify your current file. I think it is broken on nixpkgs for obvious reasons but that for PRs would be nice.
but that is out of reach for us because GitHub would probably need to add new API endpoints for it | 20:45:36 |
| 30 Oct 2021 |
 Ryan Burns | Seems like it would be fairly low-overhead to add a PR action which attempts to locally merge the PR into staging. If the merge would be nontrivial, notify the staging crew. | 01:30:05 |
| Sandro | Or let it fail or something. | 07:47:57 |
| moritz.hedtke | https://github.com/NixOS/nixpkgs/pull/143800 others please also comment I don't want to "decide" this in my own especially as I'm not really knowledgeable in that area. Das_j seems to have thumbsupped so I assume that's agreement but still | 13:18:20 |
|  fabianhjr joined the room. | 15:32:12 |
 hexa | ping darwin maintainers and pray | 19:05:42 |
| 31 Oct 2021 |
| Ryan Burns | Looks like the libdazzle dependency is blocking some user-facing gnome/pantheon applications, but I couldn't reproduce its test failure | 22:39:23 |
| 1 Nov 2021 |
 VladimÃr ÄŒunát | If a test is flaky, it's usually best to just disable it. (or at least make it non-blocking somehow) | 06:51:00 |
| VladimÃr ÄŒunát | That is, assuming that the failures don't indicate some real problem that could affect functionality. | 06:51:47 |
| hexa | sphinx on x86_64-darwin had a transient error due to a lack in network sandboxing and resulting socket collisisons | 14:15:29 |
| hexa | * sphinx on x86_64-darwin had a transient error due to a lack in network sandboxing and a resulting socket collisisons | 14:15:38 |
| hexa | * sphinx on x86_64-darwin had a transient error due to a lack in network sandboxing and a resulting socket collisison | 14:15:40 |
| hexa | restarted, it blocked nix-info … now we build ghc since 3.5h | 14:16:04 |
 sterni | I wonder how old the mac builders are | 14:22:51 |
| sterni | GHC should be below an hour even on a normal CPU | 14:23:10 |
| sterni | unless it somehow is slower on darwin which would be weird though | 14:23:24 |
| hexa | or the host is sufficiently partitioned with enough paralell jobs | 14:24:26 |
| hexa | https://hydra.nixos.org/build/157060609 | 14:25:01 |
| hexa | any bigger issues open or can we merge soon? | 18:27:28 |
| VladimÃr ÄŒunát | Right now I see over 8k build regressions: https://hydra.nixos.org/eval/1718058?compare=1718001 | 19:50:19 |
| VladimÃr ÄŒunát | Well, over 7k if we subtract newly succeeding builds (and add aarch64-darwin diff from a separate comparison). | 19:51:51 |
| Ryan Burns | It looks like most of that is due to the transient sphinx error though, what do we do about that? | 19:53:11 |
| VladimÃr ÄŒunát | The queue for x86_64-darwin was even empty now. So now I restarted all staging-next failures (in the last evaluation). | 19:54:19 |
| VladimÃr ÄŒunát | I'll hope that tomorrow it will be clearer that there are no large build regressions. | 20:03:19 |
| Ryan Burns | I also noticed the rubyPackages.nokogiri failure breaking a couple dependers, but couldn't see an obvious cause and have resigned to bisecting it. It'll probably take a long time so I wouldn't hold up the merge for it | 20:04:09 |
| Ryan Burns | * I also noticed the rubyPackages.nokogiri failure on x86_64-darwin breaking a couple dependers, but couldn't see an obvious cause and have resigned to bisecting it. It'll probably take a long time so I wouldn't hold up the merge for it | 20:04:24 |
| hexa | we still have a ZHF upcoming | 21:59:46 |
| hexa | from nov 5th | 22:01:14 |
 das_j | That might be a good time to drop this PR here ;) https://github.com/NixOS/nixpkgs/pull/144061 | 22:11:36 |
