| 8 Oct 2025 |
 K900 | I'd rather not | 10:50:43 |
| K900 | I kinda really don't like that change tbh | 10:51:24 |
| K900 | Like why are we even grabbing random manifests like that | 10:51:37 |
| K900 | Can we not either specify that or resolve the top of workspace correctly | 10:51:47 |
 niklaskorz | Happy to discuss alternatives, and I don't know about the original motivation for the glob, maybe @tomasajt:matrix.org can chime in on that | 11:01:19 |
| niklaskorz | So far zed-editor seems to be the first and only package to be affected, so really not that important | 11:14:38 |
| niklaskorz | I'll just have to deal with a couple of weeks of inquiries from unhappy Zed users, but that's ok 😄 | 11:15:07 |
| niklaskorz | replacing it with a topdown Path.walk + checking for existence of Cargo.toml now (so it automatically checks the topmost Cargo.toml first) | 13:17:44 |
| niklaskorz | Or well, I would, but I might have to deal with some kind of hardware failure right now | 13:35:09 |
| niklaskorz | oh wow, after some digging I suspect the source of the issue has never been the ordering (although strictly speaking, Path.glob does indeed not guarantee any order)... | 13:49:00 |
| niklaskorz | the failing dependency in question, candle-book, is explicitly excluded by its workspace manifest but still specifies the edition to be inherited from the workspace (which is the source of the cargo metadata failure) | 13:49:40 |
| niklaskorz | might not need a staging PR or fix in fetchCargoVendor after all then, checking if we can do with some patching here | 13:50:22 |
| niklaskorz | doesn't look like it, as we currently have no way to sneak in patches between fetchcargovendor staging and final output | 14:14:22 |
| niklaskorz | so either way the try block is the only real immediate solution (short of the upstream crate fixing its mess) | 14:14:40 |
|  Anders joined the room. | 16:36:56 |
| Anders | Are anyone interested in integrating RedoxOS with NixOS? I see there has been some efforts to do this before, but it seems to be dormant now. But the Redox OS project seems very promising as a inovative, modern and secure system which would harmonize with nix too.
https://gitlab.redox-os.org/redox-os/redox/-/issues/1552 | 16:54:36 |
| Anders | * Is anyone interested in integrating RedoxOS with NixOS? I see there has been some efforts to do this before, but it seems to be dormant now. But the Redox OS project seems very promising as a inovative, modern and secure system which would harmonize with nix too.
https://gitlab.redox-os.org/redox-os/redox/-/issues/1552 | 16:54:46 |
| Anders | https://github.com/nix-community/redoxpkgs | 16:55:35 |
| niklaskorz | Afaik the first step would be to bring back relibc | 16:55:47 |
| niklaskorz | @zmitchell:matrix.org looked into this but responded here why he stopped: https://bsky.app/profile/z-mitchell.bsky.social/post/3liahxpqjls2i | 16:56:37 |
|  Andrew Zah joined the room. | 17:13:58 |
| Anders | Too bad relibc was not maintained.
https://github.com/NixOS/nixpkgs/blob/1598da9c7d99ba7a769393c04c3c44e8acf55d92/pkgs/top-level/aliases.nix#L2318 | 17:28:51 |
| Anders | So the original build was a mess. Downlaoding tarballs from dropbox and more. But to be able to cross compile we need relibc to work. | 20:32:24 |
| niklaskorz | I might be on board with experimenting a bit as I'm personally interested in Redox | 21:03:39 |
| Anders | I tried to build relibc now, but it requires a lot of experimental rust features to build | 21:04:57 |
| Anders | I wonder if the easiest way is to build relibc inside a redox vm | 21:06:09 |
| niklaskorz | you mean -Z build-std=core,alloc,compiler_builtins? | 21:07:10 |
| niklaskorz | because we support those without nightly on nixpkgs now, technically | 21:07:57 |
| Anders | things like #[target_feature(enable = "tbm")] | 21:08:14 |
| niklaskorz | hm target_feature shouldn't require nightly though? | 21:10:22 |
