This makes the following work
disabledModules = [ foo.nixosModules.bar ];
even if `bar` is not a path, but rather a module such as
{ key = "/path/to/foo#nixosModules.bar"; config = ...; }
By supporting this, the user will often be able to use the same syntax
for both importing and disabling a module. This is becoming more relevant
because flakes promote the use of attributes to reference modules. Not
all of these modules in flake attributes will be identifiable, but with
the help of a framework such as flake-parts, these attributes can be
guaranteed to be identifiable (by outPath + attribute path).
* k3s: add environmentFile option
Enabling to include secrets through configuration such as 'sops'
* Update nixos/doc/manual/release-notes/rl-2305.section.md
Co-authored-by: Jairo Llopis <973709+yajo@users.noreply.github.com>
Update protonmail-bridge to v3. This also rename the CLI executable from
protonmail-bridge to bridge to be more in line with upstream naming.
Co-authored-by: James Landrein <github@j4m3s.eu>
Signed-off-by: Arthur Outhenin-Chalandre <arthur.outhenin-chalandre@proton.ch>
In general the man pages do not care what OS and manual they are shipped
with, so they don't get to choose the names of them. We were tempted to
do so, as we had inconsistently chosen OS names for the mandoc and
man-db/groff implementations. Since this has been rectified since, we
can just drop this boilerplate from the man pages.
Upstream has officially abandoned the project as of 2021 [0], there's been
no release since 2016, it uses the EoL Qt 4, and alternatives like
KeePassXC exist.
Also move KeePassXC to its own directory -- it doesn't make sense to
have it in KeePassX's folder anymore.
[0]: https://www.keepassx.org/index.html%3Fp=636.html
this reproduces the docbook-generated html manual exactly enough to
appease the compare workflows while we still support both toolchains.
it's also a lot faster than the docbook toolchain, rendering the entire
html manual in about two seconds on this machine (while docbook needs
about 20).
Provide a module to configure Coqui TTS, available as `tts` in nixpkgs
for a few releases already.
The module supports multiple servers in parallel, so multiple languages
and testing scenarios can be covered, without affecting any production
usage.
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.
