Updates to the latest version of the desktop client available. Tested
the config migration from `nextcloud-client` 2.3.3 with a Nextcloud
14.0.3 instance (hosted using `services.nextcloud`).
Additionally the derivation required the following changes:
* Dropped `Qt5Sql` patch: this has been fixed upstream and isn't needed
anymore (furthermore their CMake structure has changed and the patch
wouldn't apply anymore on 2.5.0).
* Moved to a new upstream repository (nextcloud/desktop), kept
`fetchgit` to properly fetch submodules.
* Added OpenSSL 1.1 integration: `libsync` (the syncing provided by this
package) requires 1.1, furthermore the linking flags had to be fixed
manually by passing `NIX_LDFLAGS` to the derivation.
Furthermore I moved the support for a Gnome3 keyring into its own
wrapper to avoid a full rebuild of the package whenever you alter
`withGnomeKeyring` in an override expressions.
It's still possible to enable keyring (now without recompile) like this:
```
nextcloud-client.override { withGnomeKeyring = true; }
```
To override the derivation itself you now have to use
`nextcloud-client-unwrapped`:
```
nextcloud-client-unwrapped.overrideAttrs (old: {
src = yoursrc;
})
```
Mininet (https://github.com/mininet/mininet) is a popular network emulator that
glues several components such as network namespaces, traffic control
commands into a set of python bindings. It is then "easy" to describe a
topology and run experiments on it.
ao has been renamed to libfive. Because there’s already a libfive
package, we can just remove the old ao package. No packages appear to
depend directly on it.
If the nix store lives on NFS, `ghc 8.2.1` is unable to build a package
database. This bug was fixed by @bgamari in `ghc 8.2.2` here:
https://ghc.haskell.org/trac/ghc/ticket/13945
This commit upgrades the unpacked bootstrap GHC version, so that we can build
newer versions of GHC even if the store is on NFS.
- removed patch for sage as it is applied in most recent release.
- simplified `ipython` attribute no need for explicit version `5`
vs. `6`.
- upgrade to most recent version of ipython
providers are already compiled independently so we don't need Hydra to
follow terraform_MAJ_MIN_full to have them all compiled.
Instead of having to create two aliases per release, add a "full"
passthru for that common use-case.
Eg:
terraform_0_11_full -> terraform_0_11.full
PHP5 will be EOLed by the end of the year: https://secure.php.net/supported-versions.php
In fact we don't support PHP5 anymore since 7e6b76fc6b.
The following packages had older versions packaged as well to retain
PHP5 support:
* APCu (4.0.11)
* Memcached (2.2.0), Memcache (3.0.8)
* XDebug (2.3.1)
* YAML (1.3.1)
* pthreads (2.0.10)
* redis (2.2.7)
The following packages were removed entirely due to missing support for
PHP7:
* spidermonkey
* zendopcache (part of PHP itself since 5.5)
* xcache
* geoip
Furthermore I declared `phpPackages.pthreads` as broken for now as it
supports PHP7, but the last release was 2016 and therefore PHP 7.0 is
supported, but the build fails with PHP 7.1 and PHP 7.2 (https://pecl.php.net/package/pthreads).
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSData", referenced from:
objc-class-ref in qmacfunctions.o
"_OBJC_CLASS_$_NSMutableArray", referenced from:
objc-class-ref in qmactoolbar.o
objc-class-ref in qmactoolbardelegate.o
ld: symbol(s) not found for architecture x86_64
FoundationDB uses Python at build time for some code generation.
However, it also has the official python bindings inside the source code
too, and the code for the Python bindings has some of it auto-generated
at compile time.
This made building python packages unattractive: we want to use the
source code generated from the FoundationDB build, but we don't want to
rebuild it. Previously we would override the 'python' input to the
FoundationDB module, but this meant we would do a complete rebuild, as
it was a necessary build time dependency, even though the resulting
generated code itself would not change. Furthermore, FoundationDB
versions < 6.0 don't properly support Python 3 *for the build system*,
though the bindings supported it, so that caused build failures. But the
first effect is the worst: it meant building separate python2 and
python3 packages implied two complete rebuilds of a single FoundationDB
version. This meant rather than 3 FDB builds, we'd do 3*N where N = the
number of major Python versions we support.
Finally, because we did not use pip to generate a wheel that we install
with metadata recorded for the installation, the FoundationDB python
package couldn't be used as an input to other setup.py-based packages:
there would be no recorded metadata in the dist-info folder which would
say this is the foundationdb package. This greatly limits its utility.
To fix all this, we do a few things:
- Apply some patches to fix the build system with Python 3.x for
older FoundationDB versions. (This is nice if end-users have
overridden the global Python version for some reason.)
- Move python directly into nativeBuildInputs, so it is only a
build time dependency.
- Take the python source code from the ./bindings directory and
tar it up use later after the build is done, so we get to keep
the generated code. This is the new 'pythonsrc' output from the
build. This code doesn't change based on whether or not the input
or resulting package is using Python 2 or 3, it's totally
deterministic.
- The build system also patches up the python source code a little,
so it can be installed directly with setup.py (it needs a little
stuff that it normally expects the build system to do.)
- Rework the python package to a separate file that uses
buildPythonPackage directly. Because the source code is already
prepared, it needs almost nothing else. Furthermore, this kills
the override itself for the foundationdb package, meaning rebuilds
are no longer needed.
- This package is very simple and just uses foundationdb.pythonsrc
as its source input. It also ensures a link to libfdb_c.so can
be found by ctypes (using substituteInPlace)
- python-packages.nix now just uses callPackage directly.
The net effect of this is, most importantly, that python packages do not
imply a full rebuild of the server source code: building python2 and
python3 packages from a version of FoundationDB now does not need to
override the foundationdb python input, reducing the number of needless
builds. They instead just run setup.py with the given version as input.
The second biggest effect is that wheel metadata is recorded correctly,
meaning dependent-python-packages that want to use the FoundationDB
bindings e.g. from PyPi should now work fine with buildPythonPackage.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
