markdown can't represent the difference without another extension and
both the html manual and the manpage render them the same, so keeping the
distinction is not very useful on its own. with the distinction removed
we can automatically convert many options that use <code> tags to markdown.
the manpage remains unchanged, html manual does not render
differently (but class names on code tags do change from "code" to "literal").
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
The ${opt.*} syntax will print the full path when NixOS is used
as a submodule.
nixpkgs.system / nixpkgs.localSystem must not be read by any
other module because its meaning is ambiguous in cross vs
non-cross contexts. hostPlatform is generally what you need.
*Where* you build something generally doesn't matter in a
system _configuration_ context like NixOS.
Riak have been updated a lot since the version 2.2 (now 3.0.10) but
has seen no updated to the package. This is at this point
a problem forcing us to maintain old versions of erlang.
We would be happy to re accept a newer version of Riak if someone want
to spend the time to set it up.
- initialSystem was keeping track of the evaluating system
- it had been used by `nesting.children`
- since, 20.09, `nesting.children` has been replaced with named
specializations
It appears that this option was left over and not cleand up properly.
It doesn't make sense to have a default value for this that's
incompatible with the default locate implementation. It means that
just doing services.locate.enable = true; generates a warning, even if
you don't care about pruning anything. So only use the default prune
list if the locate implementation supports it (i.e., isn't findutils).
Addresses #16545. Allows for user defined environment variables that
hold paths to wordlists. This is to allow for easy access to wordlists
for users and scripts, (in other distributions a convenient wordlist is
typically found in /usr/share/dict/words or similar). The default
wordlist is the one found in scowl, for no other reason than that's the
one that was mentioned in the linked issue.
It is possible to specify multiple environment variables as well. This
is for users who need multiple wordlists (such as multilingual users).
Still actively developed and yet stuck on python2. Also marked as
vulnerable and their issue tracker contains yet another security issue
reported in 2021/10 that the upstream hasn't acknowledged yet.
Mind blown.
Closes: #135543, #97274, #97275
a few things should've used buildPackages/nativeBuildInputs to not not require
the host architecture for building docs. tested by building aarch64-linux docs
on x86_64-linux, and the result looks good.
