Also removed `pkgs.hydra-flakes` since flake-support has been merged
into master[1]. Because of that, `pkgs.hydra-unstable` is now compiled
against `pkgs.nixFlakes` and currently requires a patch since Hydra's
master doesn't compile[2] atm.
[1] https://github.com/NixOS/hydra/pull/730
[2] https://github.com/NixOS/hydra/pull/732
Some changes might require manual migration steps:
"Due to changes to the way in which Gollum handles filenames, you may
have to change some links in your wiki when migrating from gollum 4.x.
See the release notes [0] for more details. You may find the
bin/gollum-migrate-tags script helpful to accomplish this. Also see the
--lenient-tag-lookup option for making tag lookup backwards compatible
with 4.x, though note that this will decrease performance on large wikis
with many tags." (source: [1])
[0]: https://github.com/gollum/gollum/wiki/5.0-release-notes
[1]: https://github.com/gollum/gollum/blob/v5.0.0/HISTORY.md
So now we have only packages for human interaction in php.packages and
only extensions in php.extensions. With this php.packages.exts have
been merged into the same attribute set as all the other extensions to
make it flat and nice.
The nextcloud module have been updated to reflect this change as well
as the documentation.
Upgrades Hydra to the latest master/flake branch. To perform this
upgrade, it's needed to do a non-trivial db-migration which provides a
massive performance-improvement[1].
The basic ideas behind multi-step upgrades of services between NixOS versions
have been gathered already[2]. For further context it's recommended to
read this first.
Basically, the following steps are needed:
* Upgrade to a non-breaking version of Hydra with the db-changes
(columns are still nullable here). If `system.stateVersion` is set to
something older than 20.03, the package will be selected
automatically, otherwise `pkgs.hydra-migration` needs to be used.
* Run `hydra-backfill-ids` on the server.
* Deploy either `pkgs.hydra-unstable` (for Hydra master) or
`pkgs.hydra-flakes` (for flakes-support) to activate the optimization.
The steps are also documented in the release-notes and in the module
using `warnings`.
`pkgs.hydra` has been removed as latest Hydra doesn't compile with
`pkgs.nixStable` and to ensure a graceful migration using the newly
introduced packages.
To verify the approach, a simple vm-test has been added which verifies
the migration steps.
[1] https://github.com/NixOS/hydra/pull/711
[2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
It's impossible to move two major-versions forward when upgrading
Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16)
and trying to upgrade to 20.03 (using Nextcloud 18 by default).
This patch implements the measurements discussed in #82056 and #82353 to
improve the update process and to circumvent similar issues in the
future:
* `pkgs.nextcloud` has been removed in favor of versioned attributes
(currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that
approach we can safely backport major-releases in the future to
simplify those upgrade-paths and we can select one of the
major-releases as default depending on the configuration (helpful to
decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be
used on 20.03 and `master` atm).
* If `system.stateVersion` is older than `20.03`, `nextcloud17` will be
used (which is one major-release behind v16 from 19.09). When using a
package older than the latest major-release available (currently v18),
the evaluation will cause a warning which describes the issue and
suggests next steps.
To make those package-selections easier, a new option to define the
package to be used for the service (namely
`services.nextcloud.package`) was introduced.
* If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to
provide more recent Nextcloud versions on older NixOS-releases), an
evaluation error will be thrown by default: this is to make sure that
`services.nextcloud.package` doesn't use an older version by accident
after checking the state-version. If `pkgs.nextcloud` is added
manually, it needs to be declared explicitly in
`services.nextcloud.package`.
* The `nixos/nextcloud`-documentation contains a
"Maintainer information"-chapter which describes how to roll out new
Nextcloud releases and how to deal with old (and probably unsafe)
versions.
Closes#82056
Dropbear lags behind OpenSSH significantly in both support for modern
key formats like `ssh-ed25519`, let alone the recently-introduced
U2F/FIDO2-based `sk-ssh-ed25519@openssh.com` (as I found when I switched
my `authorizedKeys` over to it and promptly locked myself out of my
server's initrd SSH, breaking reboots), as well as security features
like multiprocess isolation. Using the same SSH daemon for stage-1 and
the main system ensures key formats will always remain compatible, as
well as more conveniently allowing the sharing of configuration and
host keys.
The main reason to use Dropbear over OpenSSH would be initrd space
concerns, but NixOS initrds are already large (17 MiB currently on my
server), and the size difference between the two isn't huge (the test's
initrd goes from 9.7 MiB to 12 MiB with this change). If the size is
still a problem, then it would be easy to shrink sshd down to a few
hundred kilobytes by using an initrd-specific build that uses musl and
disables things like Kerberos support.
This passes the test and works on my server, but more rigorous testing
and review from people who use initrd SSH would be appreciated!
This mirrors the behaviour of systemd - It's udev that parses `.link`
files, not `systemd-networkd`.
This was originally applied in 36ef112a47,
but was reverted due to 1115959a8d causing
evaluation errors on hydra.
* Linkify all service options used in the code-examples.
* Demonstrated the use of `riot-web.override {}`.
* Moved the example how to configure a postgresql-database for
`matrix-synapse` to this document from the 20.03 release-notes.
...even when networkd is disabled
This reverts commit ce78f3ac70, reversing
changes made to dc34da0755.
I'm sorry; Hydra has been unable to evaluate, always returning
> error: unexpected EOF reading a line
and I've been unable to reproduce the problem locally. Bisecting
pointed to this merge, but I still can't see what exactly was wrong.
On servers especially, phantomjs2 pulls graphical dependencies which is unecessary.
This pathes enable the package to be linked/installed without
phantomjs2. Phantomjs2 is disabled by default since it has been deprecated in grafana https://grafana.com/docs/grafana/latest/guides/whats-new-in-v6-4/
In 0945178b3c we decided that Perl-based
VM tests should be deprecated and will be removed between 20.03 and
20.09. So let's switch `nixos-build-vms(8)` to python as well (which is
entirely interactive, so other scripts won't break).
In my experience, the test-driver isn't used most of the time, so this
patch is mainly supposed to get rid of the (probably misleading)
deprecation warning when running `nixos-build-vms`. Apart from that, the
interface for python's test-driver is way nicer.
XML error introduced with merge commit 4e0fea3fe2.
This was probably because of wrong conflict resolution, because the
actual change (d8e697b4fc) had the close
tag of the <para/> element, but the merge commit didn't.
Signed-off-by: aszlig <aszlig@nix.build>
Package is marked as broken for >2 years and used a fairly old
snapshot from the gcc7-branch, so I fairly doubt that this is
somewhere used (and is also pretty misleading as you don't expect a
random snapshot from gcc7 at `pkgs.gcc-snapshot`).
There are no new releases of sqldeveloper v17/v18 and I don't think that
we should keep obviously unmaintained software that interacts with
database systems.
I removed `sqldeveloper_18` and `pkgs.sqldeveloper` now points to
version 19.4. Unfortunately I had to drop darwin support as JavaFX is
required for 19.4 which is part of the `oraclejdk` which isn't packaged
for darwin yet.
For further information please refer to the release notes:
https://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/sqldev-relnotes-194-5908846.html
This module allows root autoLogin, so we would break that for users, but
they shouldn't be using it anyways. This gives the impression like auto
is some special display manager, when it's just lightdm and special pam
rules to allow root autoLogin. It was created for NixOS's testing
so I believe this is where it belongs.
Will be unsupported within the lifespan of 20.03. Also there aren't any
known issues that require this version as workaround, so a removal
should be fairly safe.
As of 2020-01-09, way-cooler is officially dead:
http://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html
hence, remove the package and the module.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
docs/release-notes: remove way-cooler
way-cooler: show warnings about removal
Apply suggestions from code review
Co-Authored-By: worldofpeace <worldofpeace@protonmail.ch>
way-cooler: add suggestion by @Infinisil
Deperecates the interfaces option which was used to generate a host:port
list whereas the port was always hardcoded to 53. This unifies the
listen configuration for plain and TLS sockets and allows to specify a
port without an address for wildcard binds.
This makes ~2.5x speed up of an empty container instantiate, hence reduces
rebuild time of system with many declarative containers.
Note that this doesn't affect production systems much, becaseu those most
likely already include `minimal.nix` profile.
The upstream session files display managers use have no concept of sessions being composed from
desktop manager and window manager. To be able to set upstream session files as default
session, we need a single option. Having two different ways to set default session would be confusing,
though, so we decided to deprecate the old method.
We also created separate script for each session, just like we already had a separate desktop
file for each one, and started using displayManager.sessionPackages mechanism to make the
session handling more uniform.
Fixes https://github.com/NixOS/nixpkgs/issues/75075.
To summarize the report in the aforementioned issue, at a glance,
it's a different default than what upstream polkit has. Apparently
for 8+ years polkit defaults admin identities as members of
the wheel group [0]. This assumption would be appropriate on NixOS, where
every member of group 'wheel' is necessarily privileged.
[0]: 763faf434b
This cuts down the dependency tree on some rust builds where a crate not
just exposes a binary but also a library. `$out/lib` contained a bunch
of extra support files that among other information carry linker flags
(including the full path to link-time dependencies). Worst case this led
to some binary outputs depending on the full build closure of rust
crates.
Moving all the `$out/lib` files to `$lib/lib` solves this nicely.
`lib` might be a bit weird here as they are most of the time just rlib
files (rust libraries). Those are essential only required during
compilation but they can also be shared objects (like with traditional
C-style packages). Which is why I went with `lib` for the new output.
One of the caveats we are running into here is that we do not (always)
know ahead of time of a crate produces just a library or just a binary.
Cargo allows for some ambiguity regarding whether or not a crate
provides one, two, … binaries and libraries as it's outputs. Ideally we
would be able to rely on the `crateType` entirely but so far that isn't
the case. More work on that area might show how difficult that actually
is.
This is a more sane default since we do not magically (without opt-in)
pull in binaries from `~/bin`. That is not really an expected behavior
for many users. Users that still want that behavior can now just flip
that switch.
osquery was marked as broken since April.
If somebody steps up to fix it, we can always revive it from the
histroy, but there's not much value in shipping completely broken things
in current master.
cc @ma27
The package set is not maintained. It is also not used by most of the
BEAM community. Removing it to allow a more useful set of tools fit to
the BEAM community in Nixpkgs.
Before, we very carefully unapplied and reapplied `set -u` so the rest
of Nixpkgs could continue to not fail on undefined variables. Let's rip
off the band-aid.
Just maching all network interfaces caused many breakages, see #18962
and #71106.
We already don't support the global networking.useDHCP,
networking.defaultGateway(6) options if networking.useNetworkd is
enabled, but direct users to configure the per-device
networking.interfaces.<name?>.… options.
Even though the release obviously already happened, I think it might
still make sense to add a short note about the attributes not being
supported any longer (and going forward).
(cherry picked from commit 7163d3a9df35904d0c9acc9f643fd70ee3108539)
(cherry picked from commit a64b8c3c191af1317cfdc1ea4f4e5f881c4cf503)
This option was removed because allowing (multiple) regular users to
override host entries affecting the whole system opens up a huge attack
vector. There seem to be very rare cases where this might be useful.
Consider setting system-wide host entries using networking.hosts,
provide them via the DNS server in your network, or use
networking.networkmanager.appendNameservers to point your system to
another (local) nameserver to set those entries.
This solves the dependency cycle in gcr alternatively so there won't be
two gnupg store paths in a standard NixOS system which has udisks2 enabled
by default.
NixOS users are expected to use the gpg-agent user service to pull in the
appropriate pinentry flavour or install it on their systemPackages and set
it in their local gnupg agent config instead.
Co-authored-by: Florian Klink <flokli@flokli.de>
