options processing is pretty slow right now, mostly because the
markdown-it-py parser is pure python (and with performance
pessimizations at that). options parsing *is* embarassingly parallel
though, so we can just fork out all the work to worker processes and
collect the results.
multiprocessing probably has a greater benefit on linux than on darwin
since the worker spawning method darwin uses is less efficient than
fork() on linux. this hasn't been tested on darwin, only on linux, but
if anything darwin will be faster with its preferred method.
Since 1.2.0, kanata handles missing keyboards well:
- only one keyboard need to be present when kanata starts;
- if linux-continue-if-no-devs-found is set to yes, all keyboards can
be missing at the beginning;
- all keyboards can be (un)pluged when kanata is running.
For simplicity, linux-continue-if-no-devs-found is set to yes and
systemd patch activation is removed.
using readFile instead of fileContents (or using indented strings) can
leave a trailing newline that causes build errors in systemd units and
has previously caused runtime errors in wireguard scripts. use
singleLineStr to strip a trailing newline if it exists, and to fail if
more than one is present.
...but still allow for setting `dataDir` to a custom path. This gets
rid of the use of the deprecated option PermissionsStartOnly. Also, add
the ability to customize user and group, since that could be useful
with a custom `dataDir`.
trying to get all of the podman functionality to work with the wrapper
is becoming more complicated with each release, it isn't sustainable
removing the wrapper does mean that using extraPackages will need to build from source
- include pkgs.zfs by default in the wrapped podman used by the module so it is cached
- anyone using zfsUnstable will need to build from source
- remove unnecessary serviceConfig overrides
- set HELPER_BINARIES_DIR during build
- use install.bin target on linux for podman/tmpfiles
- also installs quadlet/rootlessport in libexec
- remove unnecessary rootlessport output
- remove unnecessary substituteInPlace
these files provided mainly or exclusively xml-related tooling and
support for editing the manual. since docbook is now an implementation
detail (except for still being allowed in option docs, for now) these
tools are no longer necessary, useful, or even functional.
xmlformat.conf is still used by the nixpkgs documentation, so we have to
keep it. there's no reason it can't go live with the nixpkgs docs though.
this adds support for structural includes to nixos-render-docs.
structural includes provide a way to denote the (sub)structure of the
nixos manual in the markdown source files, very similar to how we used
literal docbook blocks before, and are processed by nixos-render-docs
without involvement of xml tooling. this will ultimately allow us to
emit the nixos manual in other formats as well, e.g. html, without going
through docbook at all.
alternatives to this source layout were also considered:
a parallel structure using e.g. toml files that describe the document
tree and links to each part is possible, but much more complicated to
implement than the solution chosen here and makes it harder to follow
which files have what substructure. it also makes it much harder to
include a substructure in the middle of a file.
much the same goes for command-line arguments to the converter, only
that command-lined arguments are even harder to specify correctly and
cannot be reasonably pulled together from many places without involving
another layer of tooling. cli arguments would also mean that the manual
structure would be fixed in default.nix, which is also not ideal.
- inline copySources into single user
- remove `inherit sources` where it's not necessary
- inline generatedSources. this will go away completely soon so we may
as well.
- inline modulesDoc into manual-combined. this too will go away soon.
- inline sources into manual-combined. this too will go away soon.
once we generate the entire manual-combined.xml with a single
nixos-render-docs invocation we will no longer need any options xml
files. likewise we do not need the test options xml in the manpage
build. splitting manpages-combined from manual-combined also allows
these two to run in parallel, slightly improving build times.
man-configuration.xml is the only manpage we build using docbook at this
time, and man-pages.xml includes just this one file. inline
man-configuration.nix into man-pages.xml so we can refer to a single
file to grab the manpage sources later rather than using find-by-suffix.
Issue: after installing, running `yubikey-agent -setup` produces the
following error:
```
nixOS: Failed to connect to the YubiKey: connecting to pscs: the Smart
card resource manager is not running
```
More on this issue: https://github.com/FiloSottile/yubikey-agent/issues/137
Since https://github.com/NixOS/nixpkgs/issues/213943 got fixed, only the main k3s derivation is tested.
Here I changed the tests a bit to make them test all provided k3s derivations
@moduon MT-1718
render all manual chapters to docbook from scratch every time the manual
is built. nixos-render-docs is quick enough at this to not worry about
the cost (needing only about a second), and it means we can remove
md-to-db.sh in the next commit.
no changes to the rendered html manual except for replacements and smartquotes.
we'll soon add another docbook converter that does not emit a section as
a collection of chapters, but sections or chapters on their own. this
should clarify naming a bit before there can be any confusion.
since support for kbd elements was added with explicit intent in #175128
it seems like a good idea to support this in nixos-render-docs instead
of just dropping it in favor of `*F12*` etc. since it's a very rare
thing in the manual and purely presentational it makes sense to use
bracketed spans instead of a new myst role.
the html-elements.lua plugin is now somewhat misnamed, but it'll go away
very soon so we don't want to bother renaming it.
this is a lot easier than adding footnote support for just the one
instance. if a use case for footnotes appears in the future (e.g. if we
wanted to render the nixpkgs manual with nixos-render-docs as well) this
decision should be reevaluated.
nixos-render-docs supports inline anchors, but not ids for blocks. it
seems wise to reserve blocks for special cases that don't have other
syntax already, like admonitions.
pandoc drops .title classes when rendering to docbook, so these are
effectively just paragraphs anyway. without support for including them
in a table of contents the complexity of parsing them in
nixos-render-docs won't be warranted.
