Now that ld.so is symlinked into the libc derivation,
we can use it as a dynamic linker.
In my testing, OpenBSD does not have any issues with executing from
a symlinked ld.so.
`fetchNpmDeps` works from the exact same source tree, thus `patchFlags`
must be respected so that any patches get applied correctly.
Signed-off-by: Christoph Heiss <christoph@c8h4.io>
The indentation stripping semantics of strings are fairly bad and have a
few gotchas where the resulting string has not the intended indentation.
This commit fixes most if not all such instances in Nixpkgs.
I tried to strive a balance between keeping the diff small and
reformatting/refactoring the code to look better. In general,
reformatting should be left to Nixfmt.
Note that this causes a lot of rebuilds by design. All changes need to
be thoroughly vetted and reviewed for correctness. There is no automatic
way to prove correctness.
List of files to fix generated by running
https://gerrit.lix.systems/c/lix/+/2092 on Nixpkgs and looking at the
warnings.
This is a follow-up to a169553f7e.
In most cases it should allow the TLS verification to be enabled.
It also makes the behavior of `fetchurl` more consistent with other fetchers
like `fetchgit`.
Ideally we would always fallback on `cacert` but I am not sure how to build
`cacert` during bootstrap without making an unmaintainable mess.
As binutils-efi no longer exists, there's no longer any reason to have
the withEFI flag. All supported builds should also build xen.efi.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Without this change, all Darwin platforms mangle to the same suffix
salt. That is normally not an issue because build = host should mean a
non-cross build, but it causes issues on Darwin with static builds
because `DEVELOPER_DIR_FOR_BUILD` and `DEVELOPER_DIR` will refer to
different SDKs but mangle to the same `DEVELOPER_DIR` with suffix salt.
The fix is to mangle static builds differently from non-static ones on
Darwin, which allows building for a static Darwin target on a
same-architecture Darwin host. This fix is applied only to Dariwn
because the issue does not appear to affect other platforms.
It is unusual to invoke a wrapped compiler without setting
`DEVELOPER_DIR`, but it can happen when a user adds a compiler to their
installed packages or when a package intentionally invokes the compiler
without an environment (such as the GHC binary packages).
Some compilers may know to check these paths when `SDKROOT` is set, but
it’s not assumed they do. `SDKROOT` is instead derived from the
`DEVELOPER_DIR`, and `NIX_CFLAGS_COMPILE` is set up with the sysroot and
necessary framework and include search paths.
The location of `libSystem.tbd` depends on the SDK, making it
effectively dynamic. It must be located relative to the `SDKROOT`
instead of to `clang.libc`.
- Removes the non-slim build instructions, massively simplifying
everything in the package.
- Removes unecessary patches.
- Inherits functions from lib instead of repeating lib.* everywhere.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
As the builder is generic, more people may be using it, so we should try
to keep this value as close to the upstream source of truth as possible.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
This is some thing introduced in 2017 to work around a problem that
no longer seems to exist. Nothing uses it except its own test, which
these days passes even with the standard `clangStdenv`.
This adds convenience writers for self-contained Nim programs.
Those are compiled into very small binaries.
Test with: `nix build .#pkgs.tests.writers.{bin,simple,wrapping}.nim`
`makeWrapper` is often used in these with `source "${makeWrapper}/nix-support/setup-hook"`
which causes `error: makeWrapper/makeShellWrapper must be in nativeBuildInputs` on cross.
Prior to this commit it was not possible to modify e.g. the list of ignored directories at all, however given that `buildFHSEnvBubblewrap` effectively uses a sandboxing tool (*bwrap*) I feel like this is a missed opportunity.
The code in nixpkgs already covers all the knobs that are required to get *Nix* itself to run inside bubblewrap, so why not allow users to make that additional modification?
While additional `ro_mounts` and such can be *added* to the bubblewrap invocation, the already mounted directories cannot be removed, and even if shadowed by e.g. a tmpfs mount, this would still allow something inside the sandbox to potentially unmount the tmpfs and access the data.
So what this change does is moving the snippet where custom code can be injected down by four lines so that users can actually modify those variables e.g. using `ignored+=( /home /srv /mnt /boot )`.
The only cases in which this would break is:
- someone using those variable names in `extraPreBwrapCmds` already and relying on them being overwritten; I would consider that chance slim, and the fix would be easy enough
- someone using a construct like `false && \` to disable the `ignored` initialisation and effectively working around this limitation; again the chances are slim (even though I know I'd be affected), and the fix would be easy enough (as this change makes the workaround needless anyway so it's an improvement)
Signed-off-by: benaryorg <binary@benary.org>
Setting the image creation timestamp in the image metadata to a
constant date can cause problems with self-hosted container
registries, that need to e.g. prune old images. This timestamp is
also useful for debugging.
However, it is almost never useful to set the filesystem timestamp to
a constant value. Doing so not only causes the image to possibly no
longer be reproducible, but also removes any possibility of
deduplicating layers with other images, causing unnecessary storage
space usage.
Therefore, this commit introduces "mtime", a new parameter to
streamLayeredImage, which allows specifying the filesystem timestamps
separately from "created". For backwards compatibility, "mtime"
defaults to the value of "created".
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
To prevent excessive build times when replacement lists are shared between
partially overlapping closures, skip the build of unused replacements.
Unfortunately, this also means that the replacement won't be applied any more
if another replacement that is applied introduces its source. But this is a
corner case, and we already show a warning, so make it clearer that handling
this situation (should it ever arise) is the responsibility of the user.
Unlike regular input-addressed or fixed-output derivations, floating and
deferred derivations do not have their store path available at evaluation time,
so their outPath is a placeholder. The following changes are needed for
replaceDependencies to continue working:
* Detect the placeholder and retrieve the store path using another IFD hack
when collecting the rewrite plan.
* Try to obtain the derivation name needed for replaceDirectDependencies from
the derivation arguments if a placeholder is detected.
* Move the length mismatch detection to build time, since the placeholder has a
fixed length which is unrelated to the store path.
Rewrite replaceDependency so that it can apply multiple replacements in
one go. This includes correctly handling the case where one of the
replacements itself needs to have another replacement applied as well.
This rewritten function is now aptly called replaceDependencies.
For compatibility, replaceDependency is retained as a simple wrapper
over replaceDependencies. It will cause a rebuild because the unpatched
dependency is now referenced by derivation instead of by storePath, but
the functionality is equivalent.
Fixes: https://github.com/NixOS/nixpkgs/issues/199162
This make sure the credentials cannot be leaked in a MITM attack.
Note that this change might break some existing deployments if the users
tries to fetch resources on endpoints with invalid certificates.
The impacted users will have the following choices:
* fix the endpoint providing the resource
* override SSL_CERT_FILE to either disable the verification (not
recommended) or to set it to a path including their CA certificate.
Previously running the Bitwarden AppImage would error.
This adds libsecret which resolves the error and allows the
Bitwarden AppImage to function normally.
