9 Oct 2024 |
Tristan Ross | And this mainly only matches on the arch name so other vendor/os names won't trip up the detection at least. | 19:42:29 |
Tristan Ross | At least the kernel only uses -target it seems for the case I ran into. | 19:43:39 |
10 Oct 2024 |
linj | Sorry for cross-posting. What is the difference between stdenv.shell and runtimeShell ? I want to do something like make SHELL=${runtimeShell} during build. | 02:14:12 |
Tristan Ross | Idk either, I can figure out from grepping | 02:15:07 |
Tristan Ross | stdenv.shell seems to be the one which can run the builder. Not sure what runtimeShell = prevStage.ccWrapperStdenv.shell; exactly means. | 02:16:59 |
Tristan Ross | Oh, they're mostly the same | 02:17:32 |
linj | In reply to @rosscomputerguy:matrix.org
stdenv.shell seems to be the one which can run the builder. Not sure what runtimeShell = prevStage.ccWrapperStdenv.shell; exactly means. Oh, I do not mean this runtimeShell, I mean pkgs.runtimeShell . | 02:18:16 |
Tristan Ross | In reply to @me:linj.tech Oh, I do not mean this runtimeShell, I mean pkgs.runtimeShell . Oh, it's an alias of runtimeShellPackage | 02:18:53 |
Tristan Ross | But it references the actual exec | 02:19:06 |
Tristan Ross | Basically like doing lib.getExec pkgs.runtimeShellPackage which the runtime shell package is bash | 02:19:34 |
Artturin | In reply to @me:linj.tech Sorry for cross-posting. What is the difference between stdenv.shell and runtimeShell ? I want to do something like make SHELL=${runtimeShell} during build. Shell for build vs shell for host | 02:23:10 |
linj | Thanks | 02:27:04 |
| 6pak joined the room. | 16:32:41 |
11 Oct 2024 |
Tristan Ross | https://github.com/NixOS/nixpkgs/issues/347955 | 16:50:21 |
| Pratham Patel (you can mention me) joined the room. | 17:12:36 |
Tristan Ross | https://github.com/NixOS/nixpkgs/pull/347959 | 17:35:33 |
emily | FWIW a maintainer team to list in packages / ci/OWNERS seems like a good idea but I don't think we can really give them concrete authority absent SC decisions about how decision-making should be structured | 17:36:02 |
emily | and it's unclear to me if that would want, e.g. a general core team, a core Linux team specifically, or a more focused stdenv team, or what | 17:36:20 |
emily | right now, I don't know if it makes sense to have the same people listed on both Darwin and Linux stdenvs, because their de facto maintainers are almost entirely disjoint | 17:36:44 |
emily | though | 17:36:50 |
emily | again it depends on what you count as stdenv | 17:36:53 |
Alyssa Ross | wouldn't this be more about codifying existing practice? | 17:37:11 |
emily | the shared code and the platform bootstraps are pretty different things | 17:37:06 |
Tristan Ross | My main thing is just to form an stdenv team from people who have had a stake in it's development. Once the SC is ready, they would be responsible for fine tuning things. | 17:37:11 |
emily | I am in favour of codifying existing practice | 17:37:35 |
emily | just want to make sure that's what we're actually doing | 17:37:39 |
Alyssa Ross | like, de facto certain stdenv changes do get blocked on waiting for somebody authoratative (via their expertise) to check it | 17:37:49 |
emily | right | 17:37:55 |
emily | (I mostly think we should make sure the structure maps to that de facto practice) | 17:38:36 |
Tristan Ross | I'm mostly looking for:
- Better communication
- Getting more PR's and issues figured out and resolved
| 17:39:51 |