Packages built with `haskellPackages.callHackage` won't be rebuilt when
updating `all-cabal-hashes`.
The removed comment was keeping a reference to the `cabal2nix` call,
which itself depends on `all-cabal-hashes`, in order to keep this file
during a garbage collection.
The tradeoff is between:
- The current behavior: a mass rebuild, any change of `all-cabal-hashes`
triggers a rebuild of all the packages built with `callHackage` and
packages which depend on them. This can take hours, and may happen
after a "small" unrelated change (i.e. an user is bumping
`all-cabal-hashes` in order to use a new package from hackage). It
also have global impacts in a project (long rebuild in CI, new entries
in cache, developers need to fetch the new entries, ...). In this
context, `cabal2nix` entries are not garbage collected.
- The new behavior: No mass rebuild, but `cabal2nix` derivations need to
be recomputed after a garbage collection. This is usually fast (a few
seconds by call), linear with the number of calls and should not
happen a lot (i.e. users are not garbage collecting everyday).
See https://github.com/NixOS/nixpkgs/issues/194751 for details.
This also removes automatic enablement/mounting of instance store swap
devices and ext3 filesystems. This behaviour is strongly opinionated
and shouldn't be enabled by default.
The unionfs behaviour never took effect anyway, because the AMI
manifest path only exists for instance store-backed AMIs, which have
not been supported by nixpkgs since
84742e2293 (2019).
Enabling Wayland support by default prevents use of XWayland on Wayland
systems, while correctly falling back to X11 when Wayland is
unavailable in the current session.
With the current packaging many people unnecessarily rely on the
`firefox` attribute, which is suggested by nixos-generate-config, which
in turn makes their Firefox use XWayland, when it shouldn't, which
causes bugs with GNOME on Wayland:
https://discourse.nixos.org/t/firefox-all-black-when-first-launched-after-login/21143
Using the Wayland-enabled Firefox was tested on pure X11 systems by
contributors on the #nix-mozilla:nixos.org room and we are confident
this change will not cause severe regressions.
Even better, people can now toggle `MOZ_ENABLE_WAYLAND=<0|1>` in their
environment to override this decision, should they feel the need to do
so.
The `sparseCheckout` argument allows the user to specify directories or
patterns of files, which Git uses to filter files it should check-out.
Git expects a multi-line string on stdin ("newline-delimited list", see
`git-sparse-checkout(1)`), but within nixpkgs it is more consistent to
use a list of strings instead. The list elements are joined to a
multi-line string only before passing it to the builder script.
A deprecation warning is emitted if a (multi-line) string is passed to
`sparseCheckout`, but for the time being it is still accepted.
The nixos-generate-config command mentioned in the manual fails with error:
nixos-generate-config: no need to specify `/` with `--root`, it is the default
This was introduced in 611b8c4472
(#161034). Now, the command should be called without any arguments.
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.
