Change:
{ stdenv, fetchurl, buildPythonPackage, pythonPackages, pygtk }: buildPythonPackage { <del> name = "keepnote-0.6.5"; </del> <ins> name = "keepnote-0.7.8"; </ins> namePrefix = ""; src = fetchurl { <del> url = http://rasm.ods.org/keepnote/download/keepnote-0.6.5.tar.gz; sha256 = "0kipcy90r50z4m9p8pyy9wi4dknsiwdrgy974xgakris2rh4lafw"; </del> <ins> url = "http://keepnote.org/download/keepnote-0.7.8.tar.gz"; sha256 = "0nhkkv1n0lqf3zn17pxg5cgryv1wwlj4hfmhixwd76rcy8gs45dh"; </ins> }; propagatedBuildInputs = [ pythonPackages.sqlite3 pygtk ];

Discussion:
Describe the bug In , the path /usr/share/applications is hardcoded, the only way to change it would be to patch the package. However, from I see that the Debian package is used, so fixing this in the source code would require not to use a binary version (I guess). To Reproduce Steps to reproduce the behavior (tested with the package from the channel): the GUI client using the command the following error be thrown in the console: Expected behavior The autostart file is properly symlinked to the nix store package. Additional context I found a dirty fix for this issue, enable the preference and run: However, note that disabling this preference will replace the symlink with the one throwing the error. Notify maintainers Metadata Maintainer information:
I always use sway and just started it that way on launch so I didn't notice. This will probably, as you said, need a change away from the pre-built package. Right now I'm quite busy, but I'll do it soon. Will tag you in the PR so you can test (as I can't...). Did the dir exist before changing the setting?
Hey, I'm working on the client daily, and I'm doing so on NixOS, so maybe I can help with this. Building the package might be a bit involved, since our is a bit involved ,and it relies on a rust toolchain installed by , although this could be worked around with some bash magic to just drop the argument. I personally just have a somewhat involved for building the daemon and then separate FSH environments for running electron builder, but that's because I'm also trying to build for Android and do weird debuggy stuff.
Yes it did since other packages created their own entries beforehand.
Thanks for the insight, So, is this an issue that might make sense to fix in the mullvad-vpn project itself? If not, could you please send me your so I have some guidance when building it?
I must apologize for the hiatus, but life happened. I've been playing around with a somewhat cleaned up nix shell for building all the things for a proper nix package, but there's still some manual labor required. The shell that I use is somewhat similar to , but mine has far more cruft to also do android stuff. And this one could very well be slimmed down further too.

The FSH environment for node is a vain attempt at making and work better, but to make things work, there's still some manual labor involved. The weird wrapping of is there because all the app's build scripts expect rust to be installed via rustup, whereas I use an overlay - so the nix script could be simplified. As long as the rust compiler is new enough, I think the app should build. To build the app, there are 6 parts that need to be built: for when the kernel module is not loaded, built via . Just executing that script on Linux should work just fine. the daemon, the CLI, problem report tool and OpenVPN plugin, should be buildable via , but the binaries end up being quite chonky, so they should all be stripped. Shell completions, the following snippet is copied verbatim from script. Download the relay list via Download the API address list via the electron GUI, built with an gulp that eventually invokes listed is basically a list of things that you must build or adjust so that they work in NixOS. Ideally, one would be able to just invoke , but due to  not building on nixOS (fails due to a node-gyp builder failing to find python) and producing an and a package, some patching would be required. It'd be great if a nix-npm wizard would apply some arcane knowledge to make build, otherwise it can just be removed from , as it's strictly a macOS dependency. Another change you'd probably want to make is to make make an unpacked build rather than producing RPMs and DEBs. The electron binary that's downloaded via will also not run. A dirty hack that I use to make it work is to just replace it with NixOS's one - , but this is not what the app developers are testing against, so there most certainly will be dragons. We build statically linked OpenVPN and Shadowsocks binaries, and those are found in  submodule. I assume these should be patchelf'ed so that they can be used on NixOS, but it seems like just using is not good enough, but doing what the current derivation does will most likely do the trick.

These binaries may be substituted with NixOS native counterparts, but they wouldn't necessarily be equivalent - Mullvad's OpenVPN binaries have some patches that upstream are not interested in and we also try to build the minimal amount of features along with a minimal build of OpenSSL supporting only the ciphersuites that Mullvad servers use. I don't believe we have published the keys we use for signing commits currently, I'll see if we can make that happen. Currently, all the release commits are always signed by the same person - but this may change arbitrarily. After having written all of the above, I'm not entirely sure if making a native package would be worth the effort, given that I can't guarantee that any of the above won't change often. Maybe the best bet would be to make a minimal patch to get electron builder so that can just run. It seems to me that it's only electron/node related scripts that fail on nixOS: the GRPC buildscript fails because it expects to be able to call a downloaded binary from building fails when running probably some other electron quirk The commits are signed by individual developers, the keys are available , one should also make sure to check if the signatures are valid.