aboutsummaryrefslogtreecommitdiff
path: root/src/libutil
AgeCommit message (Collapse)Author
2021-05-19Extract a generic `computeClosure` functionregnat
Move the `closure` logic of `computeFSClosure` to its own (templated) function. This doesn’t bring much by itself (except for the ability to properly test the “closure” functionality independently from the rest), but it allows reusing it (in particular for the realisations which will require a very similar closure computation)
2021-05-18Fix extra slash in canonPath outputMatthew Bauer
When you have a symlink like: /tmp -> ./private/tmp you need to resolve ./private/tmp relative to /tmp’s dir: ‘/’. Unlike any other path output by dirOf, / ends with a slash. We don’t want trailing slashes here since we will append another slash in the next comoponent, so clear s like we would if it was a symlink to an absoute path. This should fix at least part of the issue in https://github.com/NixOS/nix/issues/4822, will need confirmation that it actually fixes the problem to close though. Introduced in f3f228700a52857fe6e8632df4e935551ea219ff.
2021-04-22Remove makeDecompressionSource()Eelco Dolstra
This function doesn't support all compression methods (i.e. 'none' and 'br') so it shouldn't be exposed. Also restore the original decompress() as a wrapper around makeDecompressionSink().
2021-04-22libutil: allow decompression with none/empty methodLuke Granger-Brown
The S3 store relies on the ability to be able to decompress things with an empty method, because it just passes the value of the Content-Encoding directly to decompress. If the file is not compressed, then this will cause the compression routine to get confused. This caused NixOS/nixpkgs#120120.
2021-04-20Fix brotli compression of files > 128 KiBEelco Dolstra
This has been broken since faa31f40846f7a4dbc2487d000b112a6aef69d1b.
2021-04-15Merge pull request #4679 from ony/feature/one-pass-canon-pathEelco Dolstra
Optimize canonPath to resolve relative symlinks in one pass
2021-04-15Drop libbz2 / zlib / lzma dependency + style fixesEelco Dolstra
2021-04-15Merge branch 'libarchive-decompress' of https://github.com/serokell/nixEelco Dolstra
2021-04-07Restore stack size in child processesEelco Dolstra
Fixes #4673.
2021-04-07restoreSignals() + restoreAffinity() -> restoreProcessContext()Eelco Dolstra
2021-04-07PathSubstitutionGoal: Clean up pipeEelco Dolstra
If there were many top-level goals (which are not destroyed until the very end), commands like $ nix copy --to 'ssh://localhost?remote-store=/tmp/nix' \ /run/current-system --no-check-sigs --substitute-on-destination could fail with "Too many open files". So now we do some explicit cleanup from amDone(). It would be cleaner to separate goals from their temporary internal state, but that would be a bigger refactor.
2021-03-31canonPath in one passMykola Orliuk
2021-03-26Fix some typosEelco Dolstra
Fixes #4671.
2021-03-16Fix Nix to properly work with stores using a scoped IPv6 addressMaximilian Bosch
According to RFC4007[1], IPv6 addresses can have a so-called zone_id separated from the actual address with `%` as delimiter. In contrast to Nix 2.3, the version on `master` doesn't recognize it as such: $ nix ping-store --store ssh://root@fe80::1%18 --experimental-features nix-command warning: 'ping-store' is a deprecated alias for 'store ping' error: --- Error ----------------------------------------------------------------- nix don't know how to open Nix store 'ssh://root@fe80::1%18' I modified the IPv6 match-regex accordingly to optionally detect this part of the address. As we don't seem to do anything special with it, I decided to leave it as part of the URL for now. Fixes #4490 [1] https://tools.ietf.org/html/rfc4007
2021-03-10Use libarchive for all compressionYorick van Pelt
2021-02-26nix flake update: Recreate the lock fileEelco Dolstra
This is probably what most people expect it to do. Fixes #3781. There is a new command 'nix flake lock' that has the old behaviour of 'nix flake update', i.e. it just adds missing lock file entries unless overriden using --update-input.
2021-02-26Merge pull request #4530 from alyssais/killEelco Dolstra
libutil: EPERM from kill(-1, ...) is fine
2021-02-24Respect command registrations in plugins.Shea Levy
2021-02-24Initialize plugins after handling initial command line flagsShea Levy
This is technically a breaking change, since attempting to set plugin files after the first non-flag argument will now throw an error. This is acceptable given the relative lack of stability in a plugin interface and the need to tie the knot somewhere once plugins can actually define new subcommands.
2021-02-22Add x86_64 compute levels as additional system typesDaniël de Kok
When performing distributed builds of machine learning packages, it would be nice if builders without the required SIMD instructions can be excluded as build nodes. Since x86_64 has accumulated a large number of different instruction set extensions, listing all possible extensions would be unwieldy. AMD, Intel, Red Hat, and SUSE have recently defined four different microarchitecture levels that are now part of the x86-64 psABI supplement and will be used in glibc 2.33: https://gitlab.com/x86-psABIs/x86-64-ABI https://lwn.net/Articles/844831/ This change uses libcpuid to detect CPU features and then uses them to add the supported x86_64 levels to the additional system types. For example on a Ryzen 3700X: $ ~/aps/bin/nix -vv --version | grep "Additional system" Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
2021-02-07Support --no-net for backwards compatibilityEelco Dolstra
2021-02-07libutil: EPERM from kill(-1, ...) is fineAlyssa Ross
I tested a trivial program that called kill(-1, SIGKILL), which was run as the only process for an unpriveleged user, on Linux and FreeBSD. On Linux, kill reported success, while on FreeBSD it failed with EPERM. POSIX says: > If pid is -1, sig shall be sent to all processes (excluding an > unspecified set of system processes) for which the process has > permission to send that signal. and > The kill() function is successful if the process has permission to > send sig to any of the processes specified by pid. If kill() fails, > no signal shall be sent. and > [EPERM] > The process does not have permission to send the signal to any > receiving process. My reading of this is that kill(-1, ...) may fail with EPERM when there are no other processes to kill (since the current process is ignored). Since kill(-1, ...) only attempts to kill processes the user has permission to kill, it can't mean that we tried to do something we didn't have permission to kill, so it should be fine to interpret EPERM the same as success here for any POSIX-compliant system. This fixes an issue that Mic92 encountered[1] when he tried to review a Nixpkgs PR on FreeBSD. [1]: https://github.com/NixOS/nixpkgs/pull/81459#issuecomment-606073668
2021-02-05Move the GENERATE_CMP macro to its own fileregnat
Despite being an ugly hack, it can probably be useful in a couple extra places
2021-01-27Remove mkFlag()Eelco Dolstra
2021-01-25Group common optionsEelco Dolstra
2021-01-25Group subcommands by categoryEelco Dolstra
2021-01-25Make '--help' do the same as 'help' (i.e. show a manpage)Eelco Dolstra
2021-01-25Merge pull request #4467 from edolstra/error-formattingEelco Dolstra
Improve error formatting
2021-01-22Add FIXMEEelco Dolstra
2021-01-21Change error position formattingEelco Dolstra
It's now at /home/eelco/Dev/nixpkgs/pkgs/applications/misc/hello/default.nix:7:7: instead of at: (7:7) in file: /home/eelco/Dev/nixpkgs/pkgs/applications/misc/hello/default.nix The new format is more standard and clickable.
2021-01-21Remove trailing whitespaceEelco Dolstra
2021-01-21Improve error formattingEelco Dolstra
Changes: * The divider lines are gone. These were in practice a bit confusing, in particular with --show-trace or --keep-going, since then there were multiple lines, suggesting a start/end which wasn't the case. * Instead, multi-line error messages are now indented to align with the prefix (e.g. "error: "). * The 'description' field is gone since we weren't really using it. * 'hint' is renamed to 'msg' since it really wasn't a hint. * The error is now printed *before* the location info. * The 'name' field is no longer printed since most of the time it wasn't very useful since it was just the name of the exception (like EvalError). Ideally in the future this would be a unique, easily googleable error ID (like rustc). * "trace:" is now just "…". This assumes error contexts start with something like "while doing X". Example before: error: --- AssertionError ---------------------------------------------------------------------------------------- nix at: (7:7) in file: /home/eelco/Dev/nixpkgs/pkgs/applications/misc/hello/default.nix 6| 7| x = assert false; 1; | ^ 8| assertion 'false' failed ----------------------------------------------------- show-trace ----------------------------------------------------- trace: while evaluating the attribute 'x' of the derivation 'hello-2.10' at: (192:11) in file: /home/eelco/Dev/nixpkgs/pkgs/stdenv/generic/make-derivation.nix 191| // (lib.optionalAttrs (!(attrs ? name) && attrs ? pname && attrs ? version)) { 192| name = "${attrs.pname}-${attrs.version}"; | ^ 193| } // (lib.optionalAttrs (stdenv.hostPlatform != stdenv.buildPlatform && !dontAddHostSuffix && (attrs ? name || (attrs ? pname && attrs ? version)))) { Example after: error: assertion 'false' failed at: (7:7) in file: /home/eelco/Dev/nixpkgs/pkgs/applications/misc/hello/default.nix 6| 7| x = assert false; 1; | ^ 8| … while evaluating the attribute 'x' of the derivation 'hello-2.10' at: (192:11) in file: /home/eelco/Dev/nixpkgs/pkgs/stdenv/generic/make-derivation.nix 191| // (lib.optionalAttrs (!(attrs ? name) && attrs ? pname && attrs ? version)) { 192| name = "${attrs.pname}-${attrs.version}"; | ^ 193| } // (lib.optionalAttrs (stdenv.hostPlatform != stdenv.buildPlatform && !dontAddHostSuffix && (attrs ? name || (attrs ? pname && attrs ? version)))) {
2021-01-18Merge branch 'slashes-in-github-branches' of https://github.com/Ma27/nixEelco Dolstra
2021-01-15Merge pull request #4240 from bburdette/2259-error-messageDomen Kožar
2259 error message - "auto-call" error
2021-01-08Fix testsEelco Dolstra
2021-01-08Support binary unit prefixes in command line argumentsEelco Dolstra
2021-01-08string2Int(): Return std::optionalEelco Dolstra
2021-01-08Remove unused mkFlag1Eelco Dolstra
2021-01-08Remove mkFlag integer specialisationEelco Dolstra
2021-01-08Remove mkIntFlagEelco Dolstra
2020-12-23Merge pull request #4336 from NixOS/manpagesEelco Dolstra
Documentation for nix subcommands
2020-12-23Command: Remove examples()Eelco Dolstra
2020-12-22Fix testsEelco Dolstra
2020-12-22Don't log from inside the loggerEelco Dolstra
This deadlocks ProgressBar, e.g. # nix run --impure --no-substitute --store '/tmp/nix2?store=/foo' --expr 'derivation { builder = /nix/store/zi90rxslsm4mlr46l2xws1rm94g7pk8p-busybox-1.31.1-x86_64-unknown-linux-musl/bin/busybox; }' leads to Thread 1 (Thread 0x7ffff6126e80 (LWP 12250)): #0 0x00007ffff7215d62 in __lll_lock_wait () from /nix/store/9df65igwjmf2wbw0gbrrgair6piqjgmi-glibc-2.31/lib/libpthread.so.0 #1 0x00007ffff720e721 in pthread_mutex_lock () from /nix/store/9df65igwjmf2wbw0gbrrgair6piqjgmi-glibc-2.31/lib/libpthread.so.0 #2 0x00007ffff7ad17fa in __gthread_mutex_lock (__mutex=0x6c5448) at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/x86_64-unknown-linux-gnu/bits/gthr-default.h:749 #3 std::mutex::lock (this=0x6c5448) at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/bits/std_mutex.h:100 #4 std::unique_lock<std::mutex>::lock (this=0x7fffffff09a8, this=0x7fffffff09a8) at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/bits/unique_lock.h:141 #5 std::unique_lock<std::mutex>::unique_lock (__m=..., this=0x7fffffff09a8) at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/bits/unique_lock.h:71 #6 nix::Sync<nix::ProgressBar::State, std::mutex>::Lock::Lock (s=0x6c5448, this=0x7fffffff09a0) at src/libutil/sync.hh:45 #7 nix::Sync<nix::ProgressBar::State, std::mutex>::lock (this=0x6c5448) at src/libutil/sync.hh:85 #8 nix::ProgressBar::logEI (this=0x6c5440, ei=...) at src/libmain/progress-bar.cc:131 #9 0x00007ffff7608cfd in nix::Logger::logEI (ei=..., lvl=nix::lvlError, this=0x6c5440) at src/libutil/logging.hh:88 #10 nix::getCodeLines (errPos=...) at src/libutil/error.cc:66 #11 0x00007ffff76073f2 in nix::showErrorInfo (out=..., einfo=..., showTrace=<optimized out>) at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/optional:897 #12 0x00007ffff7ad19e7 in nix::ProgressBar::logEI (this=0x6c5440, ei=...) at src/libmain/progress-bar.cc:134 #13 0x00007ffff7ab9d10 in nix::Logger::logEI (ei=..., lvl=nix::lvlError, this=0x6c5440) at src/libutil/logging.hh:88 #14 nix::handleExceptions(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<void ()>) (programName="/home/eelco/Dev/nix/outputs/out/bin/nix", fun=...) at src/libmain/shared.cc:328 #15 0x000000000046226b in main (argc=<optimized out>, argv=<optimized out>) at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/ext/new_allocator.h:80
2020-12-21Move doc() to ArgsEelco Dolstra
2020-12-10Add lvlNotice log levelEelco Dolstra
This is like syslog's LOG_NOTICE: "normal, but significant, condition".
2020-12-09libstore/openStore: fix stores with IPv6 addressesMaximilian Bosch
In `nixStable` (2.3.7 to be precise) it's possible to connect to stores using an IPv6 address: nix ping-store --store ssh://root@2001:db8::1 This is also useful for `nixops(1)` where you could specify an IPv6 address in `deployment.targetHost`. However, this behavior is broken on `nixUnstable` and fails with the following error: $ nix store ping --store ssh://root@2001:db8::1 don't know how to open Nix store 'ssh://root@2001:db8::1' This happened because `openStore` from `libstore` uses the `parseURL` function from `libfetchers` which expects a valid URL as defined in RFC2732. However, this is unsupported by `ssh(1)`: $ nix store ping --store 'ssh://root@[2001:db8::1]' cannot connect to 'root@[2001:db8::1]' This patch now allows both ways of specifying a store (`root@2001:db8::1`) and also `root@[2001:db8::1]` since the latter one is useful to pass query parameters to the remote store. In order to achieve this, the following changes were made: * The URL regex from `url-parts.hh` now allows an IPv6 address in the form `2001:db8::1` and also `[2001:db8::1]`. * In `libstore`, a new function named `extractConnStr` ensures that a proper URL is passed to e.g. `ssh(1)`: * If a URL looks like either `[2001:db8::1]` or `root@[2001:db8::1]`, the brackets will be removed using a regex. No additional validation is done here as only strings parsed by `parseURL` are expected. * In any other case, the string will be left untouched. * The rules above only apply for `LegacySSHStore` and `SSHStore` (a.k.a `ssh://` and `ssh-ng://`). Unresolved questions: * I'm not really sure whether we want to allow both variants of IPv6 addresses in the URL parser. However it should be noted that both seem to be possible according to RFC2732: > This document incudes an update to the generic syntax for Uniform > Resource Identifiers defined in RFC 2396 [URL]. It defines a syntax > for IPv6 addresses and allows the use of "[" and "]" within a URI > explicitly for this reserved purpose. * Currently, it's not supported to specify a port number behind the hostname, however it seems as this is not really supported by the URL parser. Hence, this is probably out of scope here.
2020-12-03Add deprecated aliases for renamed commandsEelco Dolstra
2020-12-02Add forgotten `override` annotationregnat
2020-12-02read(): Use char * instead of unsigned char *Eelco Dolstra
This gets rid of some pointless casts.