Please Nix CI (OfBorg) with empty set instead of null on non-linux platforms,
where NixOS tests are not supported.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Define package `testScriptBin` that contains the substituted test script.
* Add an `installCheckPhase` to check the result script with ShellCheck.
* Passthru as `references.testScriptBin` to run the
(substituted) test script directly (without VM).
* Drop the logic in build script that detects if
it is run in the Nix sandbox.
* Inline sample application; drop invoke-*.nix.
Format expressions.
* Format with `nixpkgs-fmt`.
* Use multi-line style of set patterns.
Call the samples with `callPackage`.
* Rename `sample` -> `samples`.
* Take individual packages / build helpers directly from the
set pattern.
* Define `cleanSamples` to filter out overriders such as `<pkg>.override`.
added by `callPackage`.
Passthru samples and invocation results for easier debugging.
* Passthru samples, references, directReferences
* Provide tests.trivial-builders.writeStringReferencesToFile with such
samples argument.
Fixed conflict in pkgs/applications/graphics/krita/
krita: 5.1.5 -> 5.2.0
7a40fdc288
, and
treewide: use kde mirror everywhere, don't use pname in download urls
aa15f5066d
The previous find invocation didn't match the root directory, so the
root directory's access and modification time wasn't set to a
deterministic value and the build time leaked into the output.
`make-initrd` replaced `cpio` with `bsdtar` in #165892 because the
former includes the number of hardlinks in the created archive, which
depends on the filesystem (and can also be influenced by `nix-store
--optimise`). The same problem applies to `make-initrd-ng`, so this
commit replaces `cpio` with `libarchive`'s `bsdtar`.
-B must be set to the root directory of avrlibc, otherwise gcc cannot
locate crt objects for some attiny devices. -L trains as set by
bintools-wrapper are not necessary with -B set correctly because gcc
takes care of that, and likewise we can drop the -B train from
cc-wrapper because the one spec is enough.
Setting RUSTFLAGS causes Cargo to ignore other ways of configuring
flags, including the target-specific RUSTFLAGS options. This broke
pkgsCross.musl64.crosvm, and was surprising to users.
Fixes: https://github.com/NixOS/nixpkgs/pull/261727
We keep running into situations where we can't get the right
combination of rustc flags through build systems into rustc.
RUSTFLAGS is the only variable supported across build systems, but if
RUSTFLAGS is set, Cargo will ignore all other ways of specifying rustc
flags, including the target-specific ones, which we need to make
dynamic musl builds work. (This is why pkgsCross.musl64.crosvm is
currently broken — it works if you unset separateDebugInfo, which
causes RUSTFLAGS not to be set.)
So, we need to do the same thing we do for C and C++ compilers, and
add a compiler wrapper so we can inject the flags we need, regardless
of the build system.
Currently the wrapper only supports a single mechanism for injecting
flags — the NIX_RUSTFLAGS environment variable. As time goes on,
we'll probably want to add additional features, like target-specific
environment variables.
A handful of kernel modules use glob patterns to express their
firmware dependencies. (`git grep 'MODULE_FIRMWARE.*\*'`)
Previously, we weren't handling these patterns. Now, we are.
Ideally fetch-yarn-deps could do like some other fetchers and support
using SSL_CERT_FILE if it exists and also only verify integrity on FOD
hash unless using an empty/test hash.
But this should keep at least the same semantics as before the recent
Node.js change to stop using the built-in certificate store in favor of
the system one (which does not exist by default in the build sandbox).
Not sure how this ever worked but tar was trying to archive /proc and /sys, which failed to work.
Since this is never useful for containers to do, we exclude this now in the proot case.
Also fakeroot is not needed when proot is used as it provideds the same feature.
We now cleanly seperate those cases as both are kind of hacks and it's more likely
that the combination will just trigger new bugs.
when bubblewraps tries to link all the required files in etc from the
host to the fhs environment, it will re-create the /etc directory.
It will do so with `0700` permissions. This causes permissions issues
with non-root programs when they need to access configuration in the
environment /etc.
By mounting /etc as a tmpfs early, bwrap will make the directory `0755`
as expected.
Some programs (e.g. nvfetcher) parse the output of nix-prefetch-git as
JSON. However, there is a pushd/popd command in nix-prefetch-git that
outputs the directory name, breaking the structure of the result JSON.
We suppressed it with `>/dev/null`.
Passingly fixes a mixuse of tab and spaces.
This script needs to support being run both as part of a `fetchgit`
derivation and as a standalone, command-line tool.
The use of `$NIX_BUILD_TOP` only works when used in `fetchgit` but not when
invoked as a standalone tool. Instead we try to respect `$NETRC` so that
the command-line invocation behaves more like standard tools and the
`fetchgit` derivation can explicitly set `$NETRC` when `netrcPhase` is used
to avoid all ambiguity.
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
Arguably, this is a bug in Nix's structuredAttrs: without
structuredAttrs, exportReferencesGraph with an empty path set would
still result in information being provided. With structuredAttrs, no
info is provided for an empty path set.
Nevertheless, we need to be able to build even if Nix has the bug, so
work around it by checking for an empty path set and handling it
explicitly.
Darwin does not actually require `*.dylib` extension, and some ports of
unix software may still simply compile and install these as `*.so` files.
Include `*.so` in the find in this case.
Co-authored-by: Artturi <Artturin@artturin.com>
Co-authored-by: toonn <toonn@toonn.io>
Rust is not yet able to target the n32 ABI on mips64.
Let's add `isMips64n32` to the `meta.badPlatforms` of all
derivations created by buildRustPackage.
I use this to automatically detect which packages on my system can
be built for n32 (almost all of them) and build those using n32, and
the few packages (mainly those that depend on boost or rust) that
can't for n64.
Rust is not yet able to target the n32 ABI on mips64.
Let's add `isMips64n32` to the `meta.badPlatforms` of all
derivations created by buildRustCrate.
I use this to automatically detect which packages on my system can
be built for n32 (almost all of them) and build those using n32, and
the few packages (mainly those that depend on boost or rust) that
can't for n64.
Before this commit, cc-wrapper/default.nix was using
`isGccArchSupported` to validate `-mtune=` values. This has two
problems:
- On x86, `-mtune=` can take the same values as `-march`, plus two
additional values `generic` and `intel` which are not valid for
`-march`.
- On ARM, `-mtune=` does not take the same values as `-march=`;
instead it takes the same values as `-mcpu`.
This commit fixes these two problems by adding a new
`isGccTuneSupported` function. For `isx86` this returns `true` for
the two special values and otherwise defers to `isGccArchSupported`.
This commit also adds support for `-mtune=` on Aarch64.
Unfortunately on Aarch64, Clang does not accept as wide a variety of
`-mtune=` values as Gcc does. In particular, Clang does not tune
for big.LITTLE mixed-model chips like the very popular RK3399, which
is targeted using `-march=cortex-a72.cortex-a53` in gcc.
To address this problem, this commit also adds a function
`findBestTuneApproximation` which can be used to map
clang-unsupported tunings like `cortex-a72.cortex-a53` to
less-precise tunings like `cortex-a53`.
The work which led to this commit arose because we now have
packages, like `crosvm`, which use *both* `clang` *and* `gcc`.
Previously I had been using `overrideAttrs` to set
`NIX_CFLAGS_COMPILE` on a package-by-package basis based on which
compiler that package used. Since we now have packages which use
*both* compilers, this strategy no longer works.
I briefly considered splitting `NIX_CFLAGS_COMPILE` into
`NIX_CFLAGS_COMPILE_GCC` and `NIX_CFLAGS_COMPILE_CLANG`, but since
`NIX_CFLAGS_COMPILE` is sort of a hack to begin with I figured that
adding the logic to `cc-wrapper` would be preferable.
Cargo will never need to link for the target platform — that'd be for
the package being built to do at runtime. Cargo should know about the
build and host linkers.
This fixes e.g. pkgsCross.musl64.fd from x86_64-linux.
Fixes: 67a4f828b4 ("rust: hooks: fix cross compilation")
This upgrade unfortunately removes MIPS support, as it has been
dropped to Tier 3[1] and so bootstrap tarballs are no longer provided.
It looks like it was dropped due to multiple codegen bugs, and lack of
maintenance, so bringing it back would probably involve engaging with
Rust/LLVM upstream on those.
[1]: https://github.com/rust-lang/compiler-team/issues/648
