| 26 Jul 2025 |
Qyriad | it probably should | 12:35:28 |
Qyriad | that logic was translated directly from the old buildsystem | 12:35:40 |
Qyriad | and at the time most of those targets didn't work anyway for Nixpkgs broken package reasons | 12:36:19 |
Sergei Zimmerman (xokdvium) | Yeah, though is there any reason not to use hostPlatform.system when building nix with nix? | 12:38:34 |
Sergei Zimmerman (xokdvium) | * Yeah, though is there any reason not to use hostPlatform.system when building nix/lix in nixpkgs? | 12:38:56 |
Qyriad | Probably not? Have you tried it? Does anything break? | 12:39:19 |
Sergei Zimmerman (xokdvium) | It should just work. I'll try to get the manual logic in meson to align with what https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/lib/meson.nix does (for the sake of other distros building nix). But for consistency lib.systems should just be the source of truth IMO. | 12:41:20 |
emily | In reply to @xokdvium:matrix.org The default system double in currentSystem is very f'ed up on 32 bit arm, mips, powerpc e.t.c. It's really a viscous cycle where nixpkgs determines the values in host_platform and the build system doesn't really use those correctly. E.g. armv7l, armv6l translates to host_platform.cpu_family() = 'arm' in nixpkgs (as it rightly should). By the system double should differentiate between those, so it should look at cpu_name as well. 32-bit ARM can't even build Nix | 12:46:56 |
emily | so I wouldn't worry overly much | 12:47:08 |
Sergei Zimmerman (xokdvium) | Well you can build it cross (and hydra does build it). | 12:47:28 |
emily | did someone fix it? it was broken very recently | 12:47:54 |
emily | maybe only for v6/v5 | 12:48:02 |
Sergei Zimmerman (xokdvium) | Not sure, nix hydra jobset has been building it for quite some time now. | 12:49:42 |
emily | looks like it's in fact only ARMv5, whoops | 12:52:43 |
emily | 32 bit support in Nixpkgs is usually half broken in general | 12:53:17 |
Sergei Zimmerman (xokdvium) | Yup, but the PowerPC bringup work shows that it still should be fixed. | 12:54:36 |
emily | sure :) | 12:58:30 |
emily | my impression was that Nix matched the Nixpkgs platform support policy | 12:59:02 |
emily | not sure if Lix has any declared tiers | 12:59:11 |
Qyriad | Most of the time that a Lix build for a platform has broken it has been because of a downstream Nixpkgs breakage | 13:00:28 |
Qyriad | though I think sometimes that might've been through dependencies CppNix didn't have | 13:01:24 |
aloisw | There have also been a couple of instances where 32-bit specific bugs have been introduced in Lix. | 13:02:24 |
emily | building is one thing, running is another :) | 13:03:35 |
emily | (though at least most 32 bit bugs can be caught statically with sufficiently aggressive checking) | 13:03:56 |
aloisw | The instances I'm thinking of were actually all build failures. I do not know whether it actually runs. | 13:04:44 |
aloisw | I could try running a 32-bit Lix on my system, but probably it will OOM regularly. | 13:05:17 |
emily | In reply to @xokdvium:matrix.org Well you can build it cross (and hydra does build it). (the thing about building Nix cross is that it means you're building the system cross so you probably have no need for Nix on the system) | 13:05:45 |
emily | (but I'm all for deconfusing platform stuff) | 13:05:52 |
emily | In reply to @aloisw:julia0815.de
I could try running a 32-bit Lix on my system, but probably it will OOM regularly. running on an AArch64 box that has 32 bit mode is probably viable | 13:06:29 |
emily | like, "might even bootstrap a basic NixOS system if you're lucky and send some patches" viable | 13:06:48 |