| 15 Apr 2026 |
 EsperLily [she/her] | i don't have time right now to dig into this, but it seems like maybe cargo and rustc should use the appropriate disallowedWhatever attribute to ensure the bootstrap doesn't accidentally get into the closure | 00:09:50 |
| EsperLily [she/her] | (rustc itself doesn't seem to have its own bootstrap at least, but the cargo-bootstrap includes the rustc-bootstrap) | 00:10:11 |
| EsperLily [she/her] | this whole thing is in my runtime closure only because i have rustfmt in there (because of prettybat, which i never remember to even use) | 00:11:36 |
 Winter | i can take a peek later today | 00:12:46 |
| EsperLily [she/her] | https://github.com/NixOS/nixpkgs/pull/510169 | 05:04:09 |
|  @98765abc:mozilla.org left the room. | 06:50:12 |
|  voxel ⚡️ joined the room. | 19:20:37 |
| 16 Apr 2026 |
| EsperLily [she/her] | Alyssa Ross: regarding the above PR, since you complained about overrideAttrs I just dug into the reason why rustPlatform.rust.rustc is deprecated and it turns out you did that 2 years ago in https://github.com/NixOS/nixpkgs/pull/230951 and cited nativeBuildInputs = [ rustPlatform.rust.rustc ] misbehaving as the reason. I really think the right move here is to undeprecate rustPlatform.rust.{rustc,cargo} and just fix that original issue, which AFAICT is really just caused by the package being spliced but coming from the buildPackages set. It seems to me we can fix that by unsplicing the package? And I think this is the right move because it's pretty weird right now that a package using rustPlatform has no way to reference the rustc/cargo that are being used to build it, especially since we expose pkgs.makeRustPlatform so people can make their own custom rust platforms | 04:11:55 |
 Alyssa Ross | I think you're right. In the long term we should get rid of the non-composable buildRustPackage but that's harf. | 05:07:48 |
| Alyssa Ross | * | 05:07:52 |
| EsperLily [she/her] | i updated the PR to do that | 05:21:32 |
| Alyssa Ross | thanks | 05:23:20 |
| EsperLily [she/her] | i suppose i should take this opportunity to add disallowedReferences to rustc-unwrapped too, as long as we have to rebuild all of the rust packages anyway | 06:49:32 |
 eveeifyeve | I will ask in here. Can someone when the relibc is merged into nixpkgs, when there is a rustc update can you ping the redox team please? Because we will need to check if that breaks relibc as a lot of C Api's get changed on unstable. An example of this was with 1.94 with VaListImpl being renamed to VaList. | 22:20:22 |
| eveeifyeve | * I will ask in here. Can someone when the relibc is merged into nixpkgs, when there is a rust update can you ping the redox team please? Because we will need to check if that breaks relibc as a lot of C Api's get changed on unstable. An example of this was with 1.94 with VaListImpl being renamed to VaList. | 22:22:25 |
| eveeifyeve | * I will ask in here. Can someone when the relibc is merged into nixpkgs, when there is a rust update can you ping the redox team please? Because we will need to check if that breaks relibc as a lot of C Api's get changed on unstable. An example of this was with 1.94 with VaListImpl being renamed to VaList due to it wanting to be C-Abi compatible. | 22:24:23 |
 Charles | Tbh I don't think putting relibc in nixpkgs is a good idea at this point because of its reliance on so many nightly features | 22:36:42 |
| Charles | Redox upstream is aware that relibc doesn't build on newer rustc versions and the recommendation I got is "just use an older rustc" which isn't really an option for nixpkgs aiui | 22:37:56 |
| Charles | I think nixpkgs probably has enough stuff in it to support doing Redox things with it out of tree, so that's probably best to do for the time being until the reliance on volatile nightly features goes away | 22:39:18 |
| Charles | * I think nixpkgs probably has enough stuff in it to support doing Redox things with it out of tree, so it's probably best to just do that for the time being, until the reliance on volatile nightly features goes away | 22:39:53 |
| Charles | In reply to @charles:computer.surgery
Redox upstream is aware that relibc doesn't build on newer rustc versions and the recommendation I got is "just use an older rustc" which isn't really an option for nixpkgs aiui I don't think complaining at them every time a new rustc version breaks their build will accomplish anything other than being obnoxious; this is expected behavior with nightly rust | 22:41:08 |
| eveeifyeve | I am working on fixing that currently. | 23:29:48 |
| eveeifyeve | No not every version, but if it breaks relibc to let us know. | 23:30:17 |
| eveeifyeve | * No not every version, but if it breaks relibc to let us know. Because it's important for the build support for redox. | 23:30:52 |
| eveeifyeve | Since it's required at a very early step. | 23:32:41 |
| eveeifyeve | * Since it's required at a very early step when building redox. | 23:32:58 |
| eveeifyeve | * Since it's required at a very early step when building redox packages. | 23:33:06 |
| Charles | i think you misread what i wrote | 23:33:07 |
| eveeifyeve | https://gitlab.redox-os.org/eveeifyeve/relibc/-/commits/fix-relibc-for-1-94?ref_type=heads | 23:36:13 |
| eveeifyeve | * https://gitlab.redox-os.org/eveeifyeve/relibc/-/commits/fix-relibc-for-1-94 | 23:36:18 |
