A free-form `attrsOf str` option that is merged with the /etc/os-release
builder, allowing downstreams to customise arbitrary os-release fields.
This is separate from the variant option, as using an attribute set
merge means one gets an infinte recursion when making extraOSReleaseArgs
a recursive set, and the variant attribute is useful to define elsewhere
or multiple times.
Ditto for /etc/lsb-release.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
It's almost 2025; we don't need to use 3-bit colour anymore. Let's use
the proper colour code for NixOS' light blue:
ea1384e183/logo/README.md (colours)
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
The assertion message should include the `nixpkgs.config` value, however
it currently includes the entire `nixpkgs.config` _option_.
This means the type, declarations, definitions, etc were all printed.
This package was marked as vulnerable in
<https://github.com/NixOS/nixpkgs/pull/255959>, almost a year ago and
over a year after the project was archived upstream. The package and
module are unusable without bypassing a security warning in 23.05,
23.11, and 24.05.
Given that the package is intended as an organizer for
potentially‐untrusted media files, the vulnerability is critical and
leads to remote code execution, and there is basically no prospect
of upstream releasing a fix, remove the package and module entirely
for 24.11.
This constraints aren't super useful because they arent really enforced
by the software, so it's hard to get them right and we've gotten them
wrong multiple times in the past. It's better to remove them altogether
in the spirit of RFC 42.
Add '~' and '^' to the supported characters for the field. These
characters are needed to be able to define all versions that are
compatible with the UAPI Version Format specification.
One example where this is used is the `%A` flag in systemd.unit. If we
don't allow these other characters, we for example cannot declare a
pre-relase version.
systemd, as far as I can tell, doesn't enforce any restrictions on the
os-release fields.
https://uapi-group.org/specifications/specs/version_format_specification/
This change makes `baseOptionsJSON` (`lazy-option.json`) take
our existing `documentation.nixos.options.warningsAreErrors` option into
account to then set the `NIX_ABORT_ON_WARN` environment variable within
its build sandbox accordingly.
Given `documentation.nixos.options.warningsAreErrors` default to true,
our nixpkgs CI check that builds the NixOS manual for each PR, will now
fail when something raises a warning, e.g. as part of the `lib.mdDoc`
deprecation.
This should prevent new PRs with lib.mdDoc from getting merged.
Previously, the manual would build successfully, even if an eval warning
was raised.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
Since the output of `lib.systems.elaborate` contains functions, an
equality check with `==` does not suffice, `lib.systems.equals` should
be used instead.
Currently there are a bunch of really wacky hacks required to get nixpkgs
path correctly set up under flake configs such that `nix run
nixpkgs#hello` and `nix run -f '<nixpkgs>' hello` hit the nixpkgs that
the system was built with. In particular you have to use specialArgs or
an anonymous module, and everyone has to include this hack in their
own configs.
We can do this for users automatically.
I have tested these manually with a basic config; I don't know if it is
even possible to write a nixos test for it since you can't really get a
string-with-context to yourself unless you are in a flake context.
