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"
```
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
Smoketest fails with
machine # [ 3.785769] systemd[1]: dev-hugepages.mount: Failed to spawn executor: Argument list too long
machine # [ 3.788689] systemd[1]: dev-hugepages.mount: Failed to spawn 'mount' task: Argument list too long
machine # [ 3.790100] systemd[1]: dev-hugepages.mount: Failed with result 'resources'.
machine # [ 3.791572] systemd[1]: Failed to mount Huge Pages File System.
Some GHC bindists have a normal `$out/lib` directory which contains
symlinks to all core libs. Because it is a normal lib directory, the
bintools setup hook will pick up on it and cause ld to pass the
appropriate -L and -rpath flags. We do not want this to happen,
especially in the case of the stage2 compiler. Not only will the final
ghc have an unnecessary reference (and thus increased closure size) to
the binary ghc, but the extra libraries in the rpath mess with the rts
and cause e.g. segfaults in GHCi.
Unfortunately, there is no way to prevent this. It is a fundamental flaw
in the cc and bintools wrappers that they do not actually distinguish
between the roles of dependencies (build, host, target). Instead
the mangleVar* function will translate the dependencies split up by
roles into platforms. This means that the wrappers can't distinguish
between depsBuildBuild and depsHostTarget (== buildInputs) when natively
compiling. As long as we are natively compiling the wrappers will put
the stage0 ghc (be it in depsBuildBuild, nativeBuildInputs etc.) into
the linker flags of the final ghc.
The solution is to sidestep the issue. We just had ghc in depsBuildBuild
to have it added to PATH. GHC itself will pass the appropriate linker
flags if necessary. To avoid the setup hooks picking up on the GHC
libraries we just don't put it into depsBuildBuild or any other
dependency list. Since the GHC build system accepts the GHC binary via
an absolute path, we don't even need to add the stage0 GHC to PATH.
This is marked as broken already because of a Jupyter Notebook upgrade,
and the upstream repository hasn’t been touched in two years,
so there’s little reason to try doing anything about its nose
dependency. Other distributions have already dropped this package;
there’s a patch from an openSUSE maintainer to migrate it off nose,
but they don’t seem to package it any more.
* luarocks-packages-updater: convert into pyproject package
* pluginupdate: move to its own folder
so we can copy just the folder when using this as a module
* luarocks-packages-updater: adress review
* buildNeovimPlugin: pass a derivation to luaAttr
and deprecate passing a string.
Passing a string is not a typical/good nixpkgs habit. We want to give more control on
which attribute to wrap, without having to add it to the lua package set
necessarily.
* vimPlugins: update plugin with new syntax
buildNeovimPlugin now accepts derivations instead of the lua package name. This PR reflects the change
Boto has not seen a release since 2018, and has been officially
marked as deprecated in favour of boto3 and botocore since 2021. It
has required downstream patching to keep it running on newer Python
versions and is broken on the new default of Python 3.12. It also
requires the obsolete nose test framework that we are in the process
of removing.
The few packages we carry that still require boto are in poor upstream
maintenance state and some of those were already broken. The NixOps
AWS plugin was the last holdout that justified keeping this package,
but it is now also broken.
This package has been broken since 24.05 (`pkg_resources` error when
running `toil --help`), and hasn’t built since Python 3.12 became
the default. There have been two major upstream releases since this
package was last updated. I tried to package the newest version, which
drops the boto dependency, but unfortunately it requires obsolete
versions of other Python libraries that we no longer package. Since
it’s been broken for this long anyway and can’t be updated,
let’s drop it for now.
No release in almost half a decade, no maintainer in Nixpkgs, and
the README describes it as obsolete and recommends alternatives:
<978bc1926c/README.rst (obsolescence-notice)>.
No release in four years and depends on the deprecated and broken
boto package; to quote the README:
> ## Where are the maintainers ?
>
> Qubole was acquired. All the maintainers of this repo have moved
> on. Some of the employees founded ClearFeed. Others are at big data
> teams in Microsoft, Amazon et al.
The proton-vpn-network-manager-wireguard and proton-vpn-network-manager-openvpn
modules are now legacy: The same functionality is now in proton-vpn-network-manager
module, version 0.6.3 and upwards.
This commit removes the 2 deprecated modules and creates a throw message for
them to the recommanded package to be used.
The 1.x iteration of globalprotect-openconnect is no longer being
developed. Remove related components from nixpkgs.
Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
Currently, every platform uses LLVM 18 except for the following
exceptions:
* Darwin, on LLVM 16.
* WASM, on LLVM 16.
* Android, on LLVM 12.
As discussed with RossComputerGuy and alyssais on Matrix, we plan to
bump both Darwin and Linux to LLVM 19 after the 24.11 branch‐off,
and try to keep them in sync after that, bumping to new stable LLVM
releases immediately after releases branch off.
This prepares for a 25.05 where `llvmPackages` is a simple
platform‐independent alias by removing all the redundant branches
and upgrading WASM and Android to LLVM 18.
I checked with lilyinstarlight who did the previous LLVM bump for
WASM and she confirmed that there should be no particular reason to
keep it pinned to 16 so long as Firefox continues to compile, and I
have confirmed that it does.
Android was last bumped back when the other platforms
were on LLVM 7, which is pretty good evidence that these
platform‐specific conditionals create unnecessary divergence
and bitrot quickly. Due to the “maximum‐of‐minimums”
cross‐compilation logic, it was inevitably picking LLVM 16 or 18
anyway. `pkgsCross.aarch64-android.hello` fails the exact same way
as it does on `master` on all the platforms I tested (compiler-rt
failing to build on `aarch64-linux` and `x86_64-linux`, and the Linux
headers package expecting `gcc(1)` on `aarch64-darwin`).
I’m not entirely sure that the maximum‐of‐minimums logic is
correct (should it be completely ignoring `buildPlatform` like this?),
but since it will hopefully go away very soon I’ve decided not to
spend more time thinking about it.
The stage0 ghc is build->build since it builds the stage1 compiler which
has build for its host platform (i.e. is build->target relative to the
entire GHC derivation).
Also annotate a bit more around the use of pkgsBuildBuild and the boot
compiler and make it more explicit where it comes from in the
derivation.
In #339272, an elusive regression was found where the stage 2 binaries
held a reference to the boot compiler in their rpath. This issue only
affected GHC 9.6 versions built on aarch64-linux.
For still unknown reason, this issue goes away when using a source built
GHC instead of the binary GHC we derive from upstream's bindists.
Knowing more would be great, obviously, but at least this issue goes
away with GHC 9.8.*…
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
