This replaces the krb5 module's options with RFC 42-style krb5.settings
option, while greatly simplifying the code and fixing a few bugs,
namely:
- #243068 krb5: Configuration silently gets ignored when set by
multiple modules
- not being able to use mkIf etc. inside subattributes of
krb5.libdefaults, e.g. krb5.libdefaults.default_realm = mkIf ...
See #144575.
Closes#243068.
Co-authored-by: h7x4 <h7x4@nani.wtf>
This makes sure we don't need any workarounds for running Invidious with a local
PostgreSQL database.
Changing the default user should be fine as the new init script for PostgreSQL automatically
creates the new user and changes the existing database's owner to the new user. The old user
will still linger and must be removed manually.
See also: https://github.com/NixOS/nixpkgs/pull/266270
This simplifies the setup to receive emails from the ZFS Event Daemon
by relying on the sendmail wrapper defined by other modules such as
msmtp or Postfix.
This is more similar to how other modules like smartd deal with email
configuration.
The user is no longer required to define and rebuild their own ZFS
package to add email support.
GitHub: closes https://github.com/NixOS/nixpkgs/issues/132464
we previously defined a custom type for `boot.kernel.sysctl."net.core.rmem_max"`
to resolve to the highest value set. this patch adds the same behavior to
`"net.core.wmem_max"`.
as this changes the type from a string to an integer, which is a breaking
change this patch also includes a release note and updates the transmission
module to use a number for `wmem_max`.
People are actively writing release notes already and with this it's
ensured that the contents are actually valid.
Also, when writing release notes for something, I'd like to be able to
see a preview.
I don't use this tool but saw it in the top level and that's not where it should
live.
This could arguably also be seen as a RAID; it's a bit of an in-between.
see https://github.com/lathiat/nss-mdns#:~:text=in%20such%20a%20situation%20causes%20long%20timeouts%20when%20resolving%20hosts
especially:
> libnss_mdns.so.2 resolves both IPv6 and IPv4 addresses, libnss_mdns4.so.2 only IPv4 addresses and
> libnss_mdns6.so.2 only IPv6 addresses. Due to the fact that most mDNS responders only register local IPv4
> addresses via mDNS, most people will want to use libnss_mdns4.so.2 exclusively. Using libnss_mdns.so.2
> or libnss_mdns6.so.2 in such a situation causes long timeouts when resolving hosts since most modern
> Unix/Linux applications check for IPv6 addresses first, followed by a lookup for IPv4.
Fixed conflict in pkgs/applications/graphics/krita/
krita: 5.1.5 -> 5.2.0
7a40fdc288
, and
treewide: use kde mirror everywhere, don't use pname in download urls
aa15f5066d
This is now the default recommendation upstream for linux platforms
> https://doc.qt.io/qt-6.6/qtmultimedia-index.html#ffmpeg-as-the-default-backend
> In this release the FFmpeg framework is set as the default backend on
> Windows, macOS, Android, and Linux except Yocto distribution.
> The version shipped with Qt binary packages is FFmpeg 6.0
> and is tested by the maintainers.
libXrandr is required to compile support QT_WINDOW_CAPTURE_BACKEND=x11
Provide a NixOS module for the [built-in Anki Sync
Server](https://docs.ankiweb.net/sync-server.html) included in recent
versions of Anki. This supersedes the `ankisyncd` module, but we should
keep that for now because `ankisyncd` supports older versions of Anki
clients than this module.
SnapRAID has a feature where you can specify "split" parity files. This
is useful when you're using 16tb or bigger ext4-formatted disks for
parity. ext4 doesn't support files bigger than 16tb so this "split
parity file" can be used to specify two parity files on a single parity
disk and SnapRAID will automatically use the subsequent file when the current
cannot grow anymore (hits 16TB). You specify these split parity files by
separating them with commas in the "parity" config option. This
mostly already works except when it comes to the scheduled systemd sync
job where it specifies ReadWritePaths. If you specify a parity with
multiple files you'll get an error when the systemd job runs: Failed to
set up mount namespacing:
/run/systemd/unit-root/mnt/parity1/snapraid1.parity,/mnt/parity1/snapraid2.parity: No such file or directory
Essentially, when the parity file paths are passed into ReadWritePaths,
they're always treated as a single path. This change makes sure to
split the paths if they contain a comma.
The big concern for this change is if it would break users who have
commas in their actual parity file paths. This won't be an issue because SnapRAID
itself blindly splits on commas for parity files, so legitimate commas in a parity
file path wouldn't work in SnapRAID anyway. See here:
978d812153/cmdline/state.c (L692)
SnapRAID doc for split parity files: https://www.snapraid.it/manual#7.1
NixOS releases are also `lib` releases :)
The release notes were collected from looking at the `git diff` since
22.11.
Since the NixOS and Nixpkgs manuals are rendered separately, I'm linking
to the "unstable" link to make sure the links definitely work on the time of
release. The "stable" link might take some time to become available
* nixos/forgejo: changelog and migration instructions
* nixos/forgejo/docs: clarify sentence
Co-authored-by: Trolli Schmittlauch <schmittlauch@users.noreply.github.com>
* nixos/forgejo/docs: document migration via gitea impersonation
* nixos/forgejo/docs: note about url change on migration
* nixos/forgejo/docs: note about migration (non-)requirement
* nixos/forgejo/docs: header ids
* nixos/forgejo/docs: clarify release notes entry
Co-authored-by: Emily <git@emilylange.de>
* nixos/forgejo/docs: improve manual entry
Co-authored-by: Emily <git@emilylange.de>
* nixos/forgejo/docs: move changelog line to the middle of the section
as noted <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
---------
Co-authored-by: Trolli Schmittlauch <schmittlauch@users.noreply.github.com>
Co-authored-by: Emily <git@emilylange.de>
Docker CE 20.10 seems to stop receiving security updates and bug fixes
after December 10, 2023[1].
1. https://github.com/moby/moby/discussions/45104
There is public commitment for longer maintenance and then it seems
risky to default to it during 23.11 life-cycle.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
Based on #257780, separated since it introduces significant changes.
bpycv: update passthru.tests.render
blender-with-packages: deprecated
it is still backwards compatible, but no longer preferred.
[Motivation](NixOS#257817 (comment))
`extraLayouts` was missed in #259891, so moving it to the other xkb
options with this PR.
Signed-off-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
Related to #262907 (Django3 removal from nixpkgs).
This package already required an unreasonable amount of maintenance
regularly for a such small leaf-package. It has a few highly outdated
dependencies (e.g. flask 1, jinja2 2.11, sqlalchemy 1.3).
After at least each Python package-set update one had to fix up a lot of
dependencies to fix the package itself, so it was only useful on stable
branches. And having so much outdated software in a security-sensitive
piece of software seems questionable.
Finally, globin and I won't be available for maintaining this now that
Mayflower is migrating to another solution (and we'll do that as well)
and I'd expect this to bitrot extremely quick if we both bail out.
As described in the release lifecycle docs from postgresql[1], v11 will
stop receiving fixes as of Nov 9 2023. This means it's EOL throughout
the entire lifetime of 23.11, so let's drop it now.
A lot of examples are also referencing postgresql_11. Where it's
sensible, use postgresql_15 as example now to avoid confusion.
This is also handy because the LLVM 16 fix for postgresql is not
available for postgresql 11 ;-)
[1] https://www.postgresql.org/support/versioning/
* luarocks-packages-updater: init
Goal is to make it possible to maintain out-of-tree luarocks packages
without needing to clone nixpkgs.
maintainers/scripts/update-luarocks-packages gets renamed to
pkgs/development/lua-modules/updater/updater.py
Once merged you can run for instance
nix run nixpkgs#luarocks-packages-updater -- -i contrib/luarocks-packages.csv -o contrib/generated-packages.nix
I also set the parallelism (--proc) to 1 by default else luarocks fails
because of https://github.com/luarocks/luarocks/issues/1540
* Update maintainers/scripts/pluginupdate.py
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
---------
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
This is mainly due to the lack of maintenance in nixpkgs.
`google-chrome-{beta,dev}` depend on `chromium{Beta,Dev}`'s version
info.
`chromium{Beta,Dev}` are rarely updated and explicitly blocklisted by
`hydra.nixos.org`, meaning they are almost always outdated and not
cached in `cache.nixos.org`.
`chromium{Beta,Dev}` were intended to fix the build derivation of each
new major release (if something broke) *before* stable reached that
new major release.
Allowing for fast bumps in nixpkgs, especially if the stable bump
contains very important critical security fixes.
Something that can easily be replicated by using an early-stable release
or by manually entering a dev/beta version string in stable's
`upstream-info.nix`.
This resolves exposing end-users to outdated and vulnerable
`google-chrome-{beta,dev}` and `chromium{Beta,Dev}` versions.
Release announcement:
https://github.com/psb1558/Junicode-font/releases/tag/v2.001
This is a breaking change, at least in font file naming (Junicode.ttf
is now Junicode-Regular.ttf). In general, 2.0 adds a lot more font
variants and opentype and web font versions of the font.
Seeing as backward compatibility is broken anyway, I opted to break it
a bit more and change custom install path (`junicode-ttf`) to
seemingly more conventional `truetype`; new .otf and .woff2 variants
are then naturally placed in corresponding directories. This
does *not* affect the `fonts.packages` NixOS option, which rearranges
font files anyway, but brings a degree of consistency with other
fonts.
Both the file renaming and the directory structure change break
satysfi, however, so I adjusted its builder accordingly, copying over
only those font variants that were also present in 1.0 series.
While there is no fetcher or builder (in nixpkgs) that takes an `md5` parameter,
for some inscrutable reason the nix interpreter accepts the following:
```nix
fetchurl {
url = "https://www.perdu.com";
hash = "md5-rrdBU2a35b2PM2ZO+n/zGw==";
}
```
Note that neither MD5 nor SHA1 are allowed by the syntax of SRI hashes.
Kea may clean the runtime directory when starting (or maybe systemd does
it). I ran into this issue when restarting Kea after changing its
configuration, so I think the fact it normally doesn't clean it is a
race condition (it's cleaned on service start, and normally all Kea
services start at roughly the same time).
This adds a NixOS module for Soft Serve, a tasty, self-hostable Git
server for the command line. The module has a test that checks some
basic things like creating users, creating a repo and cloning it.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Yama is a LSM which restricts debugging. This prevents processes from
snooping on another. It can be easily disabled with sysctl.
This was initially included in #14392 and disabled by default by
86721a5f78.
This has been part of the hardened configuration, but many other distros
ship this for quite some time (Ubuntu for about ten years), so I'd say
it might make sense to enable this per default.
- Remove lots of declared options that were not used outside of being
included in settings. These should now be used through the freeform
module.
- Deprecate `cfg.workDir`, in favor of using systemds `StateDirectory`
- Use sqlite as default database.
Co-authored-by: Sandro Jäckel <sandro.jaeckel@gmail.com>
I noticed that openvpn3 is been clobbering my `/etc/resolv.conf` file. I
dug around a bit, and it turns out that upstream actually does have
support for systemd-resolved. I think it makes sense for us to
automatically enable that feature if the system is configured to use
systemd-resolved.
I opted to not change the default behavior of `pkgs.openvpn3`, but can
easily be convinced to change that if folks think I should.
[Motivation](https://github.com/NixOS/nixpkgs/issues/257817#issuecomment-1741705042):
- Having all the XKB options in the same attribute set clarifies their
relation better than using a common option name prefix ("xkb").
- `services.xserver.layout` is an XKB option, but this is not obvious
from its name. Putting it with the other XKB options clarifies this.
Co-authored-by: Michele Guerini Rocco <rnhmjoj@users.noreply.github.com>
