| 2 Aug 2025 |
 raitobezarius | In reply to @charles:computer.surgery
yes:
[root@blue:~]# docker run -it lix:2.94.0-devpre20250801_4efc888 nix --extra-experimental-features 'nix-command flakes' run nixpkgs#hello
warning: error: unable to download 'https://api.github.com/repos/NixOS/nixpkgs/commits/nixpkgs-unstable': Resolving timed out after 5000 milliseconds (curl error code=28); retrying in 302 ms (attempt 1/5)
warning: error: unable to download 'https://github.com/NixOS/nixpkgs/archive/c02d05bcf73fb496c604798c2268ed424a09e73e.tar.gz': Resolving timed out after 5001 milliseconds (curl error code=28); retrying in 250 ms (attempt 1/5)
warning: error: unable to download 'https://github.com/NixOS/nixpkgs/archive/c02d05bcf73fb496c604798c2268ed424a09e73e.tar.gz': Resolving timed out after 5001 milliseconds (curl error code=28); retrying in 646 ms (attempt 2/5)
error:
… while fetching the input 'github:NixOS/nixpkgs/nixpkgs-unstable'
error: uri https://github.com/NixOS/nixpkgs/archive/c02d05bcf73fb496c604798c2268ed424a09e73e.tar.gz changed final destination from https://github.com/NixOS/nixpkgs/archive/c02d05bcf73fb496c604798c2268ed424a09e73e.tar.gz to https://codeload.github.com/NixOS/nixpkgs/tar.gz/c02d05bcf73fb496c604798c2268ed424a09e73e during transfer
[root@blue:~]# docker run -it lix:2.94.0-devpre20250801_4efc888 nix --extra-experimental-features 'nix-command flakes' run nixpkgs#hello
warning: error: unable to download 'https://api.github.com/repos/NixOS/nixpkgs/commits/nixpkgs-unstable': Resolving timed out after 5002 milliseconds (curl error code=28); retrying in 322 ms (attempt 1/5)
warning: error: unable to download 'https://api.github.com/repos/NixOS/nixpkgs/commits/nixpkgs-unstable': Resolving timed out after 5000 milliseconds (curl error code=28); retrying in 572 ms (attempt 2/5)
warning: error: unable to download 'https://github.com/NixOS/nixpkgs/archive/c02d05bcf73fb496c604798c2268ed424a09e73e.tar.gz': Resolving timed out after 5003 milliseconds (curl error code=28); retrying in 272 ms (attempt 1/5)
error:
… while fetching the input 'github:NixOS/nixpkgs/nixpkgs-unstable'
error: uri https://github.com/NixOS/nixpkgs/archive/c02d05bcf73fb496c604798c2268ed424a09e73e.tar.gz changed final destination from https://github.com/NixOS/nixpkgs/archive/c02d05bcf73fb496c604798c2268ed424a09e73e.tar.gz to https://codeload.github.com/NixOS/nixpkgs/tar.gz/c02d05bcf73fb496c604798c2268ed424a09e73e during transfer
seems like maybe dns worked because the url changed but now it's mad about that for whatever reason?
i'm not sure why this happens but lix is doing the "right" thing here | 22:49:32 |
| raitobezarius | we cannot let a transfer bullshit us an URL and then change it last minute | 22:49:40 |
| raitobezarius | i will take a look if i can reproduce and check if GitHub is at fault or we have a bug somewhere else in the machinery | 22:50:26 |
| 3 Aug 2025 |
 helle (just a stray cat girl) | In reply to @raitobezarius:matrix.org
i will take a look if i can reproduce and check if GitHub is at fault or we have a bug somewhere else in the machinery according to jade and myself it most likely had a bug in the machinery
and we don't have any test suite coverage for it and we need to add the machinery for it | 05:11:37 |
| helle (just a stray cat girl) | * according to jade and myself it most likely is a bug in the machinery
and we don't have any test suite coverage for it and we need to add the machinery for it
| 05:12:37 |
| helle (just a stray cat girl) | (machinery being testing bad and weird http states, which due to how deeply we configure and add hooks to curl in lix, have failure modes not seen in curl itself | 05:13:57 |
 K900 | I have a stupid(?) idea | 07:46:54 |
| K900 | Should I duct tape systemd-inhibit to the build hook | 07:48:50 |
| helle (just a stray cat girl) | needs discussing, but is reasonable to consider | 07:54:54 |
| K900 | Oh no logind doesn't have a C API for this | 07:56:51 |
 jade_ | no, because the build hook rejects if it's going to do a local build, so you have no idea whether a nix build is actively running | 08:39:53 |
 Linux Hackerman | so I've fixed cross-compilation (and the issue where I reported that it was broken was labelled as a release blocker). Would it make sense to add at least one cross build to CI, so it doesn't get broken by accident again? Or is that too costly? | 15:36:43 |
| raitobezarius | go ahead | 16:19:30 |
| raitobezarius | add it | 16:19:31 |
| raitobezarius | we are a bit strained on x86 but that shall change soon I suppose | 16:19:41 |
 just1602 | I was thinking about lix CI while listening to a podcast where someone from 0xide mention that a full rack has 2000 CPU core, 32TB of RAM and something like 250TB of storage. | 16:22:02 |
| just1602 | I was like, just half a rack would be enough to fix all our CI issues | 16:22:12 |
| raitobezarius | hahahahaha | 16:22:16 |
| raitobezarius | but we don't have millions of euros on our hand alas | 16:22:22 |
| just1602 | At some point, I hope they're gonna have enough client to sponsor some nice opensourc projects :D | 16:23:57 |
 aloisw | In reply to @raitobezarius:matrix.org
we are a bit strained on x86 but that shall change soon I suppose If you have enough aarch64 then I guess you could also do aarch64 -> x86_64 cross? | 16:42:09 |
| raitobezarius | we do have more aarch64 | 16:42:20 |
| raitobezarius | at least, x86 is doing more work than aarch64 | 16:42:25 |
| raitobezarius | so plausibly, this could be the job you described | 16:42:31 |
| raitobezarius | it will still generate more work for x86 which will have to calculate one more job at the nej phase | 16:42:43 |
| raitobezarius | but not a compilation job at least | 16:42:48 |
| K900 | But what if I add it to the goal loop | 16:44:29 |
| aloisw | In reply to @raitobezarius:matrix.org
it will still generate more work for x86 which will have to calculate one more job at the nej phase Evaling one Lix should be quite cheap though? | 16:48:19 |
| raitobezarius | In reply to @aloisw:julia0815.de
Evaling one Lix should be quite cheap though? Yeah, I didn't mean this as this would be much more expensive | 16:48:44 |
| raitobezarius | but cost for x86(after) > cost for x86(before) | 16:48:54 |
