| 24 Jan 2025 |
|  jccd joined the room. | 13:19:12 |
| jccd | Hi all, I'm a bit confused about how the community cache works. I'm trying to get a cached aarch64-linux build of mongodb as seen in the hydra logs here: https://hydra.nix-community.org/build/2596287
whenever I try and get that store path (or any other one I randomly pull from hydra) from the nix-community cachix it returns 404.
eg: curl https://nix-community.cachix.org/94r8bay2a2n10a5lrimbz5ac3dwjdik9.narinfo
or nix path-info --store https://nix-community.cachix.org -r /nix/store/94r8bay2a2n10a5lrimbz5ac3dwjdik9-mongodb-7.0.14.drv
what am I doing wrong? (hope this isnt the wrong place to ask this btw)
| 13:27:42 |
| jccd | (the same applies to the output paths as well, in this case /nix/store/pg5wacd3ry6s3rscw2w88rxabz2k8lrd-mongodb-7.0.14 | 13:28:40 |
| jccd | * (the same applies to the output paths as well, in this case /nix/store/pg5wacd3ry6s3rscw2w88rxabz2k8lrd-mongodb-7.0.14) | 13:28:44 |
 Jonas Chevalier | Good question. We don't have really good metrics on how much back-pressure the cache has. | 14:35:02 |
| Jonas Chevalier | We have 1TB allocated by Cachix, but as nix-community grows, this might now be enough | 14:35:22 |
| Jonas Chevalier | Maybe Domen Kožar can help by taking a look at the underlying metrics | 14:36:14 |
| Jonas Chevalier | 
Download image.png | 14:37:04 |
| Jonas Chevalier | It would be useful to have some sort of GC log, or upload statistics | 14:38:28 |
| Jonas Chevalier | We could create a sub-project if you want. Is that to track the GPU instance? | 14:39:37 |
| jccd | ahhh so its just expired from the cache. thanks. | 15:49:38 |
| 25 Jan 2025 |
 Roberto Abdelkader Martínez Pérez | Does the community Buildbot provide badges that I can add to my project? | 01:10:06 |
 zowoq | No, the buildbot badge plugin doesn't work with buildbot-nix. | 01:26:37 |
| Roberto Abdelkader Martínez Pérez | Ah, got it, thanks for the info! | 01:34:11 |
| Roberto Abdelkader Martínez Pérez | Sorry to ask again, but I’d like to enable Mergify for my repository and I'm not sure if it's already enabled organization-wide. Do I just need to add a .mergify.yml file to the root of my repo, or do the admins need to perform any additional setup? | 02:19:32 |
| zowoq | Only needs to be approved by an admin, it doesn't require any additional setup. We can't enable it org wide as it adds status checks to every repo. | 02:28:06 |
| Roberto Abdelkader Martínez Pérez | zowoq: Could you please enable Mergify for my repository autofirma-nix? Thanks! | 02:36:01 |
| zowoq | Done. | 02:37:40 |
| Roberto Abdelkader Martínez Pérez | 
Download image.png | 03:04:08 |
| Roberto Abdelkader Martínez Pérez | zowoq: Thanks for enabling Mergify. However, Merge Queue and Workflow Automation are still disabled (see attached screenshot). Could you please enable both? | 03:04:33 |
| zowoq | Enabled. Didn't know those were options and that they aren't the default. | 04:12:01 |
| Roberto Abdelkader Martínez Pérez | Thank you! | 10:50:57 |
 SomeoneSerge (back on matrix) | Yes, although I'm now reflecting whether runtime tests (which we need the GPU instance for) should be the first priority if the goal is to ensure stability of GPU-accelerated software.
Now that there's a community-funded hydra we can be sure to observe build failures retrospectively, and the public substituter helps with iteration times - it's a big difference compared to the previous state of affairs.
Adding the GPU instance, while sounds very cool, would further increase visibility but only for discovering breakages that already happened.
Arguably, we'd get a much bigger impact by focusing on integration with the forge now.
There are two ways we could integrate with the forge: channel-blocking and OfBorg-like.
The former is mostly about working hours: we maintain our own channel, or we enhance the logic that advances the channels so that instead of being triggered by one jobset in the official hydra it could also get a report from an external source, namely the community hydra.
The latter, like runtime tests, is about resources: we'd need a CI that can react to on-push events in Nixpkgs to evaluate and build stuff with {cuda,rocm}Support, and we'd need a github action to fetch the report. We don't even need to block PRs, we just need a linting feature that would inform authors that their change also affects the GPU variants of nixpkgs and that they could maybe ping the responsible team | 14:53:46 |
| SomeoneSerge (back on matrix) | I imagine that on-push jobs would be a lot more pressure, but as long as we can reasonably argue that this is the right platform to build this kind of CI I think there are a few more sources we can attract to the opencollective | 14:59:23 |
|  connor (burnt/out) (UTC-8) joined the room. | 15:32:46 |
|  @luxzi:matrix.org changed their display name from luxzi (they/she) to luxzi (she/they). | 20:01:16 |
| 26 Jan 2025 |
 emily | Gaétan Lepage: load average on the 10-core Darwin builder is 21.58, trying to fix stdenv | 21:17:55 |
| emily | Ihar Hrachyshka: are you running any builds? | 21:21:48 |
 Ihar Hrachyshka | emily: I do investigate the llama-cpp-python issue, yes. any issue with that? | 21:23:01 |
| emily | the box's load average is ~2× the number of cores so it's pretty overloaded right now. I was going to fire off builds to test fixes for Darwin stdenv for the next staging-next cycle (due in ~2 days), and to try and reproduce the treewide Rust FOD hash replacement and check for any Darwin-specific issues, but it's struggling even as it is | 21:24:09 |
