While we had to lie to generate.sh in order to get nc26 into the
running, and there are a lot of apps that have not released a compatible
version yet, for the ones that have, we are adding them alongside
nextcloud 26.0.0beta1.
Because nextcloud ships their prerelease versions on a different url, we
are not parsing the version string to detect which path to use. We also
enabled and validated this change via nixos module testing.
This includes the following new packages:
- files_texteditor
- files_markdown
- forms
- groupfolders
- impersonate
- registration
- spreed
- twofactor_nextcloud_notification
- twofactor_totp
- unsplash
And the following updated ones:
- bookmarks
- calendar
- contacts
- deck
- mail
- news
- polls
While updating to 23.0.9/24.0.5[1], it was discovered that Nextcloud
silently changes db passwords in some cases (in case of MySQL in **all**
now).
This is inherently incompatible with our module. Further context is
provided in the patch file attached to this commit.
[1] https://github.com/NixOS/nixpkgs/pull/190646, see comments below
Added Nextcloud 23 and set it as the default Nextcloud version for the
NixOS module. Added PHP 8.1 as an option for phpPackage and default for
Nextcloud ≥ 24.
The version 20 of Nextcloud will be EOLed by the end of this month[1].
Since the recommended default (that didn't raise an eval-warning) on
21.05 was Nextcloud 21, this shouldn't affect too many people.
In order to ensure that nobody does a (not working) upgrade across
several major-versions of Nextcloud, I replaced the derivation of
`nextcloud20` with a `throw` that provides instructions how to proceed.
The only case that I consider "risky" is a setup upgraded from 21.05 (or
older) with a `system.stateVersion` <21.11 and with
`services.nextcloud.package` not explicitly declared in its config. To
avoid that, I also left the `else-if` for `stateVersion < 21.03` which
now sets `services.nextcloud.package` to `pkgs.nextcloud20` and thus
leads to an eval-error. This condition can be removed
as soon as 21.05 is EOL because then it's safe to assume that only
21.11. is used as stable release where no Nextcloud <=20 exists that can
lead to such an issue.
It can't be removed earlier because then every `system.stateVersion <
21.11` would lead to `nextcloud21` which is a problem if `nextcloud19`
is still used.
[1] https://docs.nextcloud.com/server/20/admin_manual/release_schedule.html
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.
* It should be made explicit in the eval-error that the CVE only affects
a component which is turned off by default.
* For more clarity, the default version used by the module is noted in
the manual.
Closes#108419
Both packages will get EOLed within the lifetime of 20.09. `nextcloud17`
can be removed entirely (the attribute-path is kept however to provide
meaningful errors), however `nextcloud18` must be kept as `insecure` to
make sure that users from `nextcloud17` can properly upgrade to
`nextcloud19` on NixOS 20.09.
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
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/.nextcloud-news-updater-wrapped -h` got 0 exit code
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/.nextcloud-news-updater-wrapped --help` got 0 exit code
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/.nextcloud-news-updater-wrapped -v` and found version 10.0.1
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/.nextcloud-news-updater-wrapped --version` and found version 10.0.1
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/nextcloud-news-updater -h` got 0 exit code
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/nextcloud-news-updater --help` got 0 exit code
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/nextcloud-news-updater -v` and found version 10.0.1
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/nextcloud-news-updater --version` and found version 10.0.1
- found 10.0.1 with grep in /nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1
- directory tree listing: https://gist.github.com/ef3eb260a3fd46598a3b70c142c2ef2c
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
