Nix Rust | 640 Members | |
| Rust | 147 Servers |
| Sender | Message | Time |
|---|---|---|
| 11 Nov 2025 | ||
To trigger the error? No, even a --version triggers it. | 21:37:40 | |
| Can't reproduce, seems to work on both my machine and nixosTest. Unless you use headless test for some reason. | 21:41:10 | |
| No, not headless. You are building espanso from source on a non-nixos system with standard Rust tooling, copying the binary while patching with autoPatchelfHook, and then running it in nix, and it's working? | 21:42:48 | |
| No, downloading .deb from releases page, doing all that and it runs. Let me clean up things and push. | 21:52:28 | |
| Oh interesting. My ultimate goal is a git bisect on the source to fix an upstream bug that was introduced sometime in the last year and a half (ugh), so I'll need to be able to build from source, but that's a reasonable way to test. I'll give that a shot. | 21:54:02 | |
| 21:55:41 | |
I do not think binary in their release .deb should be that different from build result from other distro. | 21:57:20 | |
| Actually if binary built on other distro is the one with problems, maybe it is just a mismatch of wxGTK32 versions. | 22:09:52 | |
| Hopefully not, I renovated the build system prior to the 2.3 release using a pretty standard ubuntu build process. Building now. | 22:10:00 | |
| That could totally be it. | 22:10:12 | |
| 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 Are you aware of any way that I can override | 22:14:27 | |
| Looks like wxgtk 3.2.8.1 on nix, 3.2.8.1-2 on arch. | 22:15:52 | |
| Oh, maybe I can just build on a nix shell on arch and get the matching wxgtk... | 22:16:28 | |
Iirc there is a way to not fill output git hashes importing Cargo.lock with allowBuiltinFetchGit = true; | 22:19:29 | |
Iirc a way to not fill output git hashes while importing Cargo.lock is setting allowBuiltinFetchGit = true; | 22:19:55 | |
| Building 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 | |
Just to close the loop, allowBuiltinFetchGit works a treat and is probably an even better approach. Thank you! | 22:33:31 | |
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 | ||
| 12:37:29 | ||
| 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 directoryany suggestions how to fix this? | 22:59:37 | |
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 | |
| 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 | |
| ok 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 | |
| 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 | ||
| 11:31:57 | ||
| I'm dumb, how do I patch a fetchCargoVendor | 14:03:33 | |
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 | |
| OK that's too much effort | 14:10:57 | |
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 | |
there's depsExtraArgs | 14:24:47 | |