Package Details: mullvad-vpn 2024.7-1

Git Clone URL: https://aur.archlinux.org/mullvad-vpn.git (read-only, click to copy)
Package Base: mullvad-vpn
Description: The Mullvad VPN client app for desktop
Upstream URL: https://www.mullvad.net
Licenses: GPL-3.0-or-later
Submitter: gin078
Maintainer: yochananmarqos
Last Packager: yochananmarqos
Votes: 137
Popularity: 2.73
First Submitted: 2018-10-24 17:33 (UTC)
Last Updated: 2024-10-30 16:32 (UTC)

Pinned Comments

yochananmarqos commented on 2022-11-11 19:31 (UTC) (edited on 2022-11-13 19:21 (UTC) by yochananmarqos)

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

yochananmarqos commented on 2019-12-07 17:44 (UTC) (edited on 2024-06-06 22:09 (UTC) by yochananmarqos)

--> ALWAYS DO A CLEAN BUILD <--

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

Please do not create upstream issues about the AUR package, they do not support it.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 45 Next › Last »

Bitals commented on 2024-05-16 15:53 (UTC)

However,

15:52:52     no-publish.diff ... FAILED
15:52:52     mullvad-vpn.sh ... Passed
15:52:52 ==> ERROR: One or more files did not pass the validity check!

Bitals commented on 2024-05-16 15:51 (UTC)

@yochananmarqos thank you!

Bitals commented on 2024-05-16 15:51 (UTC)

@yataro what I meant with "but for CIs not having that will force users to maintain their own fork" is e.g. I, with my own non-Mullwad CI, will have to maintain a fork of this repo, adding your patch to every version released here. Because I can't just throw a random file at Jenkins, it builds from a source repository.

So this change (disabling the publishing) affects CIs (mine for example). This publish action is only useful for Mullvad itself, because it publishes the build artifact to Mullvad Github. Disabling it is a useful change for all other non-Mullvad CIs.

yochananmarqos commented on 2024-05-16 15:48 (UTC)

@Bitals: To avoid things like that, build in a clean chroot. However, I've applied @yataro's patch.

Also, I forgot to specify the node version yesterday. Oops. That's also fixed.

yataro commented on 2024-05-16 15:41 (UTC)

@johnnybash node 22 broke gulp, the build system used for building mullvad electron app... You're left to use LTS node package, which will require users with regular node installed to build the package in chroot, or you can just use nvm.

johnnybash commented on 2024-05-16 15:37 (UTC) (edited on 2024-05-16 15:38 (UTC) by johnnybash)

imho not very reasonably to replace a build dependency from the official repos with an aur only dependency...

yataro commented on 2024-05-16 15:30 (UTC) (edited on 2024-05-16 15:31 (UTC) by yataro)

@Bitals Of course they don't :) What you said: "but for CIs not having that will force users to maintain their own fork." What I was trying to say is that this change doesn't affect ANY user, CI or not. This publish action comes from electron-builder, and only useful for publishing mullvad itself, not an AUR package. So this change from me, doesn't affect CIs, because they ship built package.

Bitals commented on 2024-05-16 15:25 (UTC) (edited on 2024-05-16 15:25 (UTC) by Bitals)

@yataro sorry, I didn't get what you said.

I don't think Mullvad's own CI will use this repo. My environment is a self-hosted Jenkins that builds packages and publishes them to a self-hosted repo. It does not use any Mullvad or some other vendor packaging and/or publishing scripts, it uses makepkg, some pacman built-in scripts like repo-add and aurutils.

yataro commented on 2024-05-16 15:18 (UTC)

@Bitals This change only affects the mullvad publish itself, CIs that publish their mullvad build should use the original repository and not the AUR package :) As for AUR CIs, they publish the built package as an artifact, so also avoid the downside of this change

Bitals commented on 2024-05-16 15:00 (UTC)

@yataro it does work. @yochananmarqos please add this patch, as I see no downsides for regular local builds, but for CIs not having that will force users to maintain their own fork.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 45 Next › Last »