I initially thought it was related to /var/lib/nixos/{gid-map,uid-map},
but it seems that to migrate GID/UID you have to edit
/etc/{group,passwd} (and update GID/UID in all files). So mention those
files in the warning messages.
We do not really declare module dependencies anywhere else and it would
a nousance to move any file if many other referenced it without being
necessary. Also most higher level modules depend on most of the lower
level ones.
So removing this because it can only potentially cause weird issues.
GL was already participially disabled because X11 is disabled and lead to
the following error when building gst-plguins-good:
```
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency gstreamer-gl-prototypes-1.0 found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency gstreamer-gl-prototypes-1.0
meson.build:328:2: ERROR: Neither a subproject directory nor a gst-plugins-base.wrap file was found.
```
Without the change non-default configs like:
fonts.fontconfig.subpixel.rgba = "rgb"
fail to build the system as:
fontconfig-conf> ln: failed to create symbolic link 'dst/': No such file or directory
fontconfig before version 2.13.1 was apparently implicitly not using
subpixel antialiasing. The fontconfig NixOS module deviated from this,
using subpixel antialiasing with `rgb` layout by default. In fontconfig
2.14.1, subpixel antialiasing was inadvertently enabled as the default:
2b6afa02ab
According to https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/337,
that deviates from GNOME/GTK’s defaults, which resulted in apps taking the
settings directly from fontconfig (e.g. Firefox) from diverging from GNOME
programs.
The change was subsequently reverted in 2.14.2, choosing the greyscale
antialiasing explicitly: 030759b74f
Let’s reflect this default setting in the NixOS module.
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
`sub-pixel` has been enabled by default since 2.14.1: 2b6afa02ab
`antialias` since 2.14.1: 0825a178e8
`lcdfilter` since 2.13.95: e1c7c6d744
`hintstyle` since 2.12.1: 98434b3392
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
If QT_QPA_PLATFORMTHEME is set to qt5ct, Qt 6 apps can utilize qt6ct, to
achieve consistent theming across the two major versions.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
Because llvmPackages_latest is used in Nixpkgs, by quite a few
packages, it's difficult to keep it up to date, because updating it
requires some level of confidence that every package that uses it is
going to keep working after the update. The result of this is that
llvmPackages_latest is not updated, and so we end up in the situation
that "latest" is two versions older than the latest version we
actually provide. This is confusing and unexpected.
"But won't this end up fragmenting our LLVM versions, if every package
previously using _latest is separately pinned to LLVM 14?", I hear you
ask. No. That fragmentation is already happening, even with an
llvmPackages_latest, because packages that actually require the
_latest_ version of LLVM (15/16), have already been decoupled from
llvmPackages_latest since it hasn't been upgraded. So like it or not,
we can't escape packages depending on specific recent LLVMs. The only
real fix is to get better at keeping the default LLVM up to
date (which I'm reasonably confident we're getting into a better
position to be feasibly better able to do).
So, unless we want to double down on providing a confusingly named
"llvmPackages_latest" attribute that refers to some arbitrary LLVM
version that's probably not the latest one (or even the latest one
available in Nixpkgs), we only have two options here: either we don't
provide such an attribute at all, or we don't use it in Nixpkgs so we
don't become scared to bump it as soon as we have a new LLVM available.
* add sector size parameter to swap randomEncryption
* add key size parameter to swap randomEncryption
* allow deviceName to be overridden for encrypted swap
* create test for swap random encryption
* update release notes
0d7cd66652 broke validation for hashes with options
such as those generated with `mkpasswd --method=sha-512 --rounds=1000000`:
$6$rounds=1000000$xpzZ6Rfg873gZnDY$RxS7lpVnohfDrrKG3lt9UFHED1KoiPGzH7zQv/HzwalZepo/IfFtxw05ap25duEJSKYhC14.Fn9eXszEpWVtF.
This fixes it.
A change made in #166308 added `networking.resolvconf.package` to the
`environment.systemPackages` list, so it is installed as part of the
system image. However it does so unconditionally, meaning that even if
the `config.networking.resolvconf.enable` is set to false the package
listed in the `networking.resolvconf.package` would still be intalled.
This change makes it so the package installation will depend on the
status of the `config.networking.resolvconf.enable` option instead.
The single option tries to do too much work, which just ends up confusing people.
So:
- don't force the console font, the kernel can figure this out as of #210205
- don't force the systemd-boot mode, it's an awkward mode that's not supported
on most things and will break flicker-free boot
- add a separate option for the xorg cursor scaling trick and move it under the xorg namespace
- add a general `fonts.optimizeForVeryHighDPI` option that explicitly says what it does
- alias the old option to that
- don't set any of those automatically in nixos-generate-config
Updates the warnings message for statefully set up passwords, now that
weak algorithms have been removed from our libxcrypt package.
Additionall we now add proper validation for hashing schemes used in
`hashedPassword`.
Neither will prevent a rebuiild, but instead issue a warning, that this
requires immediate remediation, or else users will be unable to login.
Reuses the crypt scheme ids as provided by the libxcrypt package.
Without this change, users that have both `initialHashedPassword` and
`hashedPassword` set will have `initialHashedPassword` take precedence,
but only for the first time `/etc/passwd` is generated. After that,
`hashedPassword` takes precedence. This is surprising behavior as it
would generally be expected for `hashedPassword` to win if both are set.
This wouldn't be a noticeable problem (and an assert could just be made
instead) if the users-groups module did not default the
`root.intialHashedPassword` value to `!`, to prevent login by default.
That means that users who set `root.hashedPassword` and use an ephemeral
rootfs (i.e. `/etc/passwd` is created every boot) are not able to log in
to the root account by default, unless they switch to a new generation
during the same boot (i.e. `/etc/passwd` already exists and
`hashedPassword` is used instead of `initialHashedPassword`) or they set
`root.initialHashedPassword = null` (which is unintuitive and seems
redundant).
