Closes#198646
* The options `password`/`basicAuthPassword` were removed for
datasources in Grafana 9. The only option to declare them now is to use
`secureJsonData`.
* Fix description for contactPoints provisioning: when using file/env
providers, nothing will be leaked into the store.
* Fix regex in file-provider usage check: it's also possible to either
use `$__env{FOO}` or `$FOO` to fetch secrets from the environment.
* Fix warning for datasources: `password`/`basicAuthPassword` was
removed, also check for each setting in `secureJsonData` if
env/file-provider was used (then no warning is needed!).
The hack with `either` had the side-effect that the sub-options of the
submodule didn't appear in the manual. I decided to remove this because
the "migration" isn't that hard, you just need to fix some module
declarations.
However, `mkRenamedOptionModule` wouldn't work here because it'd create
a "virtual" option for the deprecated path (i.e.
`services.grafana.provision.{datasources,dashboards}`), but that's the
already a new option, i.e. the submodule for the new stuff.
To make sure that you still get errors, I implemented a small hack using
`coercedTo` which throws an error if a list is specified (as it would be
done on 22.05) which explains what to do instead to make the migration
easier.
Also, I linkified the options in the manual now to make it easier to
navigate between those.
GTK 4 applications use accessibility bus directly
and will try to connect to it every time a widget is created:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4831
This will make GTK 4 apps (e.g. newly ported Nautilus) grind
to a halt on systems that do not have AT-SPI service installed.
Let’s explicitly disable accessibility support with an environment
variable when the AT-SPI service is not enabled to avoid that.
Just like we do for ATK-based applications with `NO_AT_BRIDGE`.
Fixes: https://github.com/NixOS/nixpkgs/issues/197188
- Do not use `daemon`, it has been synonymous to `out` since 783c40eb68
- Do not use explicit `out` output, it has been default since a17216af4c (originally introduced in 2132c86c45)
This commit fixes broken non-declarative configs by
making the assertions more relaxed.
It also allows to remove the forced configuration merge by making
`settings` `null`able (now the default).
Both cases (trivial non-declarative config and `null`able config) are
verified with additional tests.
Fixes#198665
Relative paths are interpreted relative to the working directory, which
is currently unset and thus defaults to `/`. However we want to change
the working directory in a future release such that relative paths are
interpreted relative to `/var/lib/syncthing`.
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.
