apparently pandoc has changed behavior over the past releases, so the
files are no longer in sync. occasionally this requires edits
to the markdown source to not remove an anchor that was there
before (albeit wth a very questionable id), or where things were simply
being misrendered due to syntax errors.
we only have three uses at the moment, all of them in code blocks where
they could just as well (or maybe better) be comments. markdown can't do
callouts without another pandoc filter, so we'll turn them into comments
instead.
synapse would've benefited from inline links, but referencing an
external numbered list as plain text (instead of clickable links, like
callout lists had) seems even worse than putting urls into comments as
plain text.
productname, application, acronym, guilabel, and guibutton were so far
not rendered specially and can go away completely.
replaceable does render differently, but since it was only used twice
and in places where the intent should be clear without the extra markup
it can go as well.
makes sure that program listing tags are separated from their contents
by exactly a newline character. this makes the markdown translation
easier to verify (since no new newlines need to be inserted), and
there's no rendering difference anyway.
MD can only do the latter, so change them all over now to keeps diffs reviewable.
this also includes <literal><xref> -> <xref> where options are referenced since
the reference will implicitly add an inner literal tag.
markdown cannot represent those links. remove them all now instead of in
each chapter conversion to keep the diff for each chapter small and more
understandable.
Added the RFC42-style added the posibility to use
`services.dokuwiki.sites.<name>.settings' instead of passing a plain
string to `<name>.extraConfig`. ´<name>.pluginsConfig` now also accepts
structured configuration.
The `snipe-it-setup.service` script exits with an error if the
invalid_barcode.gif already exists at the destination, due to
`set -euo pipefail` at the beginning of the script. This commit
refactors the affected lines so that it no longer causes an error.
Resolves#205791
Upon testing the change itself I realized that it doesn't build properly
because
* the `pname` of a php extension is `php-<name>`, not `<name>`.
* calling the extension `openssl-legacy` resulted in PHP trying to compile
`ext/openssl-legacy` which broke since it doesn't exist:
source root is php-8.1.12
setting SOURCE_DATE_EPOCH to timestamp 1666719000 of file php-8.1.12/win32/wsyslog.c
patching sources
cdToExtensionRootPhase
/nix/store/48mnkga4kh84xyiqwzx8v7iv090i7z66-stdenv-linux/setup: line 1399: cd: ext/openssl-legacy: No such file or directory
I didn't encounter that one before because I was mostly interested in
having a sane behavior for everyone not using this "feature" and the
documentation around this. My findings about the behavior with turning
openssl1.1 on/off are still valid because I tested this on `master` with
manually replacing `openssl` by `openssl_1_1` in `php-packages.nix`.
To work around the issue I had to slightly modify the extension
build-system for PHP:
* The attribute `extensionName` is now relevant to determine the output
paths (e.g. `lib/openssl.so`). This is not a behavioral change for
existing extensions because then `extensionName==name`.
However when specifying `extName` in `php-packages.nix` this value is
overridden and it is made sure that the extension called `extName` NOT
`name` (i.e. `openssl` vs `openssl-legacy`) is built and installed.
The `name` still has to be kept to keep the legacy openssl available
as `php.extensions.openssl-legacy`.
Additionally I implemented a small VM test to check the behavior with
server-side encryption:
* For `stateVersion` below 22.11, OpenSSL 1.1 is used (in `basic.nix`
it's checked that OpenSSL 3 is used). With that the "default"
behavior of the module is checked.
* It is ensured that the PHP interpreter for Nextcloud's php-fpm
actually loads the correct openssl extension.
* It is tested that (encrypted) files remain usable when (temporarily)
installing OpenSSL3 (of course then they're not decryptable, but on a
rollback that should still be possible).
Finally, a few more documentation changes:
* I also mentioned the issue in `nextcloud.xml` to make sure the issue
is at least mentioned in the manual section about Nextcloud. Not too
much detail here, but the relevant option `enableBrokenCiphersForSSE`
is referenced.
* I fixed a few minor wording issues to also give the full context
(we're talking about Nextcloud; we're talking about the PHP extension
**only**; please check if you really need this even though it's
enabled by default).
This is because I felt that sometimes it might be hard to understand
what's going on when e.g. an eval-warning appears without telling where
exactly it comes from.
* s/NextCloud/Nextcloud/g
* `enableBrokenCiphersForSSE` should be enabled by default for any NixOS
installation from before 22.11 to make sure existing installations
don't run into the issue. Not the other way round.
* Update release notes to reflect on that.
* Improve wording of the warning a bit: explain which option to change
to get rid of it.
* Ensure that basic tests w/o `enableBrokenCiphersForSSE` run with
OpenSSL 3.
Not a big deal in most of the cases because wordpress ensures that this
directory exists on its own, but with our twentig customizations that's
actually causing issues.
(cherry picked from commit 3285342bfe5f401dda84c13c834e73154928a61c)
this makes it easier for one to manually administer freshrss.
for example, i can import OPML from the CLI like:
```
$ nix build .#freshrss
$ freshrss FRESHRSS_DATA_PATH=/var/lib/freshrss ./result/cli/import-for-user.php --user admin --file my-opml.opml
```
whereas previously i would have needed to include
`environment.systemPackages = [ php ];` in my system for that to work.
Co-authored-by: Shahar Dawn Or <mightyiampresence@gmail.com>
Co-authored-by: a-kenji <aks.kenji@protonmail.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Ilan Joselevich <personal@ilanjoselevich.com>
Co-authored-by: Shahar Dawn Or <mightyiampresence@gmail.com>
Co-authored-by: Ctem <c@ctem.me>
Co-authored-by: a-kenji <aks.kenji@protonmail.com>
Co-authored-by: Brian Leung <leungbk@posteo.net>
Co-authored-by: Ilan Joselevich <personal@ilanjoselevich.com>
Co-authored-by: Shahar Dawn Or <mightyiampresence@gmail.com>
Co-authored-by: Ctem <c@ctem.me>
Co-authored-by: Ilan Joselevich <personal@ilanjoselevich.com>
Co-authored-by: a-kenji <aks.kenji@protonmail.com>
Co-authored-by: Ctem <c@ctem.me>
Co-authored-by: Brian Leung <leungbk@posteo.net>
Co-authored-by: Shahar Dawn Or <mightyiampresence@gmail.com>
Co-authored-by: Ilan Joselevich <personal@ilanjoselevich.com>
most of these are hidden because they're either part of a submodule that
doesn't have its type rendered (eg because the submodule type is used in
an either type) or because they are explicitly hidden. some of them are
merely hidden from nix-doc-munge by how their option is put together.
conversions were done using https://github.com/pennae/nix-doc-munge
using (probably) rev f34e145 running
nix-doc-munge nixos/**/*.nix
nix-doc-munge --import nixos/**/*.nix
the tool ensures that only changes that could affect the generated
manual *but don't* are committed, other changes require manual review
and are discarded.
there are sufficiently few variable list around, and they are
sufficiently simple, that it doesn't seem helpful to add another
markdown extension for them. rendering differences are small, except in
the tor module: admonitions inside other blocks cannot be made to work
well with mistune (and likely most other markdown processors), so those
had to be shuffled a bit. we also lose paragraph breaks in the list
items due to how we have to render from markdown to docbook, but once we
remove docbook from the pipeline those paragraph breaks will be restored.
mostly no rendering changes. some lists (like simplelist) don't have an
exact translation to markdown, so we use a comma-separated list of
literals instead.
most of the screen tags used in option docs are actually listings of
some sort. nsd had a notable exception where its screen usage was pretty
much a raw markdown block that made most sense to convert into docbook lists.
