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.
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"
```
Always specify the postPhases attribute as a list instead of a string.
Append elements to the postPhases Bash variable using appendToVar
instead of string or Bash array concatenation.
Always specify the preConfigurePhases attribute as a list instead of a
string.
Append elements to the preConfigurePhases Bash variable using
appendToVar instead of string or Bash array concatenation.
Always specify the prePhases attribute as a list instead of a string.
Append elements to the prePhases Bash variable using appendToVar
instead of string or Bash array concatenation.
The previously used pattern was introduced in #318614, but technically
leaked the default flags into the global scope. While this would
probably not make much of a practical difference, making concatTo
support default values is a much cleaner approach.
* autoPatchelfHook: add keep_libc flag
- Add keep_libc flag to disable the default libc handling. Intended
to be used by systemd.
- Add autoPatchelfFlags to autoPatchelfHook for passing arguments to
the autoPatchelf script
This reverts part of the change made in #307068 / 80be926.
Fixes#332533
'command -v builtin' returns 'builtin', which doesn't suit us since
we're looking for program in the given PATH. This could give us shebangs
like this:
#!builtin
which is surprising.
Switch to 'type -P command' which always returns a path, even if command
is both a builtin and an executable (for example 'test'), or fail is
'command' is just a builtin.
There's no point generating debug info if the compiler immediately
strips it before we get a chance to do anything with it.
This is especially important since Cargo 1.77, which asks rustc to
strip by default.
Without the change `updateSourceDateEpoch` fails on tarballs like
`diffoscope-269` that contain single top-level `-269` root as:
diffoscope> source root is -269
diffoscope> find: unknown predicate `-269'
diffoscope> chmod: invalid mode: ‘-269’
diffoscope> Try 'chmod --help' for more information.
Currently `diffoscope-269` has a `sourceRoot = "./-269";` workaround to
bypass the failure.
Co-authored-by: Philip Taron <philip.taron@gmail.com>
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`.
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.
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)
This was added in d83e9c9573,
but included substitution variables `@blas@` and `@lapack@` that were
never substituted. It's not used anywhere in `nixpkgs`.
The way we build python environments is subtly broken. A python
environment should be semantically identical to a vanilla Python
installation in, say, /usr/local. The current implementation, however,
differs in two important ways. The first is that it's impossible to use
python packages from the environment in python virtual environments. The
second is that the nix-generated environment appears to be a venv, but
it's not.
This commit changes the way python environments are built:
* When generating wrappers for python executables, we inherit argv[0]
from the wrapper. This causes python to initialize its configuration
in the environment with all the correct paths.
* We remove the sitecustomize.py file from the base python package.
This file was used tweak the python configuration after it was
incorrectly initialized. That's no longer necessary.
The end result is that python environments no longer appear to be venvs,
and behave more like a vanilla python installation. In addition it's
possible to create a venv using an environment and use packages from
both the environment and the venv.
