- Used `stdenvNoLibc` directly in the package files instead of
overriding `stdenv` to it in `all-packages.nix`
- Moved applicable libcs to `pkgs/by-name` (note: not newlib because
it's also accessible via `newlib-nano`)
Before this change, if you used an overlay to override the version of
resholve that Nixpkgs uses, then Nixpkgs would sometimes use the new
version of resholve and sometimes use the previous version of resholve.
Specifically, pkgs.resholve would use the new version of resholve and
pkgs.resholve.writeScriptBin would use the previous version of resholve.
This change makes it so that if an overlay replaces pkgs.resholve, then
pkgs.resholve and pkgs.resholve.writeScriptBin will still use the same
version of resholve.
Fixes#418458.
If a Python package does not come with either `format` or `pyproject` we
consider it a setuptools build, that calls `setup.py` directly, which is
deprecated.
This change, as a first step, migrates a large chunk of these packages to
set setuptools as their explicit format
This is so we can unify the problem space for the next step of the
migration.
This reverts commit 65a333600d.
This wasn't tested for correctness with something like fodwatch [0],
and should not have been (self-)merged so quickly, especially without
further review.
It also resulted in the breakage of at least one package [1] (and that's
the one we know of and was caught).
A few packages that were updated in between this commit and this revert
were not reverted back to using `rev`, but other than that, this is a
1:1 revert.
[0]: https://codeberg.org/raphaelr/fodwatch
[1]: https://github.com/NixOS/nixpkgs/pull/396904 / 758551e458
These have been broken for a long time and are severly outdated. I'm
taking the lack of maintenance as a lack of interest and dropping
these. It may be better to start from scratch anyways when packaging
a newer version of hasura (they have added 9.10 support, so there's
no reason it couldn't be resurrected in theory).
From experience, Hasura is a huge can of worms and I'm personally not
interested in maintaining it. I've tried to get the ball rolling
again in the past (https://github.com/NixOS/nixpkgs/pull/250035)
which also didn't garner any interest.
I was trying to get an embedded RISC-V toolchain working, by
following pretty much a documented workflow:
```
pkgsCross = import pkgs.path {
localSystem = pkgs.stdenv.buildPlatform.system;
crossSystem = {
config = "riscv32-none-elf";
libc = "newlib-nano";
gcc.arch = "rv32im";
};
};
```
This is supposed to work for compiling programs that target
"bare-metal". But when I tried to compile my project, GCC complained
that it can't fild `-lgloss`. If you're curious what libgloss is, in
very simple terms it's a glue layer that allows you to provide
implementation for the bare minimum functionality that would get the
rest of the libc working. (such as `_sbrk`, `_open`, `_read` and
friends).
After digging into it for a while, I've figured out that newlib which
is shipped by nixpkgs doesn't contain libgloss as part of the build
resuts. So this isn't just me misconfiguring the search paths.
You may be wondering - why didn't anyone else find this issue? My
current guess is that nobody really uses this combination (newlib-nano
plus a bare-metal deployment). Most people who use the cross
toolchains likely target an operating system which provides syscalls
already and don't implement the stubs themselves.
If you really want to try and reproduce the bug, you need to pass this
as a flag to gcc: `--specs=nano.specs`.
Also, this bug is not really specific to NixOS, but happened in
ArchLinux as well. Here's a relevant bug report:
https://bugs.archlinux.org/task/66548. This is where I've found the
fix. Adding the fix in the way I did seems to fix the problem for
good.
The fix itself doesn't seem to be dangerous because in case libgloss
is absent, it would be skipped and not copied to the build results.
NB: during review it's been also suggested to add libm for the same
reasons, so this is what I did as well.
This update allows newlib to compile with GCC 14, which in turn fixes
the cross-compilers which use newlib for their libc (for example,
`pkgsCross.riscv64-embedded.buildPackages.gcc`).
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build https://github.com/infinisil/treewide-nixpkgs-reformat-script/archive/a08b3a4d199c6124ac5b36a889d9099b4383463f.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
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.
sed -i 's/ webkitgtk\b/ webkitgtk_4_0/g' pkgs/**.nix
sed -i 's/(webkitgtk\b/(webkitgtk_4_0/g' pkgs/**.nix
sed -i 's/\.webkitgtk\b/.webkitgtk_4_0/g' pkgs/**.nix
webkitgtk is currently pointing to that specific ABI version but the
alias is going to start warning
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"
```
Robert Hensing