| 9 Oct 2024 |
 Alyssa Ross | or at least, I'm very not confident that there is one | 19:40:26 |
 Tristan Ross | Could also detect if -m32 or -m64 is specified but aside from -target and -m, idk any other ways. | 19:41:57 |
| 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 |
