| 20 Jun 2025 |
 emily | there's always going to be platform differences that make things build on one platform but another | 17:58:14 |
| emily | I do agree that making things "just work" as much as possible is good, but it trades off against other values | 17:58:28 |
| emily | (and I think Darwin is much closer to that than it used to be – FWIW there's some 500 instances of __darwinAllowLocalNetworking in the tree, which is a lot but not that many compared to how many packages we have to begin with) | 17:58:51 |
| emily | (you do still have to specify the SDK version explicitly in some cases… and sometimes dependencies should be omitted for Darwin) | 17:59:37 |
| emily | it's good when stuf fis portable as much as possible though | 17:59:44 |
| emily | but tbh most packages do not run loopback servers during tests | 17:59:52 |
| emily | I haven't thought that much about how much value we get out of needing to make it explicit, but generally I'd say derivations being able to talk over the network is a pretty bad default | 18:00:23 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @emilazy:matrix.org
I haven't thought that much about how much value we get out of needing to make it explicit, but generally I'd say derivations being able to talk over the network is a pretty bad default Why don't we disable it for Linux as well so we get some consistency | 18:00:52 |
| emily | btw, it is not needed on Hydra at all, since Hydra does not use the sandbox | 18:01:03 |
| emily | for better or worse | 18:01:11 |
| emily | (the sandbox is off by default) | 18:01:28 |
| emily | because on Linux it is actually isolated, since Linux has network namespaces and builds run in a namespace with their own loopback interface and nothing else | 18:01:44 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @emilazy:matrix.org
because on Linux it is actually isolated, since Linux has network namespaces and builds run in a namespace with their own loopback interface and nothing else I know | 18:02:08 |
| emily | Darwin sadly lacks that functionality | 18:02:09 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | But you'd make them know they are doing it wrong, rather than failing silently on some other cases | 18:02:35 |
| emily | it's not really silent, is it? that's why we have CI/ofborg | 18:11:22 |
| emily | there's no way to know whether something will build on a platform before something actually attempts the build | 18:11:37 |
 John Ericson | https://pad.lassul.us/zvvXlsRCRVeXU48WWaCpDg | 22:35:16 |
| John Ericson | We on the SC are thinking about this as a possible project to organize and fund on the foundation level | 22:35:51 |
| John Ericson | were curious what the Stdenv Team thinks about this | 22:36:08 |
| John Ericson | CC tomberek | 22:36:11 |
| John Ericson | to be clear, at this point, we're thinking more about the first step of a relocatable store | 22:36:42 |
| emily | it was discussed here recently :) | 22:41:02 |
| emily | here | 22:41:16 |
| emily | it's something I've thought about before, there are some tricky issues I outlined, I expect somewhat invasive patching across the tree would be necessary, but the initial hurdles are more writing loader code etc. | 22:41:52 |
| emily | I think it would be feasible but hard (and some packages may never work) | 22:42:19 |
| emily | I see this came up as DT_INTERP in the doc. I think you can just solve the problem by avoiding the kernel's code for it as I outlined earlier. | 22:43:02 |
| emily | IIRC #!/usr/bin/env -S is not portable wrt macOS so may not be a good solution for shebangs. | 22:43:44 |
| emily | might be workaroundable. | 22:43:58 |
| John Ericson | oh my bad | 22:44:08 |
