| 29 Oct 2024 |
 Toma | Is there a way to make hydra not cache a package?
I've seen this discussion: https://discourse.nixos.org/t/how-to-exclude-derivation-in-a-package-closure-from-the-binary-cache/50144
This would be useful for https://github.com/NixOS/nixpkgs/pull/349360, where the vendor directory is not itself a FOD, but constucted from a FOD. This would mean AFAICT that the vendor directory would always be rebuilt when its inputs change, since it's not a FOD. (The creation of the vendor directory is pretty cheap after you have the FOD)
| 21:00:07 |
| Toma | * Is there a way to make hydra not cache a package?
I've seen this discussion: https://discourse.nixos.org/t/how-to-exclude-derivation-in-a-package-closure-from-the-binary-cache/50144
This would be useful for https://github.com/NixOS/nixpkgs/pull/349360, where the vendor directory is not itself a FOD, but constucted from a FOD. This would mean AFAICT that the vendor directory would always be rebuilt when its inputs change, since it's not a FOD, polluting the cache unnecessarily. (The creation of the vendor directory is pretty cheap after you have the FOD)
| 21:00:50 |
 Christian Theune | Eelco: I'm wondering whether the namedConstituents feature should be working correctly when used recursively ... I'm seeing weird results where a job (release) that has another job (tested) as a constituent that in turn has constituents (the tests) only lists the tested job as a build dependency but not as a constituents and becomes green in hydra before tested actually has all its constituents fulfilled ... | 21:41:31 |
| 31 Oct 2024 |
 vcunat | In reply to @tomasajt:matrix.org
Is there a way to make hydra not cache a package?
I've seen this discussion: https://discourse.nixos.org/t/how-to-exclude-derivation-in-a-package-closure-from-the-binary-cache/50144
This would be useful for https://github.com/NixOS/nixpkgs/pull/349360, where the vendor directory is not itself a FOD, but constucted from a FOD. This would mean AFAICT that the vendor directory would always be rebuilt when its inputs change, since it's not a FOD, polluting the cache unnecessarily. (The creation of the vendor directory is pretty cheap after you have the FOD)
I think that discourse thread answers it all. | 12:24:37 |
| vcunat | In reply to @tomasajt:matrix.org
Is there a way to make hydra not cache a package?
I've seen this discussion: https://discourse.nixos.org/t/how-to-exclude-derivation-in-a-package-closure-from-the-binary-cache/50144
This would be useful for https://github.com/NixOS/nixpkgs/pull/349360, where the vendor directory is not itself a FOD, but constucted from a FOD. This would mean AFAICT that the vendor directory would always be rebuilt when its inputs change, since it's not a FOD, polluting the cache unnecessarily. (The creation of the vendor directory is pretty cheap after you have the FOD)
* I think the discourse thread answers it all. | 12:24:47 |
 ma27 | In reply to @ctheune:matrix.flyingcircus.io
Eelco: I'm wondering whether the namedConstituents feature should be working correctly when used recursively ... I'm seeing weird results where a job (release) that has another job (tested) as a constituent that in turn has constituents (the tests) only lists the tested job as a build dependency but not as a constituents and becomes green in hydra before tested actually has all its constituents fulfilled ... ftr I can confirm that this is a bug: the release job gets the tested derivation, but the original form with constituents being strings rather than added as input drvs. | 12:56:41 |
| 2 Nov 2024 |
 pbsds | https://hydra.nixos.org/build/276629352 builds fine for me, could use a restart | 02:46:27 |
|  Artem Markov changed their display name from Artem Markov to drownbes. | 08:42:17 |
| 3 Nov 2024 |
|  Marco Turchetto left the room. | 16:15:53 |
| Marco Turchetto joined the room. | 16:20:17 |
| 5 Nov 2024 |
|  @grossmap:in.tum.de left the room. | 14:16:21 |
|  @danmax:envs.net left the room. | 15:34:00 |
| 6 Nov 2024 |
|  Viorel-Cătălin Răpițeanu changed their display name from Viorel-Cătălin Răpițeanu to @catalin:one.ems.host. | 07:07:48 |
| 10 Nov 2024 |
|  Magic_RB changed their profile picture. | 17:48:34 |
| 12 Nov 2024 |
|  pfhuh joined the room. | 05:55:00 |
| 13 Nov 2024 |
|  Inayet joined the room. | 22:16:32 |
| 15 Nov 2024 |
|  @asymmetric:matrix.dapp.org.uk left the room. | 11:46:10 |
 John Ericson | das_j: Mic92 should we decide for nix-eval-jobs? | 16:24:18 |
| John Ericson | * das_j: Mic92 should we decide for nix-eval-jobs and Hydra? | 16:24:24 |
| John Ericson | I was would like to see the code dedup done :) | 16:24:34 |
| John Ericson | meson one is passing now too, nicely | 16:24:46 |
| John Ericson | With these changes, we can do one mega dev shell with nix perl bindings, nix-eval-jobs, and hydra, and change everything at once if we want :D | 16:25:39 |
 Mic92 | John Ericson: you want one mega repo? | 17:15:41 |
| John Ericson | Mic92: nope! | 17:15:50 |
| John Ericson | just I unpack a bunch of repos locally | 17:15:58 |
| John Ericson | and then make separate PRs | 17:16:07 |
 das_j | In reply to @Ericson2314:matrix.org
das_j: Mic92 should we decide for nix-eval-jobs and Hydra? I repeat my Github point which is that there is currently nobody willing and/or capable of maintaining that in-tree for hydra | 17:48:36 |
| das_j | So it can only go up from here | 17:48:42 |
| John Ericson | @janne.hess:helsinki-systems.de: maybe I saw those words twice but didn't understand them | 19:42:15 |
 Rick (Mindavi) | Thanks for fixing up CA derivations while you were at it 🙌🏼, guess it was a useful test to add 😶🌫️ | 20:02:38 |
