| 4 Jun 2024 |
 jade_ | https://codeberg.org/forgejo/forgejo/issues/4010 | 06:41:16 |
| jade_ | there, filed a forgejo bug about it | 06:41:23 |
 K900 | Love that issue title | 06:42:22 |
| jade_ | anyway, this kind of absurdity isn't your fault and we should keep filing bugs about these things as we find more of them :) | 06:46:22 |
 @irenes:matrix.org | for sure | 06:51:02 |
| @irenes:matrix.org | we're honestly doing something novel even just with how we accept contributions in all these ways, we should for sure be leaving a trail so others can follow | 06:51:38 |
|  quantumjump joined the room. | 11:11:51 |
|  ghpzin joined the room. | 11:13:12 |
|  raitobezarius changed their display name from raitobezarius (DECT: 7248) to raitobezarius. | 11:16:29 |
| K900 | How are we doing on the binary cache thing btw? | 14:58:39 |
| K900 | My rk3588 is dying | 14:58:41 |
| raitobezarius | i feel like we should really track nixpkgs and add a new CI job with Buildbot | 16:01:30 |
| raitobezarius | and push to the cache | 16:01:32 |
 Lunaphied | Agreed, at least for now until a better solution is proposed I would like that to be implemented, not sure if I understand enough to do it myself though | 17:00:32 |
 thubrecht | The easiest is to have a recurring job that fetches nixos-{unstable,24.05} each ~3 hours and compiles lix given those inputs | 17:05:12 |
 Qyriad | In reply to@raitobezarius:matrix.org
i feel like we should really track nixpkgs and add a new CI job with Buildbot Kate made an excellent point a bit ago which is that there's no real reason for our binary cache CI and our "does this CL break anything" CI to be the same thing, and given how insecure Nix builds are, maybe even good reason to not have that | 19:19:44 |
| @irenes:matrix.org | good point | 19:20:40 |
| Qyriad | Since like, anyone can push a CL and run an arbitrary derivation build on all our builders | 19:20:56 |
| @irenes:matrix.org | yes | 19:21:11 |
| Qyriad | But this also means that the contraints that led us to choosing Buildbot for Gerrit CLs don't apply to binary cache builds | 19:21:41 |
| Qyriad | (cc @raitobezarius again just so he sees this whenever he's around) | 19:22:27 |
| raitobezarius | In reply to @qyriad:katesiria.org
Kate made an excellent point a bit ago which is that there's no real reason for our binary cache CI and our "does this CL break anything" CI to be the same thing, and given how insecure Nix builds are, maybe even good reason to not have that i meant to build a specific branch regularly on the top of a set of channels | 19:39:21 |
| raitobezarius | not arbitrary CLs | 19:39:24 |
| raitobezarius | does your concern about the security still apply in this context? | 19:39:31 |
| raitobezarius | i'd assume that merged contents is assumed to be trusted | 19:39:40 |
| raitobezarius | hm | 19:39:50 |
| raitobezarius | but it's right we are still using it for arbitrary CLs | 19:39:57 |
| raitobezarius | so maybe there could be manipulation to push certain store paths even if the CI for arbitrary CLs wouldn't push to cache | 19:40:11 |
| raitobezarius | maybe in that case, what we can do is to have GHA infrastructure perform regular builds and push it to our cache? | 19:40:34 |
| Qyriad | In reply to@raitobezarius:matrix.org
i meant to build a specific branch regularly on the top of a set of channels what we mean is that building a specific branch regularly can perfectly reasonable be a different CI system than our CL CI system | 23:47:20 |
