| 18 Jul 2025 |
 fricklerhandwerk | * shameless plug, PR reviews appreciated raitobezarius | 07:24:31 |
| 19 Jul 2025 |
|  Cobalt joined the room. | 19:20:32 |
| Cobalt | Hey would the creation of a European nix cache mirror be of interest? $work has somewhat recently had a few hundred TB of free flash storage available after a storage system was decomissioned (and HDDs were sold).
We would plan for a pull through cache, i. e., likely only pull from upstream once for the first request of a file and store on disk afterwards. | 19:27:34 |
 K900 | Bandwidth is more of a concern than storage | 19:27:55 |
| K900 | For an operation like this | 19:27:57 |
 dramforever | is there any reason fastly isn't, well, fastly enough in europe? | 19:28:36 |
 emily | my experience is that Fastly maxes out my connection on the second download | 19:28:59 |
| emily | and on the first (i.e. not cached at my edge location yet) it's like 500 Mbit/s | 19:29:15 |
| dramforever | there a bunch of these kind of mirror sites in china | 19:29:21 |
| emily | dunno if limited by Fastly or S3 there | 19:29:22 |
| dramforever | but well, china | 19:29:23 |
| Cobalt | No, this is more finding a use for the storage. We can't sell/give it away easily and would like to put it to some good use. We have a 40G uplink iirc, with more for DFN | 19:29:39 |
| Cobalt | Ipv6 uplink is larger but might be difficult to implement | 19:31:39 |
 hexa | we can eventually push hydra results to multiple s3 buckets | 19:33:05 |
| hexa | * we can eventually push hydra results to multiple s3 buckets with the new queue-runner | 19:33:10 |
| hexa | so we could in theory fan than out | 19:33:22 |
|  n4ch723hr3r joined the room. | 19:40:51 |
| Cobalt | That sounds interesting but likely a lot more complex for upstream. If fastly is enough than this can likely also be postponed.
Thanks for the info about Hydra though. Maybe that is something to come back to later | 19:44:09 |
| 20 Jul 2025 |
| hexa | loading build 302783248 (nixpkgs:cross-trunk:rpi.mpg123.aarch64-darwin)
queue monitor: error:
… while loading build 302783248:
… while parsing derivation '/nix/store/l43yj5i4g570a79vi4k1n2p2lla85ppg-systemd-minimal-armv6l-unknown-linux-gnueabihf-257.6.drv'
error: attribute 'disallowedReferences' must be a list of strings
| 12:50:13 |
| hexa | vcunat: you saw this before, right? | 12:50:20 |
| hexa | killed the relevant build and now we're game again | 12:53:02 |
| hexa | annoying | 12:53:13 |
 Vladimír Čunát | Yes, this one but on a different derivation, apparently. | 13:43:21 |
| 21 Jul 2025 |
|  Cathal joined the room. | 19:46:11 |
| 22 Jul 2025 |
|  @drupol:matrix.org joined the room. | 12:38:28 |
| @drupol:matrix.org | Hey, do you have any idea why cache.nixos.org could be extremely slow at work? I contacted the helpdesk, and they confirmed there are no restrictions on their side... they suggested the issue might be external. The behaviour is strange: downloading just 30 MB takes around 15 minutes. It seems to follow a repeating pattern: the connection works normally for 1–2 seconds, then pauses for about 30 seconds, and this cycle continues indefinitely until the end. Nix is barely usable here :( Any idea how I could further investigate or troubleshoot this? Thanks! | 12:39:15 |
| @drupol:matrix.org | (feel free to redirect me to the right channel for this) | 12:46:09 |
| @drupol:matrix.org | Here's the traceroute session: https://gist.github.com/drupol/3825ac49a93c1f2d04c91286edf8e19a | 12:58:33 |
| @drupol:matrix.org | And a mtr session | 13:00:21 |
| @drupol:matrix.org | 
Download image.png | 13:00:25 |
