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
The Nixpkgs documentation on the linux kernel builders focused on
using and extending kernels that were already packaged, but never
mentioned that it's possible to also build a kernel almost "from
scratch".
The NixOS documentation went a bit deeper on manual linux kernel
configs, but that information wasn't particularly NixOS-specific.
This commit consolidates the information related to building the
kernel on Nixpkgs's documentation, while keeping any additional
NixOS-specific information on NixOS's documentation.
An additional README.md was created for contributor-facing
documentation.
* 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>
In my earlier commit
manual: Don't suggest exposing VM port to local network.
I made a side change titled
Use `127.0.0.1` also on the VM side, otherwise connections to
services that, in the VM, bind to `127.0.0.1` only
(doing the safe approach) do not work.
Unfortunately, that was wrong:
QEMU inside the VM always communicates via the virtualised
Ethernet interface, not via the VM's loopback interface.
So trying to connect to `127.0.0.1` on the VM's side cannot work.
The setting
QEMU_NET_OPTS="hostfwd=tcp::2222-:22"
caused the VM's port 2222 to be advertised on the host as
`0.0.0.0:2222`, thus anybody in the local network of the host
could SSH into the VM.
Instead, port-forward to localhost only.
Use `127.0.0.1` also on the VM side, otherwise connections to
services that, in the VM, bind to `127.0.0.1` only
(doing the safe approach) do not work.
See e.g. https://github.com/NixOS/nixpkgs/issues/100192
for more info why localhost listening is the best default.
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.
