| 19 Jun 2026 |
 hexa | 
Download | 20:33:49 |
| hexa | I think we're not quite there yet with uploads to s3 🤔 | 20:33:59 |
 John Ericson | long term I hope to make us not use the queue runner store entirely | 21:22:02 |
| John Ericson | everything should be binary cache or database | 21:22:12 |
| John Ericson | and evaluations should be distributed to builders just like regular build | 21:22:21 |
|  morwdan joined the room. | 23:16:29 |
| 20 Jun 2026 |
 Mic92 | @hexa:lossy.network: when see a lot of receiving uploads, check also the load on the machine | 04:19:38 |
| Mic92 | Because if all CPUs are working, I don't think we can make compression go much faster | 04:20:17 |
| Mic92 | Yesterday I reduced the number of concurrent uploads a bit again because it was causing issues on some smaller machines. I want to optimise a bit more for stability first before going for maximum throughput | 04:21:53 |
| Mic92 | * @hexa:lossy.network: when you see a lot of receiving uploads, check also the load on the machine | 04:22:33 |
| Mic92 | The current upload code for S3 is also not optimal. Usually one should auto scale connections based on what the S3 store respond in terms of error codes | 04:25:04 |
| Mic92 | I would like to get log and open telemetry collection to work. Than we get more insights | 04:26:21 |
| Mic92 | * The current upload code for S3 is also not optimal. Usually one should auto scale connections based on what the S3 service respond in terms of error codes | 04:26:42 |
 Vladimír Čunát | I wondered why big-parallel builds are in so much trouble since the switch, and apparently we build them with -j1 | 05:56:57 |
| Vladimír Čunát | At least the kernels I see building right now are that way. Some builds do not seem to log the make-parallelism level (e.g. chromium but those I saw now fail due to out-of-disk, as... the temp build space is tmpfs I think) | 05:59:47 |
| Vladimír Čunát | Yes, firefox here with -j1 as well:
https://hydra.nixos.org/log/adgkzznigqcx9zyjaqwldaln30rcqjsg-firefox-beta-unwrapped-151.0b9.drv | 06:00:19 |
| Mic92 | Okay that's hopefully an easy fix | 06:00:42 |
| Mic92 | I published my fast-nix-gc fixes I came up when I had to battle with the 1TB nix store / 58GB sqlite nix db: https://github.com/Mic92/fast-nix-gc/pull/45 | 06:04:46 |
| Mic92 | Deploying to staging now | 06:30:33 |
| Vladimír Čunát | _I'll be away from a computer for most of today._ | 06:51:05 |
| Vladimír Čunát | * I'll be away from a computer for most of today. | 06:51:20 |
| Mic92 | QA passed for the fixes. I will now proceed production hydra. | 07:08:28 |
| Mic92 | * QA passed for the fixes. I will now proceed with production hydra. | 07:09:46 |
 K900 | Maybe don't | 07:09:47 |
| K900 | It's been building a kernel for 7 hours | 07:09:56 |
| K900 | We might want to let it finish | 07:09:57 |
| Mic92 | K900: build number? | 07:10:20 |
| K900 | There's a bunch | 07:11:49 |
| K900 | Just search for "linux-" on /status | 07:12:03 |
| Mic92 | https://hydra.nixos.org/build/331695810/nixlog/1 matches the description | 07:13:12 |
