Speedrunning setting up a plasma-nm development environment
Why did I set up a plasma-nm development environment in the first place?
Why did I want to contribute changes to plasma-nm?
If you have peaked at my GitHub profile or activity, you probably know a couple of things about me.
- I do not use Plasma or GNOME but rather Xmonad.
- I mostly focus on kernel development and related low-level subjects these days.
So why would I bother contributing to plasma-nm
? Well, the company that pays
me for my day job uses Cisco AnyConnect as the VPN solution. From our company's
IT management perspective, Cisco AnyConnect "supports" Windows, macOS, and
Linux. The Linux client does not meet our needs, and we need to support FreeBSD
development as well. We depend heavily on the openconnect reverse-engineered
alternative. The company uses a strict SSO model backed by Microsoft Identity
Platform services. Support for SSO flows is available through the AnyConnect
ecosystem through the SAML mechanism, which openconnect has implemented in
recent years. There are two possible flows/algorithms for the SAML model with
AnyConnect. One flow involves needing to feed cookies programmatically back into
libopenconnect
for the authentication browser to succeed. The other flow
involves redirecting a base64 blob that was generated through an authentication
process done in a browser like Firefox or Chromium back to a localhost server
run by openconnect for the sake of IPC with the external browser program. While
the latter flow is much easier to utilize by users with no additional code
changes required to be used, Cisco limits the external browser flow to newer
hardware devices in their product model. This means supporting both flows is an
important task for providing support for a variety of users.
My personal motivation for adding this support was to empower young college
students and academics who are interested in developing Linux but need to
utilize their IT infrastructure in their institutions at the same time. Using
AnyConnect/GlobalProtect on Linux platforms tends to not be viable for students,
leading them to depend on openconnect
. A number of academic institutions have
now started enforcing SSO flows for their VPN login flows. Not having the bits
needed to support the cookie-based SSO authentication flow using plasma-nm
along with openconnect
would be disastrous for students using the Plasma
environment.
Why not use NixOS like I normally do for working on random projects?
Recapping, the reason I use NixOS is that it empowers me with the ability to
rapidly work on complex upstream open source projects without needing to waste
large amounts of time with development environment setup to be able to rebuild
and use those projects from source. The first two features I authored for adding
both SAML external browser flows and SAML built-in browser flows for plasma-nm
were actually tested on NixOS, where I was able to work on these features
without spending much time due to how quickly NixOS let me test my plasma-nm
tree with zero manual setup work. I just passed a pointer to my local
plasma-nm
tree, and NixOS took care of the rest for letting me test my
plasma-nm
changes. I do not like MIS-type problems, which I feel NixOS
eliminates in a lot of cases.
The reason I did not continue using NixOS for plasma-nm
development is that
NixOS will base its dependencies off of released versions. With the Plasma 5.27
freeze to focus on the Plasma 6 efforts, the upstream codebase for Plasma
components and frameworks heavily diverged from the 5.27 release components. To
be able to get an upstream version of plasma-nm compatible with NixOS, I would
need to rebuild a lot of dependencies from source. This is something that I did
not want to burn time on. Recently, there has been work on a kde2nix packaging
(which has now been upstreamed), but I was always running into cache misses,
etc., and saw a lot of rebuilding from source.
Shortcutting the work needed to get a plasma-nm development environment
Now, it's time to speedrun getting a plasma-nm
development environment.
- Install the KDE Neon Developer Edition image (likely something like Arch Linux can work as well)
- Set up
kdesrc-build
using the wiki guide (NOTE:kde-builder
is a drop-in replacement forkdesrc-build
that is being tested at the time of writing this article) - Set up a development environment with kdesrc-build or kde-builder
- Build software with kdesrc-build
- The examples shown in the guide in step 4 all use
kdesrc-run
with very isolated GUI programs. You will likely notice thatplasma-nm
cannot be tested the same way. - We will do
kdesrc-build plasma-nm
to build all theplasma-nm
KDE frameworks dependencies. I actually just note the dependencies manually andkdesrc-build
each one, but that involves reading the CMake files in theplasma-nm
project. The point of this article is speedrunning getting started withplasma-nm
development. - In a directory outside the
~/kde
directory,git clone https://invent.kde.org/plasma/plasma-nm.git && cd plasma-nm
mkdir build
cd build
cmake ../ -DCMAKE_FIND_ROOT_PATH=~/kde/ -DCMAKE_INSTALL_PREFIX=/usr [-DDISABLE_MODEMMANAGER_SUPPORT=true]
make
sudo make install
- Restart the plasma shell for the new
plasma-nm
instance to be loaded (I login-logout as my mindless speedrunning solution).
The big thing to notice is that my testing flow is heavily based on the
plasma-nm README. The main thing I did was simplify handling the dependencies
using kdesrc-build
. I originally considered compiling and installing all the
KDE frameworks dependencies and transitive dependencies by hand. It proved to be
overwhelming. Instead, I depend on kdesrc-build
to do this on my behalf and
use -DCMAKE_FIND_ROOT_PATH=~/kde/
to let CMake lookup the pre-builts of the
KDE frameworks dependencies made by kdesrc-build
.