| 27 Jun 2026 |
Mic92 | In reply to @hexa:lossy.network we can try fast-nix-gc It also can skip recently added paths. And we can actually block on gc.lock now | 14:33:49 |
hexa | that's what I meant here | 14:34:09 |
hexa | can you pick your connection pooling change on top of hydra.nixos.org? | 14:34:28 |
hexa | so we can merge | 14:34:31 |
Mic92 | * It also can skip recently added paths. And we can actually block on gc.lock now to not schedule new builds. It will now create more io | 14:34:35 |
Mic92 | * It also can skip recently added paths. And we can actually block on gc.lock now to not schedule new builds. It will now create more io anyway, so might be for the best to not schedule new builds during that | 14:35:44 |
Mic92 | In reply to @hexa:lossy.network can you pick your connection pooling change on top of hydra.nixos.org? I have on my laptop but not yet pushed. Need to wait for my train | 14:36:22 |
hexa | i fairness, we now also clean out logs much more reliably on darwin | 14:41:54 |
hexa | everything in macs/common/workarounds.nix | 14:42:15 |
hexa | so we have more headroom anyway | 14:42:24 |
hexa | I have fast-nix-gc prepared locally | 15:22:20 |
Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org Sergei Zimmerman (xokdvium): how easy would it be to have an option for "refuse to try building something if some of its outputs are present" that defaults on if fallback paths would be used (i.e. macOS, unsandboxed Linux) and then we could set it on for all of Hydra? Should be doable | 15:25:47 |
emily | can it extend to "don't try to build if any of the other outputs are able to be substituted"? :) | 15:26:21 |
Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org can it extend to "don't try to build if any of the other outputs are able to be substituted"? :) Harder, but maybe doable | 15:29:34 |
emily | tbh the macOS case is more concerning since at least in principle frankenbuilds without fallback paths should never actually be a problem unless packages are non-reproducible | 15:30:19 |
Mic92 | In reply to @emilazy:matrix.org can it extend to "don't try to build if any of the other outputs are able to be substituted"? :) Queue builder always requires inputs to be substituted | 15:38:04 |
emily | this is siblings though (outputs of the same derivation), rather than inputs | 15:38:23 |
Mic92 | It could ignore all inputs that haven't been signed by hydra... And sign local paths after upload. | 15:42:58 |
Mic92 | Or queue runner specifies the content addressed path instead of the input addressed one | 15:45:30 |
emily | I don't understand what that does for sibling outputs, since those aren't inputs? | 15:52:42 |
hexa | Jun 27 19:05:46 mimas hydra-evaluator[1724970]: created cached eval 1826650
Jun 27 19:05:46 mimas hydra-evaluator[1867846]: evaluation of jobset ‘nixos:unstable-small (jobset#240)’ succeeded
| 19:08:03 |
hexa | https://hydra.nixos.org/eval/1826650 | 19:08:09 |
hexa | does not get listeed in https://hydra.nixos.org/jobset/nixos/unstable-small | 19:09:03 |
hexa | retrying | 20:24:54 |
hexa | this time it went … cool. | 20:25:41 |
| 28 Jun 2026 |
| Eymeric joined the room. | 08:40:34 |
Eymeric | Hi! From my home Internet connection in Vietnam (ip: 14.160.32.91), https://hydra.nixos.org doesn't work correctly. Instead of the normal Hydra UI, I get a small HTML page with random-looking text (starting with Forward. The man in the middle of the European and Asiatic land-mass, from Portugal to....).
I compared it with machines I have in France and elsewhere. They all resolve the same IP (157.90.104.34), present the same TLS certificate (CN=hydra.nixos.org), and serve the normal Hydra page. The issue also disappears if I use a VPN from Vietnam.
Is there any sort of geo-blocking, filtering, or infrastructure issue that could explain this?
| 08:41:21 |
Sandro | You've run into the bot detection 😂 | 08:43:36 |
Sandro | @hexa:lossy.network | 08:43:56 |
Eymeric | Could it just be that the IP has a bad reputation or do the bot detection need more hints ? | 08:46:35 |