If the environment provides the variable (as NixOS does when the i18n option is
set), keep it rather than overriding unconditionally.
Fixes https://github.com/NixOS/nixpkgs/issues/354887
Allow customisation of the algorithm used to convert nix references
graph (created from docker image contents) to docker layers.
A collection of building blocks (python functions) is provided, which
use can assembled into a processing pipeline by specifying a list of
operations (and their initial arguments) via a nix list.
Nix references graph if first converted into a python igraph.Graph
object (with each vertex representing a nix path), which is then fed
into the user defined pipeline. Each stage in the pipeline represents a
function call, with initial arguments specified by the user in nix, and
the last argument being the result of the previous stage in the pipeline
(or the initial Graph object). Each step of the pipeline is expected to
produce a data structure consisting of arbitrarily nested lists/dicts
with Graph objects (representing docker layers) at it's leafs. The
result of the last stage in the pipeline is recursively flattened (with
each dict converted into list of values), until a flat list of Graphs
remains. This is then output as a json array of arrays (each Graph
converted into an array of paths).
This functionality is made available via new `layeringPipeline` argument
to the `streamLayeredImage`/`buildLayeredImage` functions. The default
value of the argument has been chosen to to preserve current layering
behaviour.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
We are migrating packages that meet below requirements:
1. using `callPackage`
2. called path is a directory
3. overriding set is empty (`{ }`)
4. not containing path expressions other than relative path (to
makenixpkgs-vet happy)
5. not referenced by nix files outside of the directory, other
than`pkgs/top-level/all-packages.nix`
6. not referencing nix files outside of the directory
7. not referencing `default.nix` (since it's changed to `package.nix`)
8. `outPath` doesn't change after migration
The tool is here: https://github.com/Aleksanaa/by-name-migrate.
This replaces the mess of buildEnvs with a single Rust binary that
spits out a mostly-complete root filesystem for an fhsenv.
The main goal is to have includeClosures, as we want all of the
dependencies to be in the fhsenv to avoid Steam's (and others')
LD_LIBRARY_PATH shenanigans, but without 32-bit libraries leaking
into lib64 when a 64-bit package like mangohud depends on a 32-bit
version of itself.
We "fix" this by actually looking at the files and explicitly moving
32-bit stuff to $out/lib32. This could be avoided if we had recursive
Nix, or at least system info in exportReferencesGraph, but alas.
For some reason this also shrinks the fhsenvs massively, even though
there's currently no layout optimization (e.g. a package with paths
like lib/foo/{bar,baz} will produce two symlinks in the output, even
when it's more optimal to symlink lib/foo to $out/lib/foo directly).
Originally, we switched to bsdtar from libarchive to solve a reproducibility issue related to hardlinks
As of gnu cpio 2.14 the --ignore-dirnlink option is introduced and now included in --reproducible, which solves this issue
By switching back, we are in turn solving an issue in libarchive >=3.7.5 erroring out with "Error reading archive -: (null)"
Change-Id: Ib6140d599b6547d8e941b0251ce996e303c41fa6
514b00cf08 exposed another bug in the
existing wrapper logic: Darwin SDK variables are only exported by
the SDK package hook, so if those variables aren’t already exported
inside the wrappers, the modified versions are not passed down to the
compiler tools, breaking the fallback SDK logic. This was previously
partially masked by passing down a normally‐redundant `-isysroot`
to the compiler, but now we fix it at the source.
This broke e.g. running `clang(1)` without any environment, something
the GHC binary package `installCheckPhase` does indirectly to verify
that there’s nothing missing from the wrapped GHC `$PATH`. It may
also have caused issues building for the build platform inside a
Darwin‐to‐non‐Darwin cross‐compilation build.
`-L` and `-I` are interpreted relative to the `$SDKROOT` by the
Darwin toolchain, so we have to avoid filtering out such paths in the
purity filter hacks in order to not break e.g. the .NET Core build
system. It’s also just the correct thing to do for the platform.
This reduces code duplication, makes the SDK variables available
earlier in the wrappers, and makes the behaviour between the two
wrappers more consistent.
This is basically harmless for the same reason as it is for Clang, and
lets us avoid doing wrapper hacks to fix things like the .NET build.
This reverts commit 4340a5addb.
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`
