JakeHillion/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
11838150a7
nixpkgs/pkgs/servers/nextcloud/default.nix

67 lines
2.0 KiB
Nix
Raw Normal View History

treewide: with stdenv.lib; in meta -> with lib; Part of: https://github.com/NixOS/nixpkgs/issues/108938 meta = with stdenv.lib; is a widely used pattern. We want to slowly remove the `stdenv.lib` indirection and encourage people to use `lib` directly. Thus let’s start with the meta field. This used a rewriting script to mostly automatically replace all occurances of this pattern, and add the `lib` argument to the package header if it doesn’t exist yet. The script in its current form is available at https://cs.tvl.fyi/depot@2f807d7f141068d2d60676a89213eaa5353ca6e0/-/blob/users/Profpatsch/nixpkgs-rewriter/default.nix
2021-01-11 07:54:33 +00:00
{ lib, stdenv, fetchurl, nixosTests }:
nextcloud: init at 10.0.0
2016-09-21 16:55:38 +01:00
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
let
nextcloud: 19.0.4 -> 19.0.6, 20.0.1 -> 20.0.3, mark v19 as insecure ChangeLogs: * https://nextcloud.com/changelog/#20-0-3 * https://nextcloud.com/changelog/#19-0-6 For Nextcloud 20, security advisories for CVE-2020-8259[1] & CVE-2020-8152[2] were published. The only way to fix those is to upgrade to v20, although v19 and v18 are supported, the issue won't be fixed there[3]. Even though both CVEs are only related to the encryption module[4] which is turned off by default, I decided to add a vulnerability note to `nextcloud19` since CVE-2020-8259's is rated as "High" by NIST (in contrast to Nextcloud which rates it as "Low"). If one is not affected by the issue, `nextcloud19` can still be used by declaring `permittedInsecurePackages`[5]. [1] https://nvd.nist.gov/vuln/detail/CVE-2020-8259, https://nextcloud.com/security/advisory/?id=NC-SA-2020-041 [2] https://nvd.nist.gov/vuln/detail/CVE-2020-8152, https://nextcloud.com/security/advisory/?id=NC-SA-2020-040 [3] https://help.nextcloud.com/t/fixes-for-cve-2020-8259-cve-2020-8152-in-nextcloud-18-19/98289 [4] https://docs.nextcloud.com/server/20/admin_manual/configuration_files/encryption_configuration.html [5] https://nixos.org/manual/nixpkgs/stable/#sec-allow-insecure Closes #106212
2020-12-10 19:57:42 +00:00
generic = {
version, sha256,
eol ? false, extraVulnerabilities ? []
}: stdenv.mkDerivation rec {
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
pname = "nextcloud";
inherit version;
nextcloud: init at 10.0.0
2016-09-21 16:55:38 +01:00
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
src = fetchurl {
url = "https://download.nextcloud.com/server/releases/${pname}-${version}.tar.bz2";
inherit sha256;
};
nextcloud*: add `passthru.tests` to reference VM-tests
2020-04-15 21:14:04 +01:00
passthru.tests = nixosTests.nextcloud;
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
installPhase = ''
mkdir -p $out/
cp -R . $out/
'';
nextcloud: init at 10.0.0
2016-09-21 16:55:38 +01:00
treewide: with stdenv.lib; in meta -> with lib; Part of: https://github.com/NixOS/nixpkgs/issues/108938 meta = with stdenv.lib; is a widely used pattern. We want to slowly remove the `stdenv.lib` indirection and encourage people to use `lib` directly. Thus let’s start with the meta field. This used a rewriting script to mostly automatically replace all occurances of this pattern, and add the `lib` argument to the package header if it doesn’t exist yet. The script in its current form is available at https://cs.tvl.fyi/depot@2f807d7f141068d2d60676a89213eaa5353ca6e0/-/blob/users/Profpatsch/nixpkgs-rewriter/default.nix
2021-01-11 07:54:33 +00:00
meta = with lib; {
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
description = "Sharing solution for files, calendars, contacts and more";
treewide: Per RFC45, remove all unquoted URLs
2020-04-01 02:11:51 +01:00
homepage = "https://nextcloud.com";
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
maintainers = with maintainers; [ schneefux bachp globin fpletz ma27 ];
license = licenses.agpl3Plus;
platforms = with platforms; unix;
nextcloud: 19.0.4 -> 19.0.6, 20.0.1 -> 20.0.3, mark v19 as insecure ChangeLogs: * https://nextcloud.com/changelog/#20-0-3 * https://nextcloud.com/changelog/#19-0-6 For Nextcloud 20, security advisories for CVE-2020-8259[1] & CVE-2020-8152[2] were published. The only way to fix those is to upgrade to v20, although v19 and v18 are supported, the issue won't be fixed there[3]. Even though both CVEs are only related to the encryption module[4] which is turned off by default, I decided to add a vulnerability note to `nextcloud19` since CVE-2020-8259's is rated as "High" by NIST (in contrast to Nextcloud which rates it as "Low"). If one is not affected by the issue, `nextcloud19` can still be used by declaring `permittedInsecurePackages`[5]. [1] https://nvd.nist.gov/vuln/detail/CVE-2020-8259, https://nextcloud.com/security/advisory/?id=NC-SA-2020-041 [2] https://nvd.nist.gov/vuln/detail/CVE-2020-8152, https://nextcloud.com/security/advisory/?id=NC-SA-2020-040 [3] https://help.nextcloud.com/t/fixes-for-cve-2020-8259-cve-2020-8152-in-nextcloud-18-19/98289 [4] https://docs.nextcloud.com/server/20/admin_manual/configuration_files/encryption_configuration.html [5] https://nixos.org/manual/nixpkgs/stable/#sec-allow-insecure Closes #106212
2020-12-10 19:57:42 +00:00
knownVulnerabilities = extraVulnerabilities
++ (optional eol "Nextcloud version ${version} is EOL");
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
};
};
in {
nextcloud21: init at 21.0.0, set as default version 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.
2021-02-21 23:04:23 +00:00
nextcloud18 = throw ''
Nextcloud v18 has been removed from `nixpkgs` as the support for it was dropped
by upstream in 2021-01. Please upgrade to at least Nextcloud v19 by
nixos/nextcloud: drop nextcloud17, deprecate nextcloud18 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.
2020-09-20 18:06:37 +01:00
declaring
nextcloud21: init at 21.0.0, set as default version 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.
2021-02-21 23:04:23 +00:00
services.nextcloud.package = pkgs.nextcloud19;
nixos/nextcloud: drop nextcloud17, deprecate nextcloud18 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.
2020-09-20 18:06:37 +01:00
in your NixOS config.
[1] https://docs.nextcloud.com/server/18/admin_manual/release_schedule.html
'';
nextcloud: init at 10.0.0
2016-09-21 16:55:38 +01:00
nextcloud19: update todo note
2021-03-04 20:15:18 +00:00
# FIXME(@Ma27) remove on 21.05
nextcloud19: init at 19.0.0 https://nextcloud.com/blog/nextcloud-hub-brings-productivity-to-home-office/
2020-06-03 16:17:04 +01:00
nextcloud19 = generic {
nextcloud: 19.0.4 -> 19.0.6, 20.0.1 -> 20.0.3, mark v19 as insecure ChangeLogs: * https://nextcloud.com/changelog/#20-0-3 * https://nextcloud.com/changelog/#19-0-6 For Nextcloud 20, security advisories for CVE-2020-8259[1] & CVE-2020-8152[2] were published. The only way to fix those is to upgrade to v20, although v19 and v18 are supported, the issue won't be fixed there[3]. Even though both CVEs are only related to the encryption module[4] which is turned off by default, I decided to add a vulnerability note to `nextcloud19` since CVE-2020-8259's is rated as "High" by NIST (in contrast to Nextcloud which rates it as "Low"). If one is not affected by the issue, `nextcloud19` can still be used by declaring `permittedInsecurePackages`[5]. [1] https://nvd.nist.gov/vuln/detail/CVE-2020-8259, https://nextcloud.com/security/advisory/?id=NC-SA-2020-041 [2] https://nvd.nist.gov/vuln/detail/CVE-2020-8152, https://nextcloud.com/security/advisory/?id=NC-SA-2020-040 [3] https://help.nextcloud.com/t/fixes-for-cve-2020-8259-cve-2020-8152-in-nextcloud-18-19/98289 [4] https://docs.nextcloud.com/server/20/admin_manual/configuration_files/encryption_configuration.html [5] https://nixos.org/manual/nixpkgs/stable/#sec-allow-insecure Closes #106212
2020-12-10 19:57:42 +00:00
version = "19.0.6";
sha256 = "sha256-pqqIayE0OyTailtd2zeYi+G1APjv/YHqyO8jCpq7KJg=";
extraVulnerabilities = [
nextcloud: improve documentation on defaults * 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
2021-01-05 21:31:06 +00:00
"Nextcloud 19 is still supported, but CVE-2020-8259 & CVE-2020-8152 are unfixed! Please note that both CVEs only affect the file encryption module which is turned off by default. Alternatively, `pkgs.nextcloud20` can be used."
nextcloud: 19.0.4 -> 19.0.6, 20.0.1 -> 20.0.3, mark v19 as insecure ChangeLogs: * https://nextcloud.com/changelog/#20-0-3 * https://nextcloud.com/changelog/#19-0-6 For Nextcloud 20, security advisories for CVE-2020-8259[1] & CVE-2020-8152[2] were published. The only way to fix those is to upgrade to v20, although v19 and v18 are supported, the issue won't be fixed there[3]. Even though both CVEs are only related to the encryption module[4] which is turned off by default, I decided to add a vulnerability note to `nextcloud19` since CVE-2020-8259's is rated as "High" by NIST (in contrast to Nextcloud which rates it as "Low"). If one is not affected by the issue, `nextcloud19` can still be used by declaring `permittedInsecurePackages`[5]. [1] https://nvd.nist.gov/vuln/detail/CVE-2020-8259, https://nextcloud.com/security/advisory/?id=NC-SA-2020-041 [2] https://nvd.nist.gov/vuln/detail/CVE-2020-8152, https://nextcloud.com/security/advisory/?id=NC-SA-2020-040 [3] https://help.nextcloud.com/t/fixes-for-cve-2020-8259-cve-2020-8152-in-nextcloud-18-19/98289 [4] https://docs.nextcloud.com/server/20/admin_manual/configuration_files/encryption_configuration.html [5] https://nixos.org/manual/nixpkgs/stable/#sec-allow-insecure Closes #106212
2020-12-10 19:57:42 +00:00
];
nextcloud19: init at 19.0.0 https://nextcloud.com/blog/nextcloud-hub-brings-productivity-to-home-office/
2020-06-03 16:17:04 +01:00
};
nextcloud20: init
2020-10-04 20:55:58 +01:00
nextcloud20 = generic {
nextcloud: 20.0.6 -> 20.0.7
2021-02-06 21:14:10 +00:00
version = "20.0.7";
sha256 = "sha256-jO2Ct3K/CvZ9W+EyPkD5d0KbwKK8yGQJXvx4dnUAtys=";
nextcloud20: init
2020-10-04 20:55:58 +01:00
};
nextcloud21: init at 21.0.0, set as default version 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.
2021-02-21 23:04:23 +00:00
nextcloud21 = generic {
nextcloud: 21.0.0 -> 21.0.1
2021-04-09 07:56:34 +01:00
version = "21.0.1";
sha256 = "dd7c8ccc01547914a75b44bbf86028289c8919dc39f4e2e720147b6bd596aebe";
nextcloud21: init at 21.0.0, set as default version 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.
2021-02-21 23:04:23 +00:00
};
nextcloud: 21.0.0 -> 21.0.1
2021-04-09 07:56:34 +01:00
# tip: get she sha with:
# curl 'https://download.nextcloud.com/server/releases/nextcloud-${version}.tar.bz2.sha256'
nextcloud: init at 10.0.0
2016-09-21 16:55:38 +01:00
}
Reference in New Issue Copy Permalink