`strings.trim` returns a copy of the string with all leading and trailing
whitespace removed.
`strings.trimWith` does the same thing, but calling code can decide
whether to trim the start and/or end of the string.
Those attrs have been renamed and throwing is the best way to show it,
if we only warned then the user would only get an error like this `error: Unsupported sdk: 33`
from `pkgs/top-level/darwin-packages.nix`.
If someone wants to support multiple NixOS versions then they can simply
set both attrs. (`!args ? androidSdkVersion` is for that)
`sdkVer` conflicts with the old `sdkVer`(now `darwinSdkVersion` but that still uses `sdkVer` if set) used by darwin
This shouldn't be an issue but due to `pkgs/development/interpreters/python/cpython/default.nix`
running `lib.filterAttrs (n: v: ! lib.isDerivation v && n != "passthruFun")` on it's inputs (2 of them are darwin only)
the `throw "Unsupported sdk...` in `pkgs/top-level/darwin-packages.nix` will be triggered.
After this change `pkgsCross.armv7a-android-prebuilt.python3.pythonOnBuildForHost` won't fail with
`error: Unsupported sdk: 33`
Issue was bisected to 3cb23cec23
- Bring up to date
- Give meaning to the metavariables
- Use italics for metavariables (just like the Nix manual)
- Don't abbreviate
- No hard feelings, Val.
The old stdenv didn't work, and was also impure. The new one works, and
is pure. Presently, the bootstrap tools are cross compiled into one small
nar and one large tar, which is then unpacked, patched, and split into
smaller derivations. Efforts were made to make the boot process as short
as possible - there are only two clangs built, and as many packages are
propagated between stages as possible while leaving the bootstrap tools
out of the final stdenv's closure.
This is a follow-up to https://github.com/NixOS/nixpkgs/pull/325380 where @emilazy discovered that we have some typos in field names.
This refactoring wraps the implicit lib.licenses schema up in a factory function to ensure consistency.
While a more proper type checker like the one we use for meta checks would be better I didn't want to depend on that in more places.
In fact, we might want to make meta type checks more strict on the license field.
Previously we would fallback to using `kernel` as the `os` which would
result in using the wrong `os` value (`none`) when actually we want
`unknown`. This seems to be a special case for wasm32-unknown-unknown
and wasm64-unknown-unknown so I extended the if statement to support it.
All builtins should be in mirrored in lib, for consistency, as well
as control to let the Nixpkgs pin effect *subtle* improvements in
behavior (such as the foldl' accumulator strictness).
Benefits:
- some lookups happened in the hot path, and will now be slightly faster,
with only a variable lookup and no attribute selection
- it's now harder to accidentally use args.lib aka specialArgs.lib, which
has happened
- shorter
The practical use for this should be very limited because I don't
think anyone should change `lib`, let alone change `lib.functionArgs`,
but, but it would be even stranger to rely on `args.lib` (or really
`specialArgs.lib` for what's clearly a behavior of the current
`evalModules`, which uses its own ambient lib for basically everything.
The shadowing of `lib` by `args.lib` here seems to be a small mistake,
which is easy to make.
Add lib.meta.getLicenseFromSpdxIdOr as a variant of
lib.meta.getLicenseFromSpdxId that explicitly state the default
(fallback) value if there's no license matching the given SPDX ID.
Add a library function to parse and validate an IPv6 address from a
string. It can parse the first two versions of an IPv6 address according
to https://datatracker.ietf.org/doc/html/rfc4291#section-2.2. The third
form "x❌x❌x:x.d.d.d.d" is not yet implemented. Optionally parser can accept prefix length (128 is default).
Add shell script network.sh to test IPv6 parser functionality.
* doc: migrate lib.filesystem to doc-comment format
* defintion list fixes lib/filesystem.nix
Co-authored-by: Daniel Sidhion <DanielSidhion@users.noreply.github.com>
---------
Co-authored-by: Daniel Sidhion <DanielSidhion@users.noreply.github.com>
`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.
Friend came to me with misunderstanding of how this function works.
After discussion we came to the conclusion having an example would have
prevented this.
* Extend libc
Include non-libc core libraries in the libc package. Many of these
mirror libraries present in glibc on linux, such as libgcc, libraries
used for iconv, and libraries used for reading kernel info (libkvm,
libprocstat, libmemstat).
Without this many packages outside the freebsd tree would need to be
modified to include standard dependencies which would already be on
the system for other packages.
* Mark FreeBSD as using LLVM
* Update default LLVM version FreeBSD
* Use patch monolith
The patchesRoot system combined with the fact that each derivation
will Request specific names of patches makes it very annoying to use
other FreeBSD source trees with nixpkgs. This new system allows
providing one Or more entire trees of patches whose contents will be
dynamically Parsed and only the relevant patches will be applied for
any one Derivation.
With this commit, the following knobs are available for specifying the
FreeBSD source:
- overriding `freebsd.versionInfo`, for picking another official
supported FreeBSD release.
- overriding `freebsd.source` for specifying a specific unpatched
FreeBSD source tree.
- overriding `freebsd.patches`, for specifying the patches to apply.
Co-Authored-by: Audrey Dutcher <audrey@rhelmot.io>
Co-Authored-by: John Ericson <John.Ericson@Obsidian.Systems>
The idea behind that is to enable users and developers of
downstream tools such as home-manager to test Nix master for several
reasons:
* Nix is currently trying to have a `master` branch that's always
releasable[1]. We're still on Nix 2.18 in nixpkgs due to too many
notable regressions. Enabling people to test latest master may help on
that end.
* This uses the most bleeding-edge Nix, but our packaging, so we can
identify issues with our packaging early.
* From what I've seen, most people are using the packages from nixpkgs
anyways instead of the upstream flake, this is far more convenient
anyways.
My plan is to update this once a week. Right now we rely on the
`installCheckPhase` here, but as soon as we have proper regression
testing[2], we may want to add `nixUnstable` there as well (however with
failures being allowed probably).
[1] https://discourse.nixos.org/t/nix-release-schedule-and-roadmap/14204
[2] https://github.com/NixOS/nixpkgs/pull/304332
This is all I could find after co-maintaining lib for a long time.
I've had the fortune of basically not really noticing this file,
because it has had very few interactions until the confusion in
https://github.com/NixOS/nixpkgs/pull/304277
It seems to be a state of limbo, which would be nice to resolve
(with great care), but this is not urgent, and first we should
document its status.
