| 26 Jul 2025 |
raitobezarius (DECT: 7248) | and grepping the code doesn't help | 01:45:20 |
emily | I just do not want --option ssl-cert-file to be a trivial "read any root:root file" vector :) | 01:45:58 |
raitobezarius (DECT: 7248) | either way, I guess there's ONE solution out there, it has a bunch of issues, but I think those are fairly workable | 01:46:01 |
raitobezarius (DECT: 7248) | In reply to @emilazy:matrix.org I just do not want --option ssl-cert-file to be a trivial "read any root:root file" vector :) u sure u dont want another CVE? | 01:46:11 |
raitobezarius (DECT: 7248) | please drop a comment on the CL | 01:46:18 |
emily | I should have slept an hour ago, can I do it tomorrow? :p | 01:46:59 |
raitobezarius (DECT: 7248) | i should have slept 4 hours ago, what's your point | 01:47:12 |
raitobezarius (DECT: 7248) | do it whenever it's convenient for you | 01:47:25 |
Sergei Zimmerman (xokdvium) | Qyriad: | 12:02:58 |
Sergei Zimmerman (xokdvium) | * Qyriad: What's up with the meson host_platform and cpu names? It's all very wonky and slightly broken I think (in both lix and cppnix). | 12:03:31 |
Sergei Zimmerman (xokdvium) | 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. | 12:07:40 |
Sergei Zimmerman (xokdvium) | * 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). But the system double should differentiate between those, so it should look at cpu_name as well. | 12:08:59 |
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 |