`rustc.config` is called `rust.rustcTarget` now, and
`{rustc -> rust}.platform`.
This is the new way (tm), and is preferred since
https://github.com/NixOS/nixpkgs/pull/271707 -
though the documentation still is outdated, and some expressions in
nixpkgs were using the old interface.
This updates both.
linuxManualConfig involves more boilerplate to change the kernel. Use
the wrapper linuxPackages_custom which is wrapper that takes an
attribute sets and calls linuxManualConfig approrpriately.
This is much easier for beginners to use instead of linuxManualConfig
helper.
Point to linuxManualConfig for further customizations.
* doc: add stdenv passthru chapter
Broad strokes:
- create the chapter
- move existing stdenv passthru coverage into it
- move out-of-place coverage of passthru.tests from the stdenv meta chapter into it
- (try to) apply 1-sentence-per-line to text I've touched
- add legacy anchors for everything moved
- update existing links to the new anchors
- add tentative motivating text
- make nixpkgs-internal links relative/branchless
razor: if it is only ever needed by contributors, which is likely if links
refer to the latest revision of the source code, then it's for
the contributor guide
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Context:
@FlafyDev: I think flutter apps in nixpkgs should be required to specify
a flutter version. like flutter319 and flutter322 instead of using
flutter.
https://github.com/NixOS/nixpkgs/pull/313711
This makes `justStaticExecutables` error if the produced store path
contains references to GHC. This is almost always erroneous and due to
the generated `Paths_*` module being imported. This helps prevent
`justStaticExecutables` from producing binaries with closure sizes in
the gigabytes.
See: https://github.com/NixOS/nixpkgs/issues/164630
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
* doc: autogenerate python interpreter table
This serves as a practical example on generating documentation by
inspection of the evaluated Nixpkgs tree.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
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.
These flags are not part of waf, they're custom flags that are not
widely implemented. More packages are broken because of these flags
being added than actually recognise them.
Of the packages in Nixpkgs that directly depend on wafHook that we can
attempt to cross compile (i.e. all their dependencies cross compile),
5 already successfully cross compile and recognise these flags, 2
already successfully cross compile because they have been opted out of
these flags, 3 don't cross compile successfully for reasons unrelated
to these flags, and for the remaining 7, the only thing stopping them
cross compiling successfully is that they are being passed these flags
that they don't recognise.
All of the five successfully cross-compiling packages that do
recognise these flags are samba projects: ldb, talloc, tdb, tevent,
and samba4. So this isn't a general waf convention, just a samba one.
It therefore doesn't make sense to set these flags by default. They
should just be included in the expressions for each samba project,
like all the other quirks common to samba build systems.
This change fixes cross compilation of the following packages:
blockhash ganv ndn-cxx mda_lv2 pflask raul saldl
Fixes#256769
Repro + test of fix here: https://gitlab.com/ramirez7/bug-repros/-/merge_requests/1
Adds a `srcModifier` argument to `callCabal2nixWithOptions` to allow
customizing the source files used to generate the cabal file (e.g. to
support `hpack`/`package.yaml`).
This upgrades the default version of zig to zig_0_12, which builds
reproducibly on darwin.
Fixes#299091.
Also upgrades all packages compatible with zig 0.12 to that version.
I tried to upgrade packages currently pinning 0.11 as well, but only a
few worked.
Co-authored-by: Weijia Wang (wegank) <contact@weijia.wang>
In the past I was very active with Python packaging.
For several years now I was hardly around as maintainer,
so it does not make sense I am listed as a maintainer for
these makes. Looking back, I should have removed myself
as maintainer already much longer ago. Anyway, better late
than never.
It's been a fun ride, and I do intend to occasionally contribute
to Nixpkgs, but not in the same way it once was.
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)
There appears to be no clear reason why docbook should be referenced here,
except perhaps for historical reasons from when the manual still used
docbook.
that NixOS manual section talks a lot about Nixpkgs package
configuration, which really should not be there but rather in the
Nixpkgs manual itself. but this is a rabbit hole for another time.
Co-authored-by: Dominic Mills <dominic.millz27@gmail.com>
* doc: improve fetchers overview, deduplicate readme content
* Improve caveat explanation and some fetchurl content
* move out consumer docs on source fetching
* move note on mirror URLs to the relevant section
this may be better suited for the `fetchurl` reference, but it's probably better to
just render that information into the manual. for now, because
- contributor documentation encourages mirrors
- we can expect contributors to dig into the source
- linking source files is trivial in in-code documentation
we leave it there.
* move instructions for updating hashes to the manual
* Add more clarity on text, reorganise source hash methods
---------
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Dominic Mills-Howell <dominic.millz27@gmail.com>
Co-authored-by: lolbinarycat <dogedoge61+github@gmail.com>
