The 5.10 series is the next longterm version of the linux kernel and
I've been using it on multiple x86_64 machines ever since it came out.
I think it is time to switch over the default now, so we get some
additional testing in time for NixOS 21.05.
- Write a `mkDerivation` and `mkDerivationWith` function for gnuradio,
like qt5.
- qradiolink, gqrx: Use gnuradio's callPackage and mkDerivation.
- Use gnuradio.callPackage to define all gnuradio.pkgs.
- Move all gnuradio packages expressions to pkgs/development/gnuradio-modules/ -
modeled after Python's.
- Add more paths to gnuradio's wrapper - add the extra packages as
python modules, and add their executables with proper env vars
wrapping.
Co-authored-by: Frederik Rietdijk <fridh@fridh.nl>
Change the default SMTP port to `25`, to better match the default
address `localhost`. This gets rid of some error outputs in the test,
where it fails to connect to localhost:465.
Also, don't enable postfix by default unless it's actually useful to
us.
ChangeLog: https://nextcloud.com/changelog/#latest21
* Packaged 21.0.0, test-deployed it to my personal instance and tested
the most basic functionality (`davfs2`-mount, {card,cal}dav sync, file
management).
* Bumped the default version for unstable/21.05 to `nextcloud21`. Since
`nextcloud20` was added after the release of 20.09 (and thus the
default on 20.09 is still `nextcloud19`), it's now needed to upgrade
across two majors.
This is not a problem though since it's possible to upgrade to v20 on
20.09 already and if not, the module will guard the administrator
through the upgrade with eval warnings as it's the case since 20.03.
* Dropped `nextcloud17` attribute and marked `nextcloud18` as EOL.
The NixOS 21.03 release has been delayed to 21.05. See NixOS/rfcs#80.
There are two instances of 21.03 which have been left as is, since they
are in stateVersion comparisons. This will ensure that existing user
configurations which refer to 21.03 will continue to work.
Important changes:
- The 'isync' compatibility wrapper was removed.
- The Master/Slave configuration keywords where deprecated and should be
replaced with Far/Near. All users should update their configuration
file accordingly. It's a trivial change and the old Master/Slave
keywords will still work for now but result in the following message:
Notice: Master/Slave are deprecated; use Far/Near instead.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
By default, restic determines the location of the cache based on the XDG
base dir specification, which is `~/.cache/restic` when the environment
variable `$XDG_CACHE_HOME` isn't set.
As restic is executed as root by default, this resulted in the cache being
written to `/root/.cache/restic`, which is not quite right for a system
service and also meant, multiple backup services would use the same cache
directory - potentially causing issues with locking, data corruption,
etc.
The goal was to ensure, restic uses the correct cache location for a
system service - one cache per backup specification, using `/var/cache`
as the base directory for it.
systemd sets the environment variable `$CACHE_DIRECTORY` once
`CacheDirectory=` is defined, but restic doesn't change its behavior
based on the presence of this environment variable.
Instead, the specifier [1] `%C` can be used to point restic explicitly
towards the correct cache location using the `--cache-dir` argument.
Furthermore, the `CacheDirectoryMode=` was set to `0700`, as the default
of `0755` is far too open in this case, as the cache might contain
sensitive data.
[1] https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers
