We already did this for -march in 12b0e8ac74 ("clang: don't set
-march for overridden target"), but it should have been done for all
machine flags, for the same reason.
Example bug this fixes:
nix-shell -E '
with import ./. {
crossSystem = {
system = "powerpc64le-linux";
gcc.cpu = "power10";
};
};
clangStdenv.mkDerivation { name = "test"; }
' --run '$CC -target wasm32-unknown-unknown -c /dev/null'
Which previously failed with:
clang: error: unsupported option '-mcpu=' for target 'wasm32-unknown-unknown'
This would cause any drv to be rebuilt when any part of the default.nix changes.
What we actually care about is the two JS files though, so simply reference them
directly.
Co-authored-by: Infinidoge <infinidoge@inx.moe>
Switched to a common attribute for library file extensions:
de70971c90
This makes buildRustCrate evaluate successfully when using
pkgsCross/pkgsStatic.
Most Linux distributions are enabling this these days and it does
protect against real world vulnerabilities as demonstrated by
CVE-2018-16864 and CVE-2018-16865.
Fix#53753.
Information on llvm version support gleaned from
6609892a2d68e07da3e5092507a730
Information on gcc version support a lot harder to gather,
but both 32bit and 64bit arm do appear to be supported
based on the test suite.
Before, an unstable version of melpaBuild has to be in MELPA format,
which has some disadvantages:
- existing update scripts cannot be reused[1]
- it causes inconsistence.
This patch fixes that by allowing an unstable version to be in Nix
format.
We heuristically detect if it is an unstable version in Nix format.
If so, we convert it to MELPA format.
This does not bring evaluation performance overhead. Here is my
benchmark result using hyperfine-1.18.0 and nix-2.18.1.
Without this patch:
Benchmark 1: NIXPKGS_ALLOW_BROKEN=1 nix eval --include nixpkgs=$PWD --file . emacs.pkgs.melpaPackages --apply 'pkgSet: map (drv: drv.drvPath) (builtins.filter (p: p.type or null == "derivation") (builtins.attrValues pkgSet))' --no-eval-cache >/dev/null
Time (mean ± σ): 9.126 s ± 0.048 s [User: 6.531 s, System: 0.997 s]
Range (min … max): 9.056 s … 9.186 s 10 runs
With this patch applied:
Benchmark 1: NIXPKGS_ALLOW_BROKEN=1 nix eval --include nixpkgs=$PWD --file . emacs.pkgs.melpaPackages --apply 'pkgSet: map (drv: drv.drvPath) (builtins.filter (p: p.type or null == "derivation") (builtins.attrValues pkgSet))' --no-eval-cache >/dev/null
Time (mean ± σ): 9.124 s ± 0.057 s [User: 6.522 s, System: 1.011 s]
Range (min … max): 9.040 s … 9.220 s 10 runs
[1]: 177c9eddad/pkgs/applications/editors/emacs/elisp-packages/manual-packages/lsp-bridge/default.nix (L93-L108)
Store buildFlagsArray as Bash global array variable instead of
creating/sourcing a file containing its declaration.
buildFlagsArray is short enough, and it is not assigned in a sub-shell.
There's no reason to pass it as a file. Storing it as a variable makes
the build more efficient.
Since moreutils depends on Perl and that causes #315990, drop moreutils
until Perl is fixed to handle cross compiling properly. We now create a
temporary file and write the jq result to it and then copy that to
`$out`.
This change refactors internal hooks used by buildDotnetModule to
support derivations with structured attributes. Note that this changes
variable names that the internal hooks expect.
This reverts commit 7173eb87b8.
Reason for revert: This causes too big a rebuild for master (since GHC
uses srcOnly). This went unnoticed due to a stale ofborg rebuild count.
This matches how the default unpackPhase would copy from a store path
into the build directory, so it seems wise to match this here. On file
systems that support reflinks, this should improve performance as well.
Some packages rely on `uname` to configure the host target which breaks cross-compilation.
We can have more control over the evaluation of `uname` by placing `deterministic-uname` into the package's `nativeBuildInputs`.
However the current `deterministic-uname` is hardcoded to `buildPlatform`.
This PR introduces a build argument `forPlatform` to `deterministic-uname` which allows you to override the platform it reports.
Example:
```nix
deterministic-uname.override { forPlatform = stdenv.hostPlatform; }
```
https://github.com/NixOS/nixpkgs/pull/246164 but for hardlinks.
Mesa, among other packages, has binaries that are linked together and
can end up corrupted when the same binary is stripped through two
different names.
To resolve this, print out the device and inode number before each file
name, sort/uniq based on that, then cut it back out before stripping.
The symlink resolution logic is removed as the same file accessed
through two different links in `$paths` will necessarily have the same
numbers. File/directory within the paths listed in `$paths` are
correctly not (and were never) processed due to the `-type f` predicate
and (implied) `-P` option to `find`.
This change fixes cross-compilation for .NET packages (that are not
using .sln as project files). See relevant comment in the change list
for more details.
In addition to that, it removes dotnet-test-sdk that appears to be
broken, that is, dotnet --list-sdks does not recognize SDKs from PATH,
and when propagated from the check hook it was shadowed by inputs from
preceding hooks.
Note that dotnet-test-sdk used to work when it was introduced in PR
144062, but PR 155257 probably overlooked this case. However, currently
it is not used in Nixpkgs and I think dotnetCorePackages.combinePackages
should cover the intended use case for dotnet-test-sdk.
There should be no reason to use env here:
1. In places where it is used to run dotnet with environment variables,
the same can be done with shell syntax.
For example, `env "FOO=$bar" baz` is equivalent to `FOO="$bar" baz`.
2. Otherwise, it just unnecessarily forces PATH lookup for dotnet
command. In addition to that, some dotnet invocations did not use
env.
--frozen is stricter than we need in Nixpkgs. If a Cargo.lock is
slightly wrong, or (in my use case) if building a subproject that is
not a member of the top-level workspace, but the correct Cargo.lock
can be entirely resolved from the existing top-level Cargo.lock, it
should be deterministic, and shouldn't cause any problems, to let
cargo generate the new Cargo.lock. This should result in less need to
bother upstreams about fixing their Cargo.lock files in cases where
they could have been automatically fixed.
Adding cc to propagatedBuildInputs makes derivations with
makeBinaryWrapper in nativeBuildInputs run the cc-wrapper
setup hook. This isn't an issue for derivations using
stdenv, as the cc setup hook is already run by default.
However, derivations that are made with stdenvNoCC, e.g.
because they're made with runCommand, will not run the
cc-wrapper setup hook without this change.
For some reason the FreeBSD native compiler will not work
correctly without the setup hook.
The $DISPLAY variable has a format of [host]:num[.screen]. Previously,
the number would only be extracted properly if it had the form :num.
Allow all forms but correctly discard the unused parts.
Thanks to Qyriad, it was found out that Nixpkgs was unable to cross
compile when CMake was needed at cross compilation time with Meson
because Meson refuse to use the ambiant CMake.
A simple fix is to always provide the ambiant CMake and trust the
packager to pass the right CMake, otherwise the rest of the build would
probably fail in mysterious ways.
An example of package that required this fix is the Lix, a Nix
implementation, that uses `toml11` discovered via CMake during the Meson
configure phase.
Co-authored-by: Qyriad <qyriad@qyriad.me>
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
This fixes at least one bug with default-features, and also
just aligns us more with what Cargo actually does.
Also some Python style fixes and a bit less mutating state.
Conflicts in luaPackages.luarocks-nix:
- 8b563cd9f9 switched to the new version format (prefixed by 0 since there was no relevant last tag in the branch).
bc4f6fa543 bumped version and switched to the new version format. But the tag used is not part of the branch the commit comes from (master).
Used the new version but replaced the tag prefix with 0.
- b73ec84b9e removed meta (it is already set in the overridden luarocks). But that would cause the update script to try to update the overridden luarocks (as did the previously used old.meta).
bf311d950e modified meta to fix the update script properly.
Kept the meta from the latter since it allows update script to work.
This fixes:
Could not load ICU data. UErrorCode: 2
We're using a hook instead of a wrapper because various things like to
reference the unwrapped dotnet executable.
The underlying goModules derivation must have the same source root as
the overall package. sourceRoot is being propagated already, but
setSourceRoot was not. This was surely an oversight.
This is implemented in such a way that it cannot break existing
vendorHashes unless the package is using setSourceRoot already. If
that's the case, then the package is either broken or found a workaround
to do deal with this very issue (e.g. by using `cd path` in an early
phase).
A simple search (`rg setSourceRoot $(rg -l buildGoModule)`) reveals that
no such packages obviously exist in Nixpkgs.
This was achieved using the following command:
sd 'wrapGAppsHook\b' wrapGAppsHook3 (rg -l 'wrapGAppsHook\b')
And then manually reverted the following changes:
- alias in top-level.nix
- function name in wrap-gapps-hook.sh
- comment in postFixup of at-spi2-core
- comment in gtk4
- comment in preFixup of 1password-gui/linux.nix
- comment in postFixup of qgis/unwrapped-ltr.nix and qgis/unwrapped.nix
- comment in postFixup of telegram-desktop
- comment in postFixup of fwupd
- buildCommand of mongodb-compass
- postFixup of xflux-gui
- comment in a patch in kdePackages.kde-gtk-config and plasma5Packages.kde-gtk-config
- description of programs.sway.wrapperFeatures.gtk NixOS option (manual rebuild)
Closes#267442
$ nix path-info -Sh /nix/store/qj1dm7wfw5m3mxf1gn3fdm0az9y1h5ny-linux-firmware-20240312-xz
/nix/store/qj1dm7wfw5m3mxf1gn3fdm0az9y1h5ny-linux-firmware-20240312-xz 440.3M
$ nix path-info -Sh /nix/store/c3szcjxb3g990dbiz7llwmkaf0bi98j2-linux-firmware-20240312-zstd
/nix/store/c3szcjxb3g990dbiz7llwmkaf0bi98j2-linux-firmware-20240312-zstd 460.6M
This is an increase of 4.4%, but OTOH zstd has a significantly higher
decompression speed[1].
[1] https://gregoryszorc.com/blog/2017/03/07/better-compression-with-zstandard/
Closes#302291Closes#301536
The following things have changed:
* For 5.7+: ZSWAP compressor uses zstd now.
* For 5.11+: ZRAM compressor uses zstd now.
* For 5.13+: kernel modules are compressed with zstd instead of xz.
* For 5.19+: support zstd-compressed firmware.
The modules-closure functionality needed explicit support for copying
over `.zst` files. Also, the VM image builder used busybox's `insmod`
before which doesn't support zstd. Switched to `kmod` and added xz/zstd
as dependencies for it, similar to how it's done for the actual stage1
in d33e52b253. The use of `kmod` here
doesn't seem to be such a big deal since it's only a build-time
dependency.
