| 6 Sep 2024 |
 emily | eh, my experience is that the builders are unused a large fraction of the time | 08:01:43 |
 magic_rb | (Mark the symlink readonly or smth so it cannot be gotten rid off) | 08:01:46 |
| emily | I don't mind people "hogging" it because I hog it at other times too :) | 08:01:50 |
| emily | though some kind of smart automatic scheduling could be cool | 08:02:04 |
 Jonas Chevalier | yes that would be real game changer. if we had good scheduling support, with priorities and resource accounting, we could also make the CI machines available, and reversely. But that's quite a bit of R&D | 08:24:59 |
| emily | it's not so bad to have to manually check in practice since often you need to baby-sit builds anyway | 08:26:29 |
| emily | (periodic "thanks for the builders, they make working on big Nixpkgs changes tolerable" :) ) | 08:26:40 |
| Jonas Chevalier | if we think crazy in the future, potentially, we could build every project on GitHub with a flake.nix | 08:32:39 |
| Jonas Chevalier | :p | 08:32:50 |
 nim65s | sounds like a job for slurm or similar | 08:41:54 |
| emily | In reply to @zimbatm:numtide.com
if we think crazy in the future, potentially, we could build every project on GitHub with a flake.nix yeah, like Nixpkgs! | 08:43:22 |
 Gaétan Lepage | Hi,
I have to admit that I often find myself heavily using the builders. Many of the packages I maintain are a pain to build and take a lot of resources. | 08:44:02 |
| Gaétan Lepage | Also, I very rarely explicitly SSH the builders and simply have them configured as remote-builders on my personal system.
Wouldn't messaging techniques like wall be inefective in this aspect ? | 08:45:04 |
| Gaétan Lepage | Maybe, there could be a matrix room with all the people that have been allowed to use the builder. What do you think ? | 08:45:58 |
| emily | I guess probably many people use them as remote builders. I don't because I'm paranoid and don't trust them | 08:47:39 |
| Jonas Chevalier | yeah good point. this is the matrix room | 08:47:42 |
| Jonas Chevalier | we should probably ask everybody to join this room | 08:48:04 |
| emily | having another room just for that traffic doesn't seem like a bad idea, but I'm not sure there's sufficient cause for it at present | 08:48:04 |
| emily | usually I just notice my builds are going very slow, check top, and go oh okay let's do it later then | 08:48:18 |
| Gaétan Lepage | Yes, I meant having a dedicated one, because this room also has other uses.
But, indeed, it might be overkilled. | 08:49:26 |
| emily | what would really be nice is something more useful than top so that you can see what's actually getting built and how much CPU it's using, esp. if you're running a bunch of builds and one of them is hogging all the CPU or whatever | 08:51:28 |
| emily | (but also to snoop on what others are up to and how long it's likely to take) | 08:51:36 |
| emily | I tried out nix-top but it didn't seem like it really had the info I wanted (some kind of hierarchical breakdown by nix build job, sorted by CPU) | 08:52:00 |
| Gaétan Lepage | That would be immensely helpful indeed. | 08:52:01 |
| Jonas Chevalier | the nix-daemon could also retain who scheduled the build with a little bit of patching | 08:53:36 |
| Jonas Chevalier | * the nix-daemon could also retain who scheduled the build with a little bit of patching (using SO_PEERCRED) | 08:54:43 |
|  Thom Jordan joined the room. | 18:21:14 |
 aidalgol | I've had a few people ask me about moving https://github.com/nix-community/steam-fetcher into nixpkgs. I'm not sure it really belongs there. Any thoughts on this? | 20:14:44 |
| emily | I don't think we'd want to package arbitrary steam games | 20:17:54 |
| magic_rb | +1 dont think this belongs in nixpkgs, the results can never be cached anyway | 20:19:14 |
