Arch Linux User Repository

--> ALWAYS DO A CLEAN BUILD <--

This package will verify the signature of the git tag. Developer keys are available here and instructions are here. See the PKGBUILD to determine which developer key you need.

Upstream does not support building natively for ARM64, only cross-compiling. You can use mullvad-vpn-beta-bin instead.

@yochananmarqos I figured it out - I had the older nodejs-lts-fermium and npm6 installed (since those are make dependencies for signal-desktop-beta), but everything worked fine once I installed the current nodejs and npm.

Usually paru tells me when I'm missing make dependencies, but somehow this didn't happen for this update.

Edit (Nov 18, 2021): after reinstalling current nodejs &/or npm (with nvm installed), run $ nvm use system.

@reclusivesavage:

info using node@v14.17.4

Where is that coming from? Use the system nodejs and npm.

What can I do?

I received an error when installing with $ makepkg -sirc:

   Compiling tonic v0.5.2
   Compiling mullvad-rpc v0.1.0 (/home/uSER/AUR/mullvad-vpn-beta/src/mullvadvpn-app/mullvad-rpc)
    Finished release [optimized] target(s) in 3m 58s
Generating shell completion script for bash...
    Finished release [optimized] target(s) in 0.16s
     Running `target/release/mullvad shell-completions bash dist-assets/shell-completions/`
Generating shell completion script for zsh...
    Finished release [optimized] target(s) in 0.16s
     Running `target/release/mullvad shell-completions zsh dist-assets/shell-completions/`
Generating shell completion script for fish...
    Finished release [optimized] target(s) in 0.17s
     Running `target/release/mullvad shell-completions fish dist-assets/shell-completions/`
Copying binaries
Updating relay list...
    Finished release [optimized] target(s) in 0.15s
     Running `target/release/relay_list`
Updating API address cache...
    Finished release [optimized] target(s) in 0.18s
     Running `target/release/address_cache`
~/AUR/mullvad-vpn-beta/src/mullvadvpn-app/gui ~/AUR/mullvad-vpn-beta/src/mullvadvpn-app
Installing JavaScript dependencies...
npm ERR! string.prototype.trimend not accessible from es-abstract

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/uSER/AUR/mullvad-vpn-beta/src/npm-cache/_logs/2021-10-13T01_56_31_303Z-debug.log
==> ERROR: A failure occurred in build().
    Aborting...

This was what I found in the log file:

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   '/usr/bin/node',
1 verbose cli   '/usr/bin/npm',
1 verbose cli   'ci',
1 verbose cli   '--cache',
1 verbose cli   '/home/uSER/AUR/mullvad-vpn-beta/src/npm-cache'
1 verbose cli ]
2 info using npm@6.14.15
3 info using node@v14.17.4
4 verbose npm-session 06aab0504f551e2b
5 info prepare initializing installer
6 verbose prepare starting workers
7 verbose prepare installation prefix: /home/uSER/AUR/mullvad-vpn-beta/src/mullvadvpn-app/gui
8 verbose prepare using package-lock.json
9 verbose checkLock verifying package-lock data
10 verbose teardown shutting down workers.
11 info teardown Done in 0s
12 verbose stack Error: string.prototype.trimend not accessible from es-abstract
12 verbose stack     at reqAddr (/usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:159:17)
12 verbose stack     at /usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:129:22
12 verbose stack     at Array.forEach (<anonymous>)
12 verbose stack     at addChild (/usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:128:40)
12 verbose stack     at /usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:133:7
12 verbose stack     at Array.forEach (<anonymous>)
12 verbose stack     at addChild (/usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:128:40)
12 verbose stack     at /usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:133:7
12 verbose stack     at Array.forEach (<anonymous>)
12 verbose stack     at addChild (/usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:128:40)
12 verbose stack     at /usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:133:7
12 verbose stack     at Array.forEach (<anonymous>)
12 verbose stack     at addChild (/usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:128:40)
12 verbose stack     at /usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:113:5
12 verbose stack     at Array.forEach (<anonymous>)
12 verbose stack     at lockTree (/usr/lib/node_modules/npm/node_modules/npm-logical-tree/index.js:107:5)
13 verbose cwd /home/uSER/AUR/mullvad-vpn-beta/src/mullvadvpn-app/gui
14 verbose Linux 5.14.11-1-MANJARO
15 verbose argv "/usr/bin/node" "/usr/bin/npm" "ci" "--cache" "/home/uSER/AUR/mullvad-vpn-beta/src/npm-cache"
16 verbose node v14.17.4
17 verbose npm  v6.14.15
18 error string.prototype.trimend not accessible from es-abstract
19 verbose exit [ 1, true ]

@sdht0: I'm not a polkit expert, therefore what I would do, following your philosophy of having more discretionary groups, I would create a mullvad group, add your user to it, and allow the socket to be controlled by users in this group by editing the service file. Maybe there is a polkit way, but it looks very involved.

@kubrick: I see what you mean. My setup uses the first option, which I only have to unlock once at login.

So how can I configure mullvad-gui to use the same, so that it can connect to the daemon properly?

@sdht0, which of these options are you using to control NM from your user session?

@Rangvar: lto is not enabled by default.

Build fails with LTO enabled Adding options=('!lto') works fine

then they are not going to be able to control anything network related by default on arch

I am able to control my network just fine on Plasma+NetworkManager without my user being in the wheel group.

Yes, of course it is always going to cause some issues to restrict control of the mullvad daemon to the wheel group, and it is a matter of opinion.

But if a user is created without being part of the wheel group, then they are not going to be able to control anything network related by default on arch, so why would they be allowed to control the VPN?

So on the one hand not setting this new option make the default set-up not safe, on the other hand restricting it to the wheel group is going to annoy a few people who have set up their systems in a way that their users can't control the network without elevating their privileges.

Of course I don't know how widespread this is but this seems wrong to me anyway to expect users not to be able to control the network and be able to control VPNs at the same time...