| 26 Dec 2024 |
|  elikoga changed their display name from elikoga (@38c3 📞448{0,1} to elikoga (@38c3 📞448{0,1}). | 15:26:06 |
| elikoga changed their display name from elikoga (@38c3 📞448{0,1}) to elikoga (@38c3 📞488{0,1}). | 15:26:48 |
| 27 Dec 2024 |
 rhelmot | I opened https://github.com/rust-lang/rust/issues/134811 against rustc while trying to debug https://github.com/NixOS/nixpkgs/pull/356769 if anyone here wants to save the rust people some pain | 00:53:53 |
|  raitobezarius changed their display name from raitobezarius to raitobezarius (DECT: 3538 / EPVPN 2681). | 07:32:31 |
|  Dimitar set a profile picture. | 11:41:03 |
| Dimitar changed their display name from dimitarnestorov to Dimitar. | 11:42:12 |
|  A2 changed their display name from A2 to A2 (☎️ 61777). | 15:25:27 |
| 29 Dec 2024 |
| elikoga changed their display name from elikoga (@38c3 📞488{0,1}) to elikoga (@38c3 📞488{0,1,9}). | 11:03:18 |
|  DavHau joined the room. | 14:29:44 |
| DavHau | I think I discovered a fundamental issue with rust cross compilation in nixpkgs and I could use some help finding a solution.
I was wondering why python bcrypt would build binaries for the build platform instead if the host platform and found out that cargoSetupHook (and all other rust hooks as well) behave differently when used inside mkDerivation vs in buildRustPackage.
This issue affects many packages in nixpkgs, and I would like to fix the root cause instead of working around it.
The reason is that buildRustPackage consumes the non-spliced hooks via this inherit statement, and therefore them being put inside nativeBuildInputs there doesn't have the usual effect as it has in all other package builder functions.
Most rust hooks have been designed with the wrong build/host/target triples in mind, and once used inside mkDerivaiton or buildPythonPackage this results in stuff being built for the wrong platform.
I was about to add proper splicing to those hooks and refactor most of them, but I'm questioning this approach now.
Why even have splicing for hooks, as they should only ever be used inside nativeBuildInputs and nowhere else.
Would it make more sense to disable splicing for these hooks somehow in all places, instead of refactoring them?
If yes, how would I best implement disabling the splicing? There doesn't seem to be such feature.
| 14:53:33 |
| DavHau | * I think I discovered a fundamental issue with rust cross compilation in nixpkgs and I could use some help finding a solution.
I was wondering why python bcrypt would build binaries for the build platform instead of the host platform and found out that cargoSetupHook (and all other rust hooks as well) behave differently when used inside mkDerivation vs in buildRustPackage.
This issue affects many packages in nixpkgs, and I would like to fix the root cause instead of working around it.
The reason is that buildRustPackage consumes the non-spliced hooks via this inherit statement, and therefore them being put inside nativeBuildInputs there doesn't have the usual effect as it has in all other package builder functions.
Most rust hooks have been designed with the wrong build/host/target triples in mind, and once used inside mkDerivaiton or buildPythonPackage this results in stuff being built for the wrong platform.
I was about to add proper splicing to those hooks and refactor most of them, but I'm questioning this approach now.
Why even have splicing for hooks, as they should only ever be used inside nativeBuildInputs and nowhere else.
Would it make more sense to disable splicing for these hooks somehow in all places, instead of refactoring them?
If yes, how would I best implement disabling the splicing? There doesn't seem to be such feature.
| 14:53:53 |
 emily | "Why even have splicing for hooks, as they should only ever be used inside nativeBuildInputs and nowhere else." seems wrong | 14:54:56 |
| emily | you might need to build a Rust program for the build platform in a derivation | 14:55:09 |
| emily | in which case it should go in depsBuildBuild | 14:55:15 |
| emily | (indeed this is normal to do via build.rs etc., but you can imagine e.g. Linux building a Rust tool among its other build-platform tools as a non-top-level-Cargo-driven example) | 14:55:54 |
| DavHau | OK thanks, then I guess I start refactoring | 15:11:16 |
| emily | if you can fix the setEnv nonsense that binds a tool chain way too early that would be great :p | 15:28:18 |
| DavHau | Maybe setEnv turns out to be one of many workarounds that have been implemented just because the splicing was not applied correctly in all places. | 15:37:46 |
| emily | thanks for taking this on 💜 | 15:38:18 |
 Colin | with cross-compiled glib being broken on master (it's downstream of unbound) , how should i go about upstreaming cross fixes for packages which use glib?
| 16:46:25 |
| Colin | if i PR them against master, then the reviewer can't just pull my PR branch & build it as they normally might | 16:46:57 |
| Colin | unbound/glib is fixed in staging though | 16:47:51 |
| Colin | so should i be PR'ing everything against staging, even if they're ordinary packages, just because that's the base branch for which all the prerequisites are building? | 16:48:42 |
 K900 | Staging will probably be easier to keep track of | 17:12:15 |
| 30 Dec 2024 |
| DavHau | Why is there a riscv64-unknown-linux-gnu-rustc in my dependency tree when cross compiling for riscv64? I thought rustc is platform agnostic and accepts a --target parameter. So why doe it need to be built for each cross platform? | 03:54:54 |
| DavHau | * Why is there a riscv64-unknown-linux-gnu-rustc in my dependency tree when cross compiling for riscv64? I thought rustc is platform agnostic and accepts a --target parameter. So why do I need to be build it for each cross platform? | 03:55:20 |
| K900 | Because you also need libstd | 05:38:40 |
| K900 | Which we don't build for every target under the sun because that would make rustc massive | 05:38:56 |
| DavHau | I fixed the splicing for the rust hooks and refactored them + added tests. Review/Merge appreciated: https://github.com/NixOS/nixpkgs/pull/369424 | 15:26:16 |
| DavHau | This should improve cross compilation issues with various rust packages which are not based on buildRustPackage | 15:27:23 |
