Nix Hackers | 955 Members | |
| For people hacking on the Nix package manager itself | 200 Servers |
| Sender | Message | Time |
|---|---|---|
| 12 Nov 2024 | ||
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 | |
In reply to @Ericson2314:matrix.orgSounds great, let's do that. 😊 | 02:08:05 | |
| 05:53:47 | ||
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 | |
| also maybe a remote builds GC related bug | 09:48:02 | |
| since the remote build system does not keep paths live properly | 09:48:14 | |
| * since the remote build system does not keep paths live properly often | 09:48:16 | |
| https://git.lix.systems/lix-project/lix/issues/505 see | 09:50:48 | |
| I did run a full GC in the mac builders last night | 09:52:12 | |
| 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 | |
| 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 | |
| It is repeatable in that the same problem seems to have occurred with two different tarballs | 12:51:32 | |
| are the files in the tarball ordered? | 15:04:05 | |
| 18:51:18 | ||
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 | |
| but yes, probably would not be too absurd to take machines out while gc'ing them | 22:04:14 | |
| yeah, it didn't seem to affect the mac much | 22:04:16 | |
| and all other builders regularly run gcs as well | 22:04:51 | |
| if this was a substantial problem we'd know | 22:05:07 | |
| 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 | |
| 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 | |
| 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 | |
| alternative is to send the .drv file or something else that has the things as dependency and have that cause gcroots | 22:07:01 | |
(the specific problem is that nix copy and its backend operations do not keep the full closure alive on the remote end) | 22:07:24 | |
* (the specific problem is that nix copy and its backend operations do not keep the full closure alive on the remote end after checking for common paths) | 22:07:32 | |
In reply to @puck:puck.moeNot sure what you’re asking, mind elaborating? | 22:18:38 | |
nix-2.25.0 does not build against latest release of libgit2 as src/libfetchers/git-utils.cc:288:13: error: ‘git_mempack_write_thin_pack’ was not declared in this scope. It looks like it depends on unreleased feature: https://github.com/libgit2/libgit2/commit/f9c35fb50998d1c9d26293a18ade3d7c32f6ecb0. Is it intentional? I would hope for a silently disabled feature rather than hard build failure. | 22:47:47 | |
| is there a URL where I can access the Nix manual for 2.25? | 23:53:02 | |