| 13 Jul 2025 |
Andrew | Oh, I guess it's only for native tests... | 07:24:31 |
Andrew | I guess I should try creating a separate image without it. should be a hell of a lot smaller. | 07:26:43 |
| Hatim joined the room. | 09:31:37 |
| @audiotrope:matrix.org left the room. | 15:13:33 |
| timschumi joined the room. | 18:28:49 |
| Marie changed their profile picture. | 20:11:54 |
emily | we have this in cargo.nix:
//
lib.optionalAttrs (stdenv.buildPlatform.rust.rustcTarget != stdenv.hostPlatform.rust.rustcTarget)
{
HOST_PKG_CONFIG_PATH = "${pkgsBuildBuild.pkg-config}/bin/pkg-config";
}
| 21:24:00 |
emily | it seems highly questionable | 21:24:03 |
emily | that's PKG_CONFIG_PATH for HOST, not the path to the executable | 21:24:10 |
emily | but 0ac955ad63e2f94c64de584551493ceb33b00b45 claims it fixed something somehow | 21:24:31 |
| 14 Jul 2025 |
Gaétan Lepage | Looks like rustfmt is broken on x86_64-darwin on nixos-25.05:
https://buildbot.nix-community.org/#/builders/2847/builds/5266/steps/1/logs/stdio (from Nixvim CI) | 00:45:35 |
Alyssa Ross | Hydra shows broken between 36d055248bd7758309ead91562b2cc44b08a257f and bff650412cc35886110bed88287f6fa6ccb65cf6 | 10:18:36 |
rosssmyth | It uses the MSVC libraries, and it uses lld as the linker. Link.exe sucks even on native Windows anyways. | 14:50:16 |
rosssmyth | Looks like it probably is | 14:56:18 |
rosssmyth | Ok, I updated it to use xwin. It is less janky, and faster to download. I'll have to more experimentation later.
https://github.com/RossSmyth/nur/blob/main/msvc-rust/default.nix | 17:56:36 |
| 15 Jul 2025 |
Toma | With staging-next done, we can do https://github.com/NixOS/nixpkgs/pull/421558 now
This is just the removal of the usages, not the removal of the logic.
For the logic, should we make setting useFetchCargoVendor a warning/error in 25.11? We could just remove the logic completely, but then people might not remove it from their out-of-tree derivations...
| 13:21:46 |
Toma | * With staging-next done, we can do https://github.com/NixOS/nixpkgs/pull/421558 now
This is just the removal of the usages, not the removal of the logic.
For the logic, should we make setting useFetchCargoVendor a warning/error in 25.11? We could just remove the logic completely, but then people might not remove it from their out-of-tree derivations... Or, since we didn't have too long of a period where useFetchCargoVendor was forced to be set to true manually, we should just remove it without warnings.
| 13:24:08 |
emily | I'm ambivalent about warning vs. error, but I think we should have some notice rather than just an unknown argument error | 13:29:19 |
emily | warning and then hard removal in 26.05 seems okay | 13:29:36 |
emily | * warning in 25.11 and then hard removal in 26.05 seems okay | 13:29:39 |
Toma | There are now unknown arguments... its just mkDerivation, anything goes | 13:29:48 |
Toma | * There are no unknown arguments... its just mkDerivation, anything goes | 13:30:06 |
emily | ouch… | 13:30:08 |
emily | good point | 13:30:16 |
emily | maybe a throw and then removal then | 13:30:36 |
Toma | Also, should we wait for https://github.com/NixOS/nixpkgs/pull/423228 to reach stable so that we can do a double treewide to completely avoid merge conflicts? | 13:31:34 |
Toma | * Also, should we wait for https://github.com/NixOS/nixpkgs/pull/423228 to reach stable so that we can do a double treewide to completely avoid backport merge conflicts? | 13:32:04 |
emily | probably let's wait | 13:32:40 |
Toma | alright | 13:33:05 |
emily | probably not a big deal | 13:33:25 |