 | Nix Hackers | 892 Members |
| For people hacking on the Nix package manager itself | 189 Servers |
| Nix Hackers | 892 Members |
| For people hacking on the Nix package manager itself | 189 Servers |
| Sender | Message | Time |
|---|---|---|
| 11 Nov 2024 | ||
 Vladimír Čunát | (same output, though as usual, on Hydra this got overwritten, but I remember) | 09:01:55 |
| Vladimír Čunát | Mic92: now I tried the same derivation on a machine outside NixOS infra and there this issue won't reproduce. Hard to guess what's the key difference, though. | 09:08:50 |
| Vladimír Čunát | * Mic92: now I tried the same-hashed derivation on a machine outside NixOS infra and there this issue won't reproduce. Hard to guess what's the key difference, though. | 09:09:12 |
 Martin Schwaighofer | In reply to @joerg:thalheim.ioIs the meeting link https://jitsi.lassul.us/nix-maintainers or something else? The link to the google calendar entry for the work meeting is a dead link. 😅 | 13:02:47 |
 gr_h_m joined the room. | 20:04:08 | |
| 12 Nov 2024 | ||
 John Ericson | In reply to @mschwaig:matrix.orgHi @mschwaig:matrix.org have you looked at CA derivations? From a lightening quick skim of your paper, sounds like we've had some similar ideas on how to retrofit the benefits of content addressed derivation outputs for input-addressed derivation outputs | 01:45:29 |
| John Ericson | I would be happy to talk to you about this more | 01:45:55 |
| Martin Schwaighofer | In reply to @Ericson2314:matrix.org Yes I have looked at CA derivations! 😊 I'd be interested in you ideas on this topic and how similarly/differently we see those things! If you're looking for specifics in the paper, I think besides T3/M3 the sections relevant to the content addressing vs input addressing issue are 6.3.2, the first half of 6.4.2, and 4.1.1. | 02:07:32 |
| Martin Schwaighofer | In reply to @Ericson2314:matrix.orgSounds great, let's do that. 😊 | 02:08:05 |
 pfhuh joined the room. | 05:53:47 | |
 jade_ | In reply to @vcunat:matrix.orgcan happen if the scheduler fucks up (we had this bug in lix HEAD recently because of a big scheduler refactor) | 09:47:49 |
| jade_ | also maybe a remote builds GC related bug | 09:48:02 |
| jade_ | since the remote build system does not keep paths live properly | 09:48:14 |
| jade_ | * since the remote build system does not keep paths live properly often | 09:48:16 |
| jade_ | https://git.lix.systems/lix-project/lix/issues/505 see | 09:50:48 |
 hexa | I did run a full GC in the mac builders last night | 09:52:12 |
 Mic92 | hexa: maybe we need to take out machines out of hydra when doing a GC. Machines are under load when this happen anyway. | 11:45:10 |
 p14 | I am having a problem with a http tarball URL used as a flake input somehow resulting in an incomplete unpack on disk. Are there known bugs in this area? Out of 70k files I am missing 1k in the unpack; these are present if I run ‘tar xf’ manually but not in the nix store for the flake input outPath. | 12:26:07 |
| p14 | It is repeatable in that the same problem seems to have occurred with two different tarballs | 12:51:32 |
 puck | are the files in the tarball ordered? | 15:04:05 |
 azahi changed their profile picture. | 18:51:18 | |
| jade_ | In reply to @joerg:thalheim.iounless the gc system was rewritten in cppnix, it is merely running one deleter thread and is not going to be loading the machine that hard | 22:03:56 |
| jade_ | but yes, probably would not be too absurd to take machines out while gc'ing them | 22:04:14 |
| hexa | yeah, it didn't seem to affect the mac much | 22:04:16 |
| hexa | and all other builders regularly run gcs as well | 22:04:51 |
| hexa | if this was a substantial problem we'd know | 22:05:07 |
| jade_ | i have a prototype for multithreaded gc deletion in lix, but i haven't finished it. it is an area where nix scales badly, anyhow. | 22:04:58 |
| jade_ | the gc root bug has affected lix's CI infrastructure pretty badly, but it is somewhat unclear if it is fully resolvable without either significant perf problems or protocol changes (which in the lix case are impossible) | 22:06:08 |
| jade_ | since you would have to potentially send a gcroot request for every build input of a derivation which would be a nasty latency stackup | 22:06:34 |
| jade_ | alternative is to send the .drv file or something else that has the things as dependency and have that cause gcroots | 22:07:01 |