| 18 Jun 2025 |
 aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | In reply to @reckenrode:matrix.org
Yeah, to see if there are other unmaintained packages in the major platform bootstraps. It's up to them to decide. | 17:34:16 |
| aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | Currently I just want to reduce this kind of warning which is not actionable enough for ordinary users | 17:34:56 |
| aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | In reply to @reckenrode:matrix.org
If someone later wants to take over one if these packages, would the stdenv team be dropped from them? Also the same | 17:35:40 |
| aleksana š³ļøāā§ļø (force me to bed after 18:00 UTC) | We probably don't want to see someone who just added themselves to the maintainer list take up maintenance work, because merging r-ryantm unconditionally may still cause some chaos | 17:37:38 |
 Alyssa Ross | TBH you may be overestimating how much care goes into committer-merged updates to stdenv dependencies š | 17:40:02 |
| Alyssa Ross | (Not saying this isn't a good idea) | 17:42:00 |
|  tomberek joined the room. | 17:45:59 |
| tomberek | Would the stdenv folks be interested in a relocatable store, a relocatable Nix? The SC is exploring this as a possible roadmap effort and a big part of it would be building some momentum with the core+stdenv that requires more specialized experience. Don't have all the details figured out, but trying to gauge the interest. | 17:57:09 |
| Alyssa Ross | There are situations where it would be useful for sure but I'd expect it to be an immense effort | 17:58:02 |
 WeetHet | In reply to @tomberek:matrix.org
Would the stdenv folks be interested in a relocatable store, a relocatable Nix? The SC is exploring this as a possible roadmap effort and a big part of it would be building some momentum with the core+stdenv that requires more specialized experience. Don't have all the details figured out, but trying to gauge the interest. Not an stdenv folk but if I understand correctly, this would allow moving the darwin store out of a separate partition which would certainly be nice | 18:02:22 |
 emily | I've explored the idea (not in code, just in my head) and I would like it but I agree with Alyssa that it would be super tough in a lot of ways ā it's not just linker stuff but a bunch of ecosystems fractally expecting absolute paths to work, so I think it would involve substantial patching of many many packages | 18:03:14 |
| emily | (hopefully some of that could go upstream, but I know some projects are happy assuming absolute paths) | 18:03:31 |
| tomberek | It being a large effort is why we're trying to see if there is interest, what kind of funding would be needed, to do a feasibility analysis, etc. | 18:03:35 |
| emily | linker stuff is an issue too though: e.g., the path to the dynamic loader for Linux shared executables is absolute, and that's a kernel-level limitation. you can use $ORIGIN in library paths but not for the loader itself. I think you can work around it by linking binaries as effectively "static PIEs" with their own startup code that finds their dynamic loader and execs it | 18:04:37 |
| emily | but definitely pretty deep toolchain surgery to make that work, I've wanted to prototype it but no time | 18:04:53 |
| emily | (not sure if an explicit exec would always work without weirdness or if it'd have to be "load the dynamic loader into memory in userspace" which would be painful) | 18:05:46 |
| Alyssa Ross | My instinct here is that the cure is worse than the disease | 18:32:21 |
 Randy Eckenrode | In reply to @weethet:catgirl.cloud
Not an stdenv folk but if I understand correctly, this would allow moving the darwin store out of a separate partition which would certainly be nice Having it on a separate partition also comes with benefits (like being able to have a case-sensitive store). | 19:56:10 |
| Randy Eckenrode | Relocatable store seems like it would have the same difficulties as CA derivations with needing to update path references. | 19:58:13 |
| Randy Eckenrode | Iād rather see CA derivations stabilized if I had to choose. | 19:58:35 |
|  rosssmyth joined the room. | 20:48:00 |
| rosssmyth | I really like the work that has been going into stdenv recently. Primarily from Tristan Ross (though others too). I try silly stdenv stuff at work often and the work being done make it more possible to do in the future. | 21:02:18 |
| rosssmyth | thanks | 21:02:19 |
| rosssmyth | 376197 is one I am looking forward too because I tried wrestling pkgsCross in the past and the way the CPU attributes are setup now made it harder than it needed to be | 21:04:20 |
| rosssmyth | * 376197 is one I am looking forward to because I tried wrestling pkgsCross in the past and the way the CPU attributes are setup now made it harder than it needed to be | 21:04:24 |
 Tristan Ross | In reply to @rosssmyth:matrix.org
376197 is one I am looking forward too because I tried wrestling pkgsCross in the past and the way the CPU attributes are setup now made it harder than it needed to be Yeah, that PR is delayed because the toolchain attributes PR is needed. | 21:06:04 |
| rosssmyth | I work in embedded, so I've found some fun corners of the pkgsCross system that lead to me mainly giving up on using it for now. One is that cmake's targets are not the same as clang's, so for certain triples compiler-rt seems to be built for the wrong target. I think that was the outcome of one afternoon of staring at logs a couple months ago. | 21:12:53 |
| Tristan Ross | Yeah, that's one of the use cases that I had thought of for the platform improvements | 21:14:58 |
| Tristan Ross | The idea is to be able to manipulate as much as possible. | 21:15:10 |
| Tristan Ross | There's obviously combinations which don't work | 21:15:35 |
