| 14 May 2024 |
 samrose | In reply to @k900:0upti.me
That is basically Hydra I guess what I describe is more like a metadata system that can include eval and build data hydra does + data about where things are cached and doesn't have to be tied to one package set or hydra instance or whatever | 13:40:33 |
 K900 | If you want to run that globally, there's trust issues | 13:41:17 |
| samrose | In reply to @k900:0upti.me
But every time I've seen it used it ended up eventually not being enough and then people started building tools around it that just made things more complicated it's not much different than architecting with any other API/service approach, really. And I agree this issue is always a factor when choosing that approach. | 13:41:44 |
| samrose | In reply to @k900:0upti.me
But every time I've seen it used it ended up eventually not being enough and then people started building tools around it that just made things more complicated Thanks for sharing this perspective | 13:41:57 |
| samrose | In reply to @k900:0upti.me
If you want to run that globally, there's trust issues Oh yes of course. | 13:42:07 |
| samrose | In reply to @k900:0upti.me
Has anyone actually tried building dyndrvs on Hydra? what's an example of a dyndrv to try out on hydra? | 13:46:32 |
| K900 | There is none in nixpkgs at least | 13:47:04 |
| K900 | You can probably copy something from the original RFC | 13:47:11 |
| K900 | Assuming those even build | 13:47:15 |
 Julia | anyone else occasioally experiencing firefox freezing? cpu usage drops to 0, doesn't react to any user input | 13:50:57 |
| Julia | (using 124.0.2, sway) | 13:52:09 |
| Julia | * (using 124.0.2, swayfx) | 13:52:25 |
| samrose | In reply to @k900:0upti.me
Assuming those even build they may have some problems I used to work at flox from about 2022 - start of this year. Now I recall this, although I had forgotten that it was even an RFC :) I kinda feel about this how you feel about postgrest :) but for different reasons. I think maybe that RFC may need more baking in the oven to think through the impact of dynamically generating derivations. But seems like it could be a good option to turn on for very large builds if it works well (like nixpkgs, linux, etc) but to be fair he said
Really, this RFC is just proposing that we create the experimental feature.
So I guess there are a lot of unknowns and the RFC wanted to create the experimental feature, explore how it works and evolve it. Sounds like fun anyway
| 14:00:55 |
| K900 | I am not all the way convinced dyndrvs are the solution | 14:01:42 |
| K900 | But they are a solution and the problem they attempt to solve is becoming big for nixpkgs | 14:01:53 |
| K900 | So I'd like to have something | 14:01:57 |
| samrose | In reply to @k900:0upti.me
I am not all the way convinced dyndrvs are the solution but the proposition does seem to show some issues with nix, so I think you are right on that it is worth exploring | 14:02:32 |
| samrose | In reply to @k900:0upti.me
But they are a solution and the problem they attempt to solve is becoming big for nixpkgs probably it can work and my guess is that it needs more exploration | 14:06:35 |
| *  @tc424:glasgow.social wonders why nix copy has claimed to upload several gigs of data, when the resulting s3 bucket contains only 60mb of objects | 14:09:14 |
 puck | oh, this is a known-ish bug, but we haven't been able to find all the sources of it | 14:09:38 |
| @tc424:glasgow.social | In reply to@puck:puck.moe
oh, this is a known-ish bug, but we haven't been able to find all the sources of it was slightly worried I was going bonkers :) | 14:11:14 |
| puck | what was your nix copy command line like? | 14:11:42 |
| samrose | In reply to @k900:0upti.me
I am not all the way convinced dyndrvs are the solution yeah you could be right about this,and it does seem like the rfc is a good start and likely this approach could be part of the solution if it's not "the" solution so I shouldn't come across personally like I am rejecting it. Lix definitely needs something like this | 14:12:16 |
| @tc424:glasgow.social | In reply to@puck:puck.moe
what was your nix copy command line like? nix copy --to "s3://muslpi?endpoint=http://aux-test.lan:3900®ion=garage" $(which armv6l-unknown-linux-musleabihf-gcc) | 14:13:19 |
| @tc424:glasgow.social | In reply to@tc424:glasgow.social
nix copy --to "s3://muslpi?endpoint=http://aux-test.lan:3900®ion=garage" $(which armv6l-unknown-linux-musleabihf-gcc) nix-store -qR $(which armv6l-unknown-linux-musleabihf-gcc)output looks sane | 14:14:30 |
| puck | okay, nothing specal then; should be able to figure it out | 14:15:14 |
| puck | * okay, nothing specal then; should be able to figure it out with that | 14:15:17 |
| samrose | In reply to @k900:0upti.me
You can probably copy something from the original RFC I'll try it sometime soon and let you know if that helps | 14:18:38 |
 Qyriad | I'm pretty sure Lunaphied tried this and determined that the implementation in Nix (and thus Lix) is not far enough for all but the most trivial cases, and even those require combining it with recursive Nix iwrc | 14:19:55 |
 Lunaphied | Yes; well more specifically as part of rolling back a bug it introduced, dynamic derivations don't really currently do anything because you can't build their referenced outputs lol. you can use recursive Nix to invoke the output and build it from another drv though but it's a workaround and there's no need for that approach if you already have recursive Nix | 14:22:13 |
