Please provide instructions on building mozillavpn on Linux without a proprietary toolchain

[volkertb]

Dear Mozilla developers,

Is the Mozilla VPN client open source or not?

Because if it is, why are the Linux build instructions making me jump through these arcane and unconventional hoops by having me install miniconda and running the commercial Qt installer, which also forces me to create a Qt account, even for open source use?

Also, even after doing all of that, I still end up with errors. (See below.)

This is on Clear Linux OS, version 42410.

Not only are you forcing me to build the Mozilla VPN client yourself (since you keep insisting that "Ubuntu is Linux"), but you're making the Linux build process non-trivial as well.

Is miniconda really necessary? It's used for data science and AI purposes. Why should it be needed as part of the build toolchain? Just CMake, with perhaps a Python script here and there, should be enough.

And instead of having to use Qt's installer application, just having the Qt 6.x development dependencies installed through our distros' package managers should be sufficient.

To summarize my frustrations: why do you continue to make it so damn hard for non-Ubuntu Linux users?

Please stop focusing on only Ubuntu and instead offer the original Mozilla VPN application binary in a distro-neutral package format (Flatpak or AppImage) format already!

$ cmake -S . -B build -DCMAKE_PREFIX_PATH=$HOME/Qt/gcc_64/lib/cmake/
Configuring for Unix Makefiles
Setting build type Debug
APP_VERSION=2.25.0
-- The C compiler identification is GNU 14.2.1
-- The CXX compiler identification is GNU 14.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- clang-tidy: The -DCMAKE_EXPORT_COMPILE_COMMANDS=ON flag is not set. Linting will be skipped.
Generated BUILD_ID: 2.202409281533
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Performing Test HAVE_STDATOMIC
-- Performing Test HAVE_STDATOMIC - Success
-- Found WrapAtomic: TRUE
-- Found OpenGL: /usr/lib64/libOpenGL.so
-- Found WrapOpenGL: TRUE
-- Found XKB: /usr/lib64/libxkbcommon.so (found suitable version "1.7.0", minimum required is "0.5.0")
-- Found WrapVulkanHeaders: /usr/include
-- Could NOT find Qt6Qml (missing: Qt6Qml_DIR)
CMake Warning at CMakeLists.txt:120 (find_package):
  Found package configuration file:

    /usr/lib64/cmake/Qt6/Qt6Config.cmake

  but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be NOT
  FOUND.  Reason given by package:

  Failed to find required Qt component "Qml".

  Expected Config file at "/usr/lib64/cmake/Qt6Qml/Qt6QmlConfig.cmake" does
  NOT exist



  Configuring with --debug-find-pkg=Qt6Qml might reveal details why the
  package was not found.

  Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some
  of the path variables that find_package uses to try and find the package.



-- Could NOT find Qt6NetworkAuth (missing: Qt6NetworkAuth_DIR)
CMake Warning at CMakeLists.txt:136 (find_package):
  Found package configuration file:

    /usr/lib64/cmake/Qt6/Qt6Config.cmake

  but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be NOT
  FOUND.  Reason given by package:

  Failed to find required Qt component "NetworkAuth".

  Expected Config file at
  "/usr/lib64/cmake/Qt6NetworkAuth/Qt6NetworkAuthConfig.cmake" does NOT exist



  Configuring with --debug-find-pkg=Qt6NetworkAuth might reveal details why
  the package was not found.

  Configuring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some
  of the path variables that find_package uses to try and find the package.



Using Qt version 6.7.2
-- Found OpenSSL: /usr/lib64/libcrypto.so (found version "3.3.2")
Building sentry for Linux
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.2.0")
-- Checking for module 'libcap'
--   Found libcap, version 2.70
-- Checking for module 'libsecret-1'
--   Found libsecret-1, version 0.21.4
-- Checking for module 'systemd'
--   Found systemd, version 255
CMake Error at src/ui/CMakeLists.txt:5 (qt_add_qml_module):
  Unknown CMake command "qt_add_qml_module".


-- Configuring incomplete, errors occurred!

[oskirby]

I agree, these build instructions are horrifically out of date, and I appologize. I will attempt to write up something a little bit better and more modern.

To address some of your criticisms.

I don't personally use Conda during Linux development, we have been using this for our Apple and Windows targets as a place to centrally manage dependencies, specifically to collect the Python modules, golang and rust tooling into one place. For Linux it should be sufficient to ensure that the build-dependencies (either from linux/debian/control for .deb based distros, or linux/mozillavpn.spec for RPM based distrios) are satisfied, and then install the python modules from requirements.txt.

We initially decided to cite the Qt installer as our recommended way to install Qt because the oldest distro we need to support (Ubuntu 20.04/Focal) doesn't include Qt6. But times have changed an nearly all distibutions supply a usable version of Qt6. So this section should probably be written to recommend installation from the Distribution package manager and to remove the references to the Qt installer.

Qt is in fact an open source project, and we use it under the terms of the LGPL license under which it is distributed. Unfortunately though, they don't offer any download links to compiled versions of this software (they really want to steer everyone towards creating Qt accounts and pushing the commercial version). This makes it feel significantly less open source.

[oskirby]

As for better alternatives. I actually really like Flatpaks and I have been doing my best to maintain the manifests to build them in the linux/flatpak directory. This has been a bit of a side-project of mine and I would like to start making an effort to getting them onto flathub in the next release or two - but I can't really promise much of a timeline for that as it only gets worked on when I am outside of my work hours.

One downside of the flatpaks though is that they don't allow us to perform split tunneling (this requires significantly more permissions than the sandbox will permit). So making use of the Flatpak versions of the VPN client comes at the cost of some features.

[volkertb]

Thanks for the explanation and clarification. And for your efforts to improve all this, of course.

As for the split tunneling limitation in the Flatpak sandbox, would it make sense to open a feature ticket for this at the Flatpak project? (Perhaps you or someone else has already done so.)

Even with the reduced features, having MozillaVPN available as a Flatpak would still be worth it, IMO.

[volkertb]

Also, as discussed in another issue a while back, I would really recommend that you decouple the UI from the core application, and allow the official MozillaVPN to be used from the command line or through a locally running web console, without having to compile the client with QT6 dependencies.