| 5 Nov 2025 |
kloenk | what is the current state of rust in lix? I see/know there is lix-doc. but is that something that wants to get removed (saw the consumer saying some TODO that I did not fully understand).
end question would be is it acceptable to write other features in rust or should as much as possible still be C++? | 22:34:37 |
K900 | The problem with writing features in Rust is mostly that there's no bindings to the C++ bits | 22:37:47 |
K900 | And the C++ bits are increasingly relying on coroutines via kj which basically don't FFI | 22:38:23 |
K900 | So you could write things in Rust, but those things need to either expose a sync C API surface or communicate over some sort of currently-not-existent RPC mechanism | 22:39:34 |
kloenk | raito nerdsniped me to write a new log format (like the multiline I did years ago). Kinda don't have the time for that, but wonderd if I can just forward all the data to rust and do the actuall handling of all the printing in rust | 22:42:47 |
K900 | Will have to build some sort of RPC layer for this | 22:44:29 |
K900 | Probably | 22:44:40 |
kloenk | From what I remember I think I could do most stuff with just a sync C abi. but also might have changed. but sounds like in general I can look into it (should I find the time for it :)) | 22:45:39 |
| 6 Nov 2025 |
raitobezarius | blocked on ability for rustc to tell us what we need to do wrt linkage to meson | 01:02:06 |
raitobezarius | mostly libstd relinking issues, etc. | 01:02:27 |
raitobezarius | the same set of problems that systemd is running into afaik | 01:02:40 |
raitobezarius | if we go any RPC way, that's akin to do nom | 01:03:22 |
| 7 Nov 2025 |
Qyriad | we think the strat re: Rust may be to just have rustc do the final link | 23:03:21 |
| 8 Nov 2025 |
| byteflavour joined the room. | 07:59:59 |
Rutile (Commentator2.0) feel free to ping | currently working on this cl: https://gerrit.lix.systems/c/lix/+/4533 (specifying remote builders using toml instead of what the actual stuff the current thingy is) but am getting the following cryptic error message, when specifying more than one element in a list:
error: bad machine specification: failed to convert column #3 in a row: 'systemTypes = ["Arch1", "Arch2"]' to 'unsigned int'"
using systemTypes = ["Arch1"] works, but as soon as i add a second value, it throws the error above.. anyone have any clue why and how to fix this? note: am trying to data.get<std::vector<std::string>>(...)
| 19:51:46 |
| 9 Nov 2025 |
| ghpzin (moved to @ghpzin:envs.net) changed their display name from ghpzin to ghpzin (moved to @ghpzin:envs.net). | 15:04:03 |
Sergei Zimmerman (xokdvium) | Is this a known regression? Wasn't too successful at minimizing, maybe somebody could give it a shot:
nix eval "https://api.flakehub.com/f/pinned/HariAmoor-professional/nixos-config/0.1.15%2Brev-9663eb776b745a0eb637320c165729bf6acaac70/018a8b2d-121a-7d71-8db4-666a0ec6c497/source.tar.gz#nixosConfigurations.nixos.config.system.build.toplevel" --no-allow-import-from-derivation --no-eval-cache
Fails on 3ad1af8 with:
error: makeWrapper/makeShellWrapper must be in nativeBuildInputs
note: trace involved the following derivations:
derivation 'home-manager-generation'
derivation 'home-manager-files'
derivation 'home-manager-path'
derivation 'bitwarden-x86_64-unknown-linux-gnu-2023.5.1'
derivation 'npm-install-hook'
derivation 'make-shell-wrapper-hook'
Works on 2.93. Sorry for the flakehub repro, don't have a lot of energy atm to keep minimizing this. I think a tell-tale sign is the fact that the derivation name is prefixed (x86_64-unknown-linux-gnu) as if nixpkgs is cross-compiled to gnu64, but it's not. raitobezarius this must have to do with the thunk equality changes?
| 15:41:12 |
raitobezarius | if cross is involved, that seems likely | 15:43:22 |
raitobezarius | thanks for the report | 15:43:24 |
Sergei Zimmerman (xokdvium) | The issue is that it has no cross is sight | 15:43:37 |
Sergei Zimmerman (xokdvium) | * The issue is that it has no cross in sight | 15:45:32 |
Sergei Zimmerman (xokdvium) | Plain old native config of nixpkgs. | 15:45:47 |
raitobezarius | Ugh, OK, thanks | 15:48:21 |
raitobezarius | We will start bisecting on Monday if pennae doesn't beat me to it | 15:48:31 |
Sergei Zimmerman (xokdvium) | I get the same error as the above for nix eval "github:nixos/nixpkgs?rev=a999c1cc0c9eb2095729d5aa03e0d8f7ed256780#pkgsCross.gnu64.bitwarden" --no-eval-cache. So that's why I suspect that nixpkgs machinery is misled into thinking it's cross while it's not | 15:51:28 |
Sergei Zimmerman (xokdvium) | And that's both for cppnix/lix | 15:52:13 |
aloisw | 2.93:
nix-repl> nixosConfigurations.nixos.config.nixpkgs.hostPlatform == nixosConfigurations.nixos.config.nixpkgs.buildPlatform
true
main:
nix-repl> nixosConfigurations.nixos.config.nixpkgs.hostPlatform == nixosConfigurations.nixos.config.nixpkgs.buildPlatform
false
So it indeed thinks there's cross now where there wasn't before. | 16:19:34 |
aloisw | Slightly reduced reproducer:
let
inherit (import <nixpkgs> { }) lib;
in
(lib.evalModules {
modules = [
(
{ config, ... }:
{
options = {
buildPlatform = lib.mkOption {
type = lib.types.either lib.types.str lib.types.attrs;
apply = lib.systems.elaborate;
default = config.hostPlatform;
};
hostPlatform = lib.mkOption {
type = lib.types.either lib.types.str lib.types.attrs;
apply = lib.systems.elaborate;
default = "x86_64-linux";
};
isCross = lib.mkOption { type = lib.types.bool; };
};
config = {
isCross = config.buildPlatform == config.hostPlatform;
};
}
)
];
}).config.isCross
| 16:34:50 |
aloisw | Fully reduced reproducer:
with rec {
a = {
f = x: x;
meow = true;
};
b = a // {
meow = true;
};
};
a == b
| 16:39:41 |
raitobezarius | oh wow | 16:46:16 |