| Age | Commit message (Collapse) | Author |
|---|
|
There already existed a smoke test for the link content length,
but it appears that there exists some corruptions pernicious enough
to replace the file content with zeros, and keeping the same length.
--repair-path now goes as far as checking the content of the link,
making it true to its name and actually repairing the path for such
coruption cases.
|
|
Add a crude tracing mechansim for the build results
|
|
reproducibility: hide non-reproducible settings from manual
|
|
ca-specific-schema.sql: add index on RealisationsRefs(referrer)
|
|
This is a temporary hack until we make queryMissing() async.
Closes #5324.
|
|
|
|
|
|
|
|
https://hydra.nixos.org/build/161439235
|
|
On macOS / BSD, these sockets inherit the non-blocking flag of the
server soocket, which is not what we want.
https://github.com/dotnet/runtime/issues/25069
https://bugs.python.org/issue7995
https://hydra.nixos.org/build/161439304
|
|
Add a `_NIX_TRACE_BUILT_OUTPUTS` environment variable that can be set to
a filename in which the result of each build will be logged.
This is intentionally crude and undocumented as it’s only meant to be a
temporary thing to assess the usefulness of CA derivations.
Any other use would need a cleaner re-implementation first.
|
|
Make the build of unresolved derivations return the same status as the
resolved one, except in the case of an `AlreadyValid` in which case it
will return `ResolvesToAlreadyValid` to mean that the outputs of the unresolved
derivation weren’t known, but the resolved one is.
|
|
Closes #1584.
|
|
|
|
Tidy up the logging
|
|
|
|
|
|
Fixes: https://github.com/NixOS/nixos-homepage/issues/762
|
|
Fix #5712
|
|
|
|
Because the manual is generated from default values which are themselves
generated from various sources (cpuid, bios settings (kvm), number of
cores). This commit hides non-reproducible settings from the manual
output.
|
|
No matter what, we need to resize the buffer to not have any scratch
space after we do the `read`. In the end of file case, `got` will be 0
from it's initial value.
Before, we forgot to resize in the EOF case with the break. Yes, we know
we didn't recieve any data in that case, but we still have the scatch
space to undo.
Co-Authored-By: Will Fancher <Will.Fancher@Obsidian.Systems>
|
|
This doesn't fix the bug, but makes the code less difficult to read.
Also improve the comments, now that it is clear what part is needed in
each code path.
|
|
No more buffering in string.
|
|
Use the macros more, so we properly skip work when the log level
excludes. Also log the daemon operation number on the daemon side.
|
|
"recursive-nix" system feature only with experimental feature
|
|
|
|
Inspired by https://github.com/NixOS/nix/pull/5599
|
|
Set new rosetta 2 path in sandbox
|
|
see:
https://github.com/NixOS/nix/pull/5388
and
https://github.com/NixOS/nix/pull/5251
|
|
|
|
|
|
Closes https://github.com/NixOS/nix/issues/972
|
|
|
|
|
|
Fix a stack buffer overflow found by running MemorySanitizer.
|
|
async realisation substitution
|
|
|
|
|
|
For a typical desktop system (~2K packages) we can easily get 100K
entries in RealisationsRefs. Without indices query for RealisationsRefs
requires linear scan.
RealisationsRefs(referrer)
--------------------------
Inefficiency is seen as a 100% CPU load of nix-daemon for the following
scenario:
$ nix edit -f . bash # add unused environment variable, like FOO="1"
# populate RealisationsRefs, build fresh system
$ nix build -f nixos system --arg config '{ contentAddressedByDefault = true; }'
$ nix edit -f . bash # add unused environment variable, like FOO="2"
$ time nix build -f nixos system --arg config '{ contentAddressedByDefault = true; }'
In this case `bash `will be rebuilt a few times and then rest of CPU
time is spent on scanning RealisationsRefs table (about 5 CPU-minutes
on my machine).
Before the change:
$ time nix build -f nixos system ... # step 4 above
real 34m3,613s
user 0m5,232s
sys 0m0,758s
Of all this time about 29.5 minutes are taken by nix-daemon's CPU time.
After the change:
$ time nix build -f nixos system ... # step 4 above
real 4m50,061s
user 0m5,038s
sys 0m0,677s
Of all this time about 1 minute is taken by nix-daemon's CPU time.
Most of the time is spent polling for non-existent realisations on
cache-nixos.org.
Realisations(outputPath)
------------------------
After running CA system for two weeks I got ~1M entries in Realisations
table. `nix-collect-garbage` became very slow (seemingly 100 path deletions
per second). It happens due to a slow cascading delete from Realisations
triggered by deletion from ValidPaths.
The fix is to add an index on primary key from ValidPaths(id) that
triggers cascading deletions.
Before the change:
$ time nix-collect-garbage -d --max-freed 100G
<interrupted before finish, took too long>
real 23m32.411s
user 17m49.679s
sys 4m50.609s
Most of time was spent in re-scanning Realisations table on each path deletion.
After the change:
$ time nix-collect-garbage -d --max-freed 100G
real 8m43.226s
user 6m16.317s
sys 1m40.188s
Time is spent scanning sqlite indices and in kernel when unlinking directories.
|
|
Allow references in addPath
|
|
Co-Authored-By: Eelco Dolstra <edolstra@gmail.com>
|
|
Doing it as a side-effect of calling LocalStore::makeStoreWritable()
is very ugly.
Also, make sure that stopping the progress bar joins the update
thread, otherwise that thread should be unshared as well.
|
|
|
|
Since 4806f2f6b0fd2cae401b89fe19d8c528ffd88b5f, we can't have paths with
references passed to builtins.{path,filterSource}. This prevents many cases
of those functions called on IFD outputs from working. Resolve this by
passing the references found in the original path to the added path.
|
|
When setting flake-local options (with the `nixConfig` field), forward
these options to the daemon in case we’re using one.
This is necessary in particular for options like `binary-caches` or
`post-build-hook` to make sense.
Fix <https://github.com/NixOS/nix/commit/343239fc8a1993f707a990c2cd54a41f1fa3de99#r44356843>
|
|
|
|
|
|
That way we can fetch several realisations from the same cache in
parallel
|
|
Doesn’t change much so far because everything is still using it
synchronously, but should allow the binary cache to fetch stuff in
parallel
|
