PHP 8.2 will only receive security patches starting at the end of
November[1], so it makes sense to bump the default version forward.
I looked through all modules with the substring `pkgs.php`[2] and all of
the usages looked fine or were fixed in a commit before this one.
[1] https://www.php.net/supported-versions.php
[2] I didn't take `with`/`let ... in` things into account, but honestly,
if an application doesn't work with a newer PHP, it should probably
be pinned down instead of blindly relying on `pkgs.php`.
services.bind.cacheNetworks should only apply to recursive queryies, as
per the option documentation:
> Note that this is for recursive queries – all networks are allowed to
> query zones configured with the zones option by default [...].
This would correspond to the `allow-query-cache` option in named.conf,
as per the BIND docs[1]:
> Specifies which hosts (an IP address list) can access this server’s
> cache and thus effectively controls recursion.
And not `allow-query`, which restricts all requests (including requests
where the server has authority) [2]:
> Specifies which hosts (an IP address list) are allowed to send queries
> to this resolver.
> [...]
> Note:
> `allow-query-cache` is used to specify access to the cache.
[1]: https://bind9.readthedocs.io/en/v9.20.0/reference.html#namedconf-statement-allow-query-cache
[2]: https://bind9.readthedocs.io/en/v9.20.0/reference.html#namedconf-statement-allow-query
I wondered why my neovim was slow. Turned out notmuch.vim loading took >
500ms to load (ruby and all). And I dont even use it !
I suspect the plugin could be improved to lazyload more stuff but I
think it's ok to have the vim plugin installer be a user decision as well.
I moved it to a new "vim" output : you can install the plugin via
"notmuch.vim"
This looks a little ridiculous right now, but my experience is that
it’s common to find the beginning or end of a section and add more
things there without seeing the comments. We should probably move
to a one file per release note system, but in the meantime this is
a low‐cost way to help reduce merge conflicts.
This will be EOL at the end of November, so there's little reason to
keep it in 24.11[1]. As discussed, we'd like to keep it for as long as
possible to make sure there's a state in nixpkgs that has the latest
minor of postgresql_12 available with the most recent CVEs fixed for
people who cannot upgrade[2].
This aspect has been made explicit in the manual now for the next .11
release.
During the discussions it has been brought up that if people just do
`services.postgresql.enable = true;` and let the code decide the
postgresql version based on `system.stateVersion`, there's a chance that
such EOL dates will be missed. To make this harder, a warning will now
be raised when using the stateVersion-condition and the oldest still
available major is selected.
Additionally regrouped the postgresql things in the release notes to
make sure these are all shown consecutively. Otherwise it's a little
hard to keep track of all the changes made to postgresql in 24.11.
[1] https://endoflife.date/postgresql
[2] https://github.com/NixOS/nixpkgs/pull/353158#issuecomment-2453056692
