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.
This patch adds an assertion to the writeTextFile trivial
builder, asserting that a specified destination starts with
a slash.
This matches the current behavior of the function and merely
provides a helpful error message.
The dotnet sdk used usually needs to match the one required by the
project (global.json). Having the dependcy in nix just meant it always
had to be overridden.
Rationale:
With the advent of RFC 140, Nixpkgs becomes to promote self-contained package
directories and strongly discourages scattering along the old and deprecated
filesystem hierarchy.
Further, `build-support/flutter/*` is not referenced by any other expressions in
Nixpkgs besides flutter itself.
Further, concentrating all Flutter-related toolset below a same directory
hierarchy (arguably?) eases maintenance and future migrations.
Seeing the following new warnings pop up on stderr when cargo was bumped
to 1.78:
```
warning: `/build/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
```
which happens to break commitmsgfmt builds in nix (#320294).
closes#320294
Tested the following packages with and without structuredAttrs:
- rust-analyzer: cargo-build-hook, cargo-check-hook
- jujutsu: cargo-nextest-hook
- kornia-rs: maturin-build-hook
