26 Apr 2025 |
KFears (burning out) | So I disagree | 22:03:04 |
jade_ | right, but if you bite off more than you can reasonably chew and the CLs are too big, it's hard to get them over the finish line | 22:03:30 |
KFears (burning out) | It's perfectly realistic, even with the whole n-e-j part that is grinding my gears, and git flows being very annoying | 22:03:32 |
KFears (burning out) | If that ever becomes a problem, I'll just cut the CL in parts, no problem | 22:04:10 |
KFears (burning out) | But alright, if you want manual-only - I'll give you manual-only | 22:04:43 |
KFears (burning out) | I'm just very much not satisfied with doing 10% of the work and saying I've done something | 22:05:18 |
jade_ | i.e. if you have to go for a 1000 line CL that has to add a bunch of conditionals all over releng you will probably find out about every mistake at once and it will wind up a recipe for unmerged sadness. expanding from the easiest one outward is the simplest path to make incremental progress. | 22:05:22 |
KFears (burning out) | It won't be 1000 line CL because I'd just slap conditionals instead of actually refactoring the code to have the abstractions in place to accommodate for different environments with different usages | 22:06:37 |
KFears (burning out) | I don't do 1000 line CLs | 22:07:08 |
jade_ | right but what i am saying is that the different environment code should not have to exist at all; not as conditionals, not as abstractions. we should start with the subset that doesn't require any of that stuff. | 22:07:30 |
KFears (burning out) | So uhhh, bad news there... There's none | 22:08:12 |
jade_ | i don't think that nix-eval-jobs should be broken for you, and if it is, we need to revise the test structure | 22:08:17 |
jade_ | i.e. the vm is being created the wrong way | 22:08:39 |
KFears (burning out) | I had to put in some hacks to merely get local to do the very first step, because it eagerly expects the origin to be Gerrit, and either I put a hack into the VM to set origin to Gerrit, or I actually fix the code that is responsible for it | 22:09:39 |
KFears (burning out) | Like, there's nothing to test if there's no changes to code, the current code approach just doesn't work for testing | 22:11:08 |
KFears (burning out) | I guess it'll be much easier to demonstrate on an actual CL review | 22:12:30 |
KFears (burning out) | And if just building manual is fine, I'll just do that | 22:13:56 |
Ramses 🇵🇸 | Anyone else facing Apr 26 22:36:48 bld1 nix-daemon[3146565]: unexpected Nix daemon error: error: serialised integer 7022364302122705765 is too large for type 'j' with lix built from main? | 22:38:31 |
Ramses 🇵🇸 | This is what I get on the remote side, which is running cppnix 2.28 (I can't easily deploy lix there) | 22:39:10 |
Ramses 🇵🇸 | Sorry, I'm tired, I should have been more clear. Remote builds are broken with my setup, and that error is what I get on the remote side | 22:40:07 |
Ramses 🇵🇸 | K900: reverting your patch fixes the issue, but it's not immediately clear to me from the diff what might be causing this | 23:16:27 |
griff | Ramses 🇵🇸: 7022364302122705765 is the unsigned 64 bit little-endian representation of echo sta . So my guess is that the remote command is overridden so that bash isn't started like the patch expects and instead it tries to read echo started command as the magic int that starts the protocol. | 23:34:01 |
27 Apr 2025 |
raitobezarius | In reply to @rvdp:infosec.exchange Anyone else facing Apr 26 22:36:48 bld1 nix-daemon[3146565]: unexpected Nix daemon error: error: serialised integer 7022364302122705765 is too large for type 'j' with lix built from main? Will take a look | 07:07:16 |
Ramses 🇵🇸 | I have a forced command set for the ssh key on the remote builder, which used to be set to "nix-daemon --stdio", and since the latest changes to lix I changed it to "echo started; nix-daemon --stdio" | 08:02:26 |
Ramses 🇵🇸 | I guess that this isn't compatible with the new changes to the remote build stuff | 08:03:20 |
K900 | Yeah we now rely on being able to run bash | 08:04:01 |
K900 | And then pipe commands into it | 08:04:07 |
Ramses 🇵🇸 | Hmm, that's annoying. I have this separate key with a forced command since the key that I use for interactive login sits on a fido device, but having to touch the fido device for every remote build connection is quite annoying | 08:08:05 |
Ramses 🇵🇸 | Maybe I could move to a persistent control master instead and just use the fido key | 08:09:29 |
K900 | Connection pooling should actually work now | 08:12:46 |