| 1 Nov 2021 |
 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 |
| das_j | Also what's the general opinion about the coreutils/ZFS thing? I'd really love to have a coreutils without that current patch on 21.11. The ZFS folks are working on a workaround (which consists of just disabling the broken functionality on their side). Do you think this can slip into the last staging(-next) cycle among the removal of the patchß0? | 22:13:58 |
| das_j | * Also what's the general opinion about the coreutils/ZFS thing? I'd really love to have a coreutils without that current patch on 21.11. The ZFS folks are working on a workaround (which consists of just disabling the broken functionality on their side). Do you think this can slip into the last staging(-next) cycle among the removal of the patch? | 22:14:00 |
| Vladimír Čunát | I find it a bit problematic that ZFS version on OS is (generally) quite decoupled from the coreutils version in nixpkgs. | 23:00:12 |
| das_j | We could mention in the release notes that a reboot is highly recommended for ZFS users and only drop the patch after 21.11 is released? | 23:01:48 |
| das_j | * We could mention in the release notes that a reboot is highly recommended for ZFS users and only drop the patch after 21.11 is released (with 21.11 backport)? | 23:02:24 |
| Vladimír Čunát | I didn't mean just a reboot. The host may not even be NixOS. | 23:03:19 |
| das_j | Oh, right | 23:03:30 |
| das_j | So drop it on master after 21.11 is released and don't backport it? | 23:04:59 |
| das_j | that gives ~6 months of time for users who are using the stable channels | 23:05:14 |
