This change makes sure that each Nextcloud plugin installed provides a
`meta` section with proper license information.
Unfortunately, the metadata from the appstore is useless for this
purpose since it doesn't differentiate between e.g. AGPL 3.x and AGPL
3.x or any later version. In fact, this isn't consistent between their
software, e.g. `bookmarks` has `agpl3Plus` according to the files'
headers[1] whereas `twofactor_nextcloud_notification` is AGPL 3 only[2].
I don't think there's any trivial and reasonable way to retrieve this
information programatically, so I decided to change the format of
`nextcloud-apps.json`[3] to also contain the license in the form of the
license attribute we have in `lib/licenses.nix`, i.e. GNU AGPL 3 or
later is `agpl3Plus`.
I retrieved the information using the following approach:
* go to the source code of $app at the revision we currently have
packaged
* check for a license identifier (does it specify the license only or
the license "or any later version")?
* first in `src/main.js` because most apps from Nextcloud itself used
actual spdx identifiers in the frontend's source-code.
* then in `lib/AppInfo/Application.php` which each Nextcloud app has.
License changes should be updated accordingly when updating the apps. As
with any other package in nixpkgs as well, this currently needs to be
done manually (or as part of the review process)[4].
Also, I decided to change the `name` of the `applyPatches` derivation
from `source-patched` to `nextcloud-app-${appName}-${appVersion}`. When
deploying a lot of apps (and probably displaying the diff using
`nix store diff-closures` on deploy), the current output isn't very
helpful. This is purely optional because I didn't want to break the
interface of `fetchNextcloudApp` again.
[1] https://github.com/nextcloud/bookmarks/blob/v13.1.0/lib/AppInfo/Application.php#L6
[2] https://github.com/nextcloud/twofactor_nextcloud_notification/blob/v3.7.0/lib/AppInfo/Application.php
[3] This isn't really well-defined since it's preprocessed with `jq(1)`
before passing the apps to nc4nix.
[4] Though notable license changes (e.g. agpl -> gpl) would also pop up
in the diff of <nextcloudversion>.json, so this is pretty easy to
catch.
No idea what this gibberish disguised as tag is, but nc4nix doesn't seem
to cope well with it. For now, let's pin `maps` to the stable 1.1 release (as
it's the case for nextcloud27 already) since 1.1 is supported for all of
v25 to v27[1], so this seems reasonable to do.
[1] https://github.com/nextcloud/maps/blob/v1.1.0/appinfo/info.xml#L36
That way you can add packages like this in your `configuration.nix(8)`:
extraApps = with config.services.nextcloud.package.packages.apps; {
inherit calendar contacts;
};
I.e. it's not necessary anymore to update the reference anymore when
upgrading to a new major.
This is not needed anymore because the version is EOL for almost a year
now and we don't even have the packages anymore, only the attributes for
compatibility for upgrades from older NixOS versions.
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.
