!FBuJyWXTGcGtHTPphC:nixos.org

Nix Rust

638 Members
Rust146 Servers

Load older messages

SenderMessageTime
11 Nov 2025
@n8henrie:matrix.orgn8henrieHopefully not, I renovated the build system prior to the 2.3 release using a pretty standard ubuntu build process. Building now.22:10:00
@n8henrie:matrix.orgn8henrieThat could totally be it.22:10:12
@n8henrie:matrix.orgn8henrie

I bet you're right. Yup the deb version is working fine.

But now I'm not sure how to get a matching wxGTK32 version on Arch, but I can look into that.

It certainly would be much easier to just bisect by setting src = /path/to/espanso-src, but then cargoHash fails. I set it to look at Cargo.lock instead, but then there's a (or maybe more than one) git dependency that trips things up.

Are you aware of any way that I can override src in the package definition without the cargoHash stuff being wrong on every iteration of a bisect?

22:14:27
@n8henrie:matrix.orgn8henrieLooks like wxgtk 3.2.8.1 on nix, 3.2.8.1-2 on arch.22:15:52
@n8henrie:matrix.orgn8henrieOh, maybe I can just build on a nix shell on arch and get the matching wxgtk...22:16:28
@ghpzin:envs.netghpzin Iirc there is a way to not fill output git hashes importing Cargo.lock with allowBuiltinFetchGit = true; 22:19:29
@ghpzin:envs.netghpzin Iirc a way to not fill output git hashes while importing Cargo.lock is setting allowBuiltinFetchGit = true; 22:19:55
@n8henrie:matrix.orgn8henrieBuilding in a nix shell with the matching version of wxGTK worked! Thanks a ton! I'll experiment with the built-in fetchgit as well, thank you for the suggestion.22:24:34
@n8henrie:matrix.orgn8henrie Just to close the loop, allowBuiltinFetchGit works a treat and is probably an even better approach. Thank you! 22:33:31
@n8henrie:matrix.orgn8henrie This way I can make sure the package builds or exit 125 for the bisect. If the package builds, run the nixosTest and get a result. Fingers crossed. 22:34:37
12 Nov 2025
@inayet:matrix.orgInayet changed their display name from inayet to Inayet.12:37:29
@crop_tech:matrix.orgcrop i am trying to use this crate in a project that i work on on a nixos machine: https://github.com/HadrienG2/hwlocality
it depends on a c library that i add to the shell.nix in the buildInputs = with pkgs; [hwloc] and then set the libpath with libPath = with pkgs; lib.makeLibraryPath buildInputs; ... the library is loaded dynamically as the error appears only when i try to use the crate in rust.
the error is target/release/multi_thread: error while loading shared libraries: libhwloc.so.15: cannot open shared object file: No such file or directory
any suggestions how to fix this? 		22:59:37
@crop_tech:matrix.orgcrop i now added the following line to the shell.nix
LD_LIBRARY_PATH = "${pkgs.lib.makeLibraryPath buildInputs}";
but i thought this is not recommended. 		23:25:43
@crop_tech:matrix.orgcrop its not "recommended" because now i am missing other libraries (pipewire-...-jack-lib) ... and i don't know how it got put into the LDLIBRARYPATH variable automatically 23:33:14
@crop_tech:matrix.orgcropok i found the solution for the jack problem but it actually doesn't help for hwloc to be found .... which is strange because one time i run the build (but i don't know what i changed it worked)23:46:20
@crop_tech:matrix.orgcrop ok it seems to work if i use the "vendored" hwloc build by cargo ... not ideal (and only without the LDLIBRARYPATH thing which seems to be what i shouldn't do anyway) 23:50:39
15 Nov 2025
@louis2747:matrix.orgLouis2747 joined the room.11:31:57
@k900:0upti.meK900I'm dumb, how do I patch a fetchCargoVendor14:03:33
@ghpzin:envs.netghpzin I saw somebody do rustPlatform.fetchCargoVendor similar to what it does by default, then change it with runCommand and set cargoDeps attr to result.
Not sure whether it is the most "accepted" way to do it. 		14:09:53
@k900:0upti.meK900OK that's too much effort14:10:57
@ghpzin:envs.netghpzin I saw somebody do rustPlatform.fetchCargoVendor similar to what it does by default, then change it with runCommand and set cargoDeps attr to result.
Not sure whether it is the most "accepted" way to do it.
https://github.com/NixOS/nixpkgs/blob/321f80c3e2a7ebefde46ef112e88e73774bc9fc7/pkgs/by-name/fl/flare-signal/package.nix#L49-L69 		14:11:00
@niklaskorz:matrix.orgniklaskorz there's depsExtraArgs 14:24:47
@niklaskorz:matrix.orgniklaskorzhttps://github.com/NixOS/nixpkgs/blob/c5ae371f1a6a7fd27823bc500d9390b38c05fa55/pkgs/by-name/ze/zed-editor/package.nix#L131-L13514:24:54
@niklaskorz:matrix.orgniklaskorzbut it's undocumented14:25:26
@niklaskorz:matrix.orgniklaskorzbut that doesn't do anything else than passing extraArgs to buildRustPackage's implicit fetchCargoVendor call, so probably not what you are looking for if you already use fetchCargoVendor directly14:26:57
@niklaskorz:matrix.orgniklaskorz* but that doesn't do anything else than passing extra args to buildRustPackage's implicit fetchCargoVendor call, so probably not what you are looking for if you already use fetchCargoVendor directly14:27:06
@niklaskorz:matrix.orgniklaskorz if you need to patch a dependency's own code then the common solution is to do that in your package's postPatch on $cargoDepsCopy 14:28:20
@k900:0upti.meK900Bleh14:28:54
@ghpzin:envs.netghpzin fetchCargoVendor is just runCommand at the very end, so you can probably do the same on top of it.
Or applyPatches on top. 		14:33:25
@ghpzin:envs.netghpzin fetchCargoVendor is just runCommand at the very end, so you can probably do the same inside.
Or applyPatches on top. 		14:33:40

Show newer messages

Back to Room ListRoom Version: 6