[docs] snap wisdom + contribution ideas

3 files changed, 60 insertions, 13 deletions

diff --git a/docs/build-snap-canonical.rst b/docs/build-snap-canonical.rst
new file mode 100644
index 0000000..f4aa967
--- /dev/null
+++ b/docs/build-snap-canonical.rst
@@ -0,0 +1,38 @@
+git integration
+===============
+
+All seems to be more smooth with the "new" (ahem) github integration (once things *are* working).
+
+Some tips:
+
+- We've got different repos. `riseup-vpn-snap` is the *snap* repo. Import code from upstream, just merge it with `-X theirs`
+- If the snap doesn't change, just use `make bump_snap` for upgrading the version from git (TODO we could write this also into the hardcoded version).
+- Otherwise, just do `make vendor` and import the snapcraft.yaml generated from the template.
+
+
+local builds
+------------
+multipass is the recommended way, but canonical does use lxd so at times some paths etc change.
+For your own sanity:
+
+- get a zfs pool on a fast device, and get yourself acquainted with lxd to use that pool.
+- don't get too frustrated with networking + lxd. restarting any iptables in your host (if using bridges) usually helps.
+- you can use `make local_snap` to use your local lxd infra. it launches with
+  `--debug`, so you'll be dropped into a local shell to see what the fuck the
+  manual build of Qt is complaining about.
+
+
+existential helpline
+--------------------
+* don't despair. we've all been there.
+* snapcraft forum is useful.
+* all tech is crap: don't think that you'll be happy reimplementing the whole
+  app in electron or whatnot. just don't. enjoy life while you can.
+* https://forum.snapcraft.io/t/the-sorry-state-of-snapping-qt5-apps/22809
+* https://github.com/mozilla-mobile/mozilla-vpn-client/blob/main/scripts/qt5_compile.sh
+
+if you have some time
+---------------------
+* look into a `clang` build. qt builds fine, but last time I tried there was
+  some incompatible version (?) that didn't let the qmake build finish.
+
diff --git a/docs/build-snap-launchpad.rst b/docs/build-snap-launchpad.rst
deleted file mode 100644
index 0a614f6..0000000
--- a/docs/build-snap-launchpad.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-launchpad
-=========
-In launchpad, you need to configure a git source for your project, and define a snap recipe for that source.
-
-Be warned that launchpad does an automatic import every 6 hours.
-
-If you need to do manual builds, you first need to trigger an import. Look for the "import now" button in your source page:
-
-https://code.launchpad.net/~leapsnaps/riseupvpn/+git/riseup_vpn
-
-Then you can trigger a manual build:
-
-https://code.launchpad.net/~leapsnaps/+snap/riseup-vpn/+request-builds
diff --git a/docs/contribution-ideas.md b/docs/contribution-ideas.md
new file mode 100644
index 0000000..b263b0e
--- /dev/null
+++ b/docs/contribution-ideas.md
@@ -0,0 +1,22 @@
+# I have time, how can I help?
+
+## Packaging
+
+* Look into `AppImage` + https://github.com/probonopd/linuxdeployqt.
+  We've not considered that option too much in the past, but it might give us
+  a decent, self-contained alternative to snap etc.
+ 
+## Linux
+
+* Revamp vpn helper architecture: there're problems, of course, but we can try
+  to isolate the client gui from the vpn helper itself (and "ship it" as
+  a binary under the single bundle, as I do now with bitmak-root). An idea
+  that's been floating around for a long time is to recycle the helper
+  interface, and have a long-lived privileged helper that does the vpn
+  connection using openvpn3 libr.
+
+  elijah was initially supporting a short-lived helper (what we have right now
+  with bitmask-root), but perhaps the integration can be done right with pkexec
+  or otherwise (separate users in linux etc). This has the additional advantage
+  of allowing us to do a very early startup, and not to depend so much on
+  pkexec + ubuntu's quirks (portability!).