Nix Rust | 701 Members | |
| Rust | 155 Servers |
| Sender | Message | Time |
|---|---|---|
| 1 Jul 2025 | ||
| wait how do we find the file then | 15:50:03 | |
| does rustc have a TARGET_SPEC_DIR or something | 15:50:47 | |
| you know what, nevermind, i'm not actually blocked on r-h-f | 15:59:26 | |
i don't have the string with context problem if i use rust.framepointers | 15:59:48 | |
* i don't have the string with context problem if i use rust.frame-pointers | 16:02:24 | |
| I have opened https://github.com/NixOS/nixpkgs/pull/421558 I don't want to imagine the merge issues with having made a change in 2000 packages, all of them near often-changing hash values and having them be only in staging but not master. I think we should first have a staging cycle where the Any better ideas? | 17:31:48 | |
| I'd also imagine a similar process for release-25.05, but I guess the merge issues are less severe there | 17:32:46 | |
| oh god, it gets passed down still? | 17:32:48 | |
yes, let's do the staging thing then | 17:33:04 | |
| and certainly let's backport to 25.05 | 17:33:09 | |
and we'll also need to do a merge into staging-next and staging when we land | 17:33:31 | |
as in, make it a nop in staging | 17:33:51 | |
| sorry for not catching that originally | 17:34:00 | |
| btw, you may want to collapse newlines for the
case | 17:34:37 | |
| (not sure if we have any in tree or not though) | 17:34:40 | |
(and actually I guess nixfmt might collapse those already) | 17:34:47 | |
| yes | 17:34:52 | |
| * yes it does | 17:35:06 | |
| Okay, I'll work on the make-NOOP PR then | 17:35:53 | |
| https://github.com/NixOS/nixpkgs/pull/421563 | 17:41:39 | |
| this minimal change should be fine I think | 17:42:13 | |
| Oh it has an eval error, will fix it in a minute | 17:45:43 | |
| * Oh it has an eval error, will fix it in a minute Edit: Done! | 17:47:57 | |
| 20:31:06 | ||
| 20:35:21 | ||
| 2 Jul 2025 | ||
| 02:12:23 | ||
| 13:30:16 | ||
| 3 Jul 2025 | ||
| 20:37:07 | ||
| I would like to revive some conversation around https://github.com/NixOS/nixpkgs/pull/387337 Currently the implementation creates a new subdirectory for each unique Here's an example of how the final directory layout might look like:
| 22:41:21 | |
| I'm also wondering whether we want to support fetching from other registries in the future. This would require some ret-con on the layout of the FOD itself, but it shouldn't be too bad. | 22:42:38 | |