| 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 |
raitobezarius | thx | 16:46:17 |
raitobezarius | a fix may rain in the next hours | 16:47:18 |
raitobezarius | i want to go and say that zomg the fact that we broke eval based on this behavior :') | 16:51:32 |
Lunaphied | Dear gods that's horrifying | 16:58:33 |
Winter | i fucking hate it | 16:58:49 |
Sergei Zimmerman (xokdvium) | What's even more cursed is this:
nix::EvalState::eqValues (this=0x555555e8b770, v1=..., v2=..., pos=..., errorCtx="while testing two values for equality") at lix/libexpr/eval.cc:2613
2613 forceValue(v2, pos);
(gdb)
2616 if (v1.type() == nInt && v2.type() == nFloat) {
(gdb)
2619 if (v1.type() == nFloat && v2.type() == nInt) {
(gdb)
2624 if (v1.type() != v2.type()) return false;
(gdb)
2629 auto pointerEq = [&] { return v1.pointerEqProxy() == v2.pointerEqProxy(); };
(gdb)
2631 switch (v1.type()) {
(gdb)
2658 if (pointerEq()) return true;
(gdb)
2661 if (isDerivation(v1) && isDerivation(v2)) {
(gdb)
2669 if (v1.attrs()->size() != v2.attrs()->size()) return false;
(gdb) p v1.attrs()->size()
$1 = 2
(gdb) p v2.attrs()->size()
$2 = 3
It's not equal because the attrset size is incorrect? How???
| 17:21:56 |
aloisw | I'd guess because it forgot to shrink after noticing that the update replaced one entry? | 17:24:59 |
Sergei Zimmerman (xokdvium) | Updates never replace anything - they copy to a new attribute set though. It's puzzling | 17:25:38 |
aloisw | In reply to @raitobezarius:matrix.org i want to go and say that zomg the fact that we broke eval based on this behavior :') Honestly I didn't even know before tracing this down that true is the expected value in this place. | 17:25:58 |
Sergei Zimmerman (xokdvium) | Ah I see, that might be my SNAFU hmmm | 17:26:33 |
aloisw | In reply to @xokdvium:matrix.org Updates never replace anything - they copy to a new attribute set though. It's puzzling "Replace" not in the sense that it's an in-place update, but that the keys overlap. I think it allocates sum of the sizes many entries and then is supposed to shrink if not all were needed due to overlap. | 17:28:12 |
Sergei Zimmerman (xokdvium) | Capacity never actually gets shrunk and size is only incremented when doing a push_back to the bindings. Something looks broken in the ExprOpUpdate::eval code. | 17:35:41 |