Having python3 in the PATH and python2's setuptools and enum in PYTHONPATH
breaks any python3 script. Having mercurial in buildInputs makes this
condition true, breaking glib's python scripts, which after 2.58 use python3.
Mercurial isn't actually needed in buildInputs, so removing mercurial is a
simple fix.
Building glib with selinux support caused the build to fail due to selinux being
specificed in `Required.private` in gio-2.0.pc. `pkgconfigUpstream` isn't
patched to handle `Required.private` properly.
We need to set dontUseImakeConfigure in a few places to prevent imake
from overriding the default configure phase. This packages all have a
configure script that needs to get run:
- Xaw3d
- R
- tkgate
- ssvnc
The original issue can be reproduced when sending with an unpatched
`mutt` or `neomutt` an email with an attachement which as han `.asc`
extension. This will be interpreted as `application/pgp-encrypted` which
experiences special logic, in the end the attachement will contain
"Version: 1"[1][2][3]
Right now, there are the following issues in the {,neo}mutt packages:
* `mutt.override { smimeSupport = true }` fails to build since the
Debian patch results in a 404. Debian moved their packages to
`salsa.debian.org`.
However we can't use a versioned URL for this as Debian only tracks
the Mutt versions that are available in their releases. The patch
doesn't touch Mutt's core and is therefore simple to rebase, so
sticking to the 1.10.2 patch for now should be sufficient.
* The original issue was never fixed in NeoMutt, currently we use the
S/MIME database from `pkgs.mime-types` which contains the issue with
`application/pgp-encrypted` as well.
After some discussion[4] it seems to be the best decision to use the
`mailcap` database distributed by Fedora[5] which fixes the issue
rather than `mime-types` v9 from 2012.
[1] https://bugs.archlinux.org/task/43319
[2] https://bugs.gentoo.org/534658
[3] https://github.com/neomutt/neomutt/blob/neomutt-20180716/sendlib.c#L490-L496
[4] https://github.com/NixOS/nixpkgs/pull/50927#issuecomment-441383260
[5] https://pagure.io/mailcap
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;
})
```
Helm uses its version to determine what version of Tiller (the server
component) to install. Without this patch it thinks it is `v2.11+unreleased` and
tries to download `gcr.io/kubernetes-helm/tiller:v2.11`. After the patch it
correctly downloads `gcr.io/kubernetes-helm/tiller:v2.11.0`. Fixes#49120.
Jan Tojnar
Tor Hedin Brønner
Frederik Rietdijk
Matthew Bauer
Renaud
volth
worldofpeace
Maximilian Bosch
rht
Eric Bailey
Daniel Fullmer
Michael Weiss
José Romildo Malaquias
Will Dietz
Jörg Thalheim
Benjamin Staffin
Vladimír Čunát
Stephen
Robert Schütz
Michael Raskin
Jörg Thalheim
lewo
sjau
Teo Klestrup Röijezon
Martin Lu
hyperfekt
R. RyanTM
Chris Ostrouchov