| 9 Sep 2021 |
 @grahamc:nixos.org | I think there is/was an alert on jobs that are taking a long time: https://monitoring.nixos.org/grafana/d/j0hJAY1Wk/in-progress-build-duration-heatmap?orgId=1&refresh=30s | 11:40:15 |
| @grahamc:nixos.org | yeah: https://monitoring.nixos.org/prometheus/alerts maybe we could get it posting to matrix | 11:40:37 |
 Vladimír Čunát | In reply to @grahamc:nixos.org
fwiw it doesn't look like a capacity issue at the moment, since there are macs that are able to take work but aren't given any Then something is wrong.
"x86_64-darwin" : {
"runnable" : 8939,
"running" : 55,
"waitTime" : 981988989
},
| 11:43:20 |
| @grahamc:nixos.org | yeah ... I have found runnable to be misleading ... but I don't remember the why ..... | 11:44:26 |
| @grahamc:nixos.org | I've done autoscaling based on runnable andended up running dozens of totally idle machines for days as a result | 11:47:59 |
| @grahamc:nixos.org | I have a client facing similar mysterious issues and wants to look in to them ~soon, but not yet | 11:51:24 |
 baloo | https://github.com/NixOS/nixpkgs/pull/137197 this should fix the dns resolution failure on hydra | 16:06:24 |
| @grahamc:nixos.org | Maybe we can get Eelco to do a release instead of apply patches | 16:10:19 |
| Vladimír Čunát | Well, it's relevant what nix gets deployed to the machines, not what we have in nixpkgs. | 16:10:27 |
| Vladimír Čunát | (at least for hydra.nixos.org failures) | 16:10:38 |
| Vladimír Čunát | * (at least for hydra.nixos.org failures, of course you can get the same anywhere else as well) | 16:12:01 |
 Rick (Mindavi) | It's time for a release anyway, he wrote it on discourse too | 16:16:52 |
| Rick (Mindavi) | I guess they still want to do some tickets, but at some point it would be good if there was a stable 2.4 | 16:17:28 |
| Rick (Mindavi) | Oh, a 2.3 release of course :) | 16:17:47 |
| baloo | In reply to @grahamc:nixos.org
Maybe we can get Eelco to do a release instead of apply patches I mean, whichever is the fastest is fine by me :) I was mostly chasing r13y myself, and I know it pulls nixpkgs version. | 16:33:53 |
| 11 Sep 2021 |
 sterni | The status.nixos.org page seems to behind? nixos-unstable is at bbbe2b35f736d039884e082ecc6d6e631e126029, but it says 4f6d8095fd51954120a1d08ea5896fe42dc3923b | 13:45:55 |
| sterni | ah no the channel is still behind, but the nixos-unstable branch in nixpkgs is ahead of that? | 13:46:34 |
 lukegb (he/him) | that comes from https://nixos.org/channels/nixos-unstable/git-revision | 14:21:24 |
| sterni | seems like the population of the branch should be tied to the channel update service?
> git fetch origin && git rev-parse origin/nixos-unstable
bbbe2b35f736d039884e082ecc6d6e631e126029
| 14:23:04 |
 Jonas Chevalier | that was supposed to be fixed by https://github.com/NixOS/nixos-channel-scripts/pull/49 | 14:39:54 |
| lukegb (he/him) | Lemme just PURGE all the channels out of Fastly | 14:40:50 |
| sterni | ah right it's the caching problem that makes more sense | 14:41:32 |
| Jonas Chevalier | purge sent | 14:42:04 |
| lukegb (he/him) | status.nixos.org seems happier now | 14:42:46 |
| Jonas Chevalier | please ping me if you see more caching issues in the future | 14:43:59 |
| baloo | for what it's worth, s-maxage only affects the first cache | 15:53:01 |
| baloo | a Cache-Control: header would serve the same purpose, and allow each layer to implement the same strategy. | 15:53:27 |
| baloo | should someone (entreprise user) have another cache in between, he would not see the benefits | 15:53:55 |
| baloo | I think it would make sense to juste use max-age and not s-maxage | 15:54:44 |
| baloo | * a max-age in the Cache-Control header would serve the same purpose, and allow each layer to implement the same strategy. | 15:55:11 |
