Apologies to the non-flake users; your repl isn't quite as fancy,
but at least evaluates your config exactly as you would expect,
unlike flakes which are only evaluated impurely for now.
This type is necessary to have correct merging behavior for
`allowUnfreePredicate` and `allowInsecurePredicate`
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
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
