Qt links against GTK to be able to use native GTK file chooser
in GTK-oriented DEs. However, GTK expects a specific environment,
which means the application needs to be wrapped to prevent crashes
when file chooser is opened in some environments.
This patch bypasses the need for wrapping Qt applications with GTK-related
environment since the file chooser dialogue will now come from a separate
process (instantiated by the XDG desktop portal via D-Bus).
In the future, we could remove the GTK dependency from Qt to fix the crashes
on non-{GNOME,Pantheon} environments. Then, users would be able to choose
between non-native Qt dialogue or native one facilitated by XDG portals
(e.g. through setting `QT_QPA_PLATFORMTHEME` to either `qgnomeplatform`,
or `xdgdesktopportal`).
One disadvantage is adding a Qt dependency to GNOME, even for people
who might not use any Qt apps. But they can easily just add `qt5.enable = false;`
to their NixOS configuration.
The configuration is also presumably less battle tested than plain Qt
with its first-party GTK integration. But it is backed by Fedora
and used by Manjaro GNOME so it cannot be that bad.
Lastly, I worry about ABI compatibility of the platform modules
with apps installed from different Nixpkgs revision.
The way `(lib.formats.yaml {}).generate` generates YAML is compliant
because on YAML 1.2 spec JSON is a subset of YAML but it bugs people's
minds and can lead to problems with software that is not compatible with
YAML 1.2.
This commit also changes the test of the generation function. Data
validation/typing remains the same.
See #133802.
Signed-off-by: lucasew <lucas59356@gmail.com>
Recommend to use services.xserver.dpi option instead. Mention in the
documentation that it's a sledgehammer approach and monitor settings should be
used instead.
Also don't set DPI in fontconfig settings; fontconfig should use Xft settings
by default so let's not override one value in multiple places. For example,
user now can set DPI via ~/.Xresources properly.
The problem behind this is that the hardened patchset[1]. Quite recently
this led to a weird problem when Linux 5.12 was dropped (and thus had to
be removed from `nixpkgs`), there were no patches for 5.13, so
`linuxPackages_hardened_latest` had to be downgraded to 5.10 as base[2]
which may be rather unintuitive and unexpected.
To avoid these kind of "silent downgrades" in the future, it makes sense
to drop the attribute entirely. If somebody wants to use a hardened
kernel, it's better to explicitly pin it using the newly introduced
versioned attributes, e.g. `linuxPackages_4_14_hardened`.
[1] https://github.com/anthraxx/linux-hardened/
[2] https://github.com/NixOS/nixpkgs/pull/133587
The wpa_supplicant service in the NixOS installer is unusable because
the control socket is disabled and /etc/wpa_supplicant.conf ignored.
The manual currently recommends manually starting the daemon and using
wpa_passphrase, but this requires figuring out the interface name,
driver and only works for WPA2 personal networks.
By enabling the control socket, instead, a user can configure the
network via wpa_cli (or wpa_gui in the graphical installer), which
support more advanced network configurations.
The paperless project has moved on to paperless-ng and the original
paperless package in Nixpkgs has stopped working recently (due to
version incompatibility with the providede Django package).
Instead of investing more time into the old module we should migrate all
users to the new module instead.
Some ACME providers (like Buypass) are using a different certificate
to sign OCSP responses than for server certificates. Therefore,
sslTrustedCertificate should be provided by the user and we need to
allow that.
* Previously, both the xorg and wayland backend were built into the yambar
package. The refactor breaks up each backends to its separate, with xorg
being the default. Thus yambar users on wayland should switch to the
yambar-wayland package.
For security reasons, and generally, it is best to create a more fine
grained group than plugdev. This way users that wish to tweak razer
devices don't have access to the entire plugdev group's permissions.
This is of course a breaking change.
Previously the driver was configured exclusively through convoluted
environment variables.
Now the driver's defaults are configured through env variables.
Some additional concerns are in the github comments of this PR.
Jos van Bakel