[i-love-my-pinephone] Draft section on porting, popular opinion

1 files changed, 477 insertions, 26 deletions

diff --git a/org/I Love My PinePhone/i-love-my-pinephone.org b/org/I Love My PinePhone/i-love-my-pinephone.org
index 670453a..0347c6d 100644
--- a/org/I Love My PinePhone/i-love-my-pinephone.org
+++ b/org/I Love My PinePhone/i-love-my-pinephone.org
@@ -278,7 +278,7 @@ analogs on PostmarketOS.
 | Clock                    | [[https://gitlab.gnome.org/GNOME/gnome-clocks][gnome-clocks]]            |                                                                                       |
 | Contacts                 | [[https://gitlab.gnome.org/GNOME/gnome-contacts][gnome-contacts]]          |                                                                                       |
 | Conversations            | [[https://wiki.postmarketos.org/wiki/Dino][dino]]                    | Unused in PostmarketOS.[fn:4]                                                         |
-| Discord                  | [[https://github.com/diamondburned/gtkcord4][gtkcord4]]                | currently unused.[fn:5]                                                               |
+| Discord                  | [[https://github.com/diamondburned/gtkcord4][gtkcord4]]                | Discord sucks and I hate it, but I have friends who prefer it, so I have to settle.   |
 | Email                    |                         | Unused on Android.                                                                    |
 | F-Droid                  |                         | Android-specific application                                                          |
 | FFUpdater                |                         | Android-specific application                                                          |
@@ -467,20 +467,63 @@ the web or check my email. It was [[https://forum.pine64.org/showthread.php?tid=
 ** On-screen Keyboard
 
 This is a difficult issue to put into words, and as such I've had a hard time
-looking around for mention of it on the internet.
+looking around for mention of it on the bug tracker or elsewhere.
 
 Sometimes, when typing with [[c9ed5147c6d4af76366ee706cdd3dfee3a7b0e14ac0789b24d2a701f2455d0e8ef3bf377bb07ad4dfb2121e5d62877c014b5bbb3c7e24931cdf75bd702f897c43462eaddd6cf255431367b2956a8cb7b26984ed2de05d37efd32068ec15538f2][Squeekboard]] (the on-screen keyboard that comes with
 Phosh), I'll press a key once and two characters will be inserted -- as if the
 phone registered it as two taps in quick succession.
 
-# TODO: Attempt to find mention of it in the bug tracker.
+A solution I'd like to try is to patch Squeekboard and have it keep a timer for
+determining how much time there elapses between key press events. If the pause
+is too short, then we'd drop the second key press. Squeekboard seems to be
+mostly written in Rust, so I find that to be an enticing quality-of-life
+improvement project, but I think I've done enough technical work in this post
+already, so I'll do it another time.
 
-** Bluetooth sucks
+** Bluetooth Audio
 
-# TODO
+# TODO: This section needs to be updated.
+# Procedure:
+# 1. `nice -11 mpd`
+# 2. `mpc play`
+# 3. `pkill mpd`
+# 4. `nice -11 mpd`
+# 5. Music starts playing without hiccups.
+
+Bluetooth audio remains a pain point, and an elusive one at that. It works only
+when attempting to troubleshoot -- never when I actually want to use my
+PinePhone as a Bluetooth audio source. The [[https://wiki.archlinux.org/title/Bluetooth_headset#Connecting_works,_but_there_are_sound_glitches_all_the_time][Arch Linux Wiki has a page]] on
+troubleshooting my situation, which is that "[c]onnecting works, but there are
+sound glitches all the time." In my case, I have no issues connecting to my
+car's stereo system, for example, but 90% of the time I will have audio buffer
+overruns that cause the audio to pause every second or so. It is infuriating to
+have to listen to.
+
+[[# https://forum.pine64.org/showthread.php?tid=10810][CyberSeb on the PINE64 forum has a post]] for configuring the Bluetooth stack to
+work better, and I have some recollection of the second step working well, but
+as of late the script I have to run those commands (included below) no longer
+works. It tends to fail at =pactl set-port-latency-offset=, either because
+=BLUEZCARD= isn't defined, or something else. The error messages are hardly
+deterministic.
+
+I've added some debugging output and the good ol' song and dance for making Bash
+less shitty, in hopes that I'll be able to get more data the next time I run it.
+
+#+BEGIN_SRC sh
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+BLUEZCARD=`pactl list cards short | egrep -o bluez.*[[:space:]]`
+echo "Determined BLUEZCARD to be $BLUEZCARD"
+pactl set-port-latency-offset $BLUEZCARD headset-output 100000
+sudo service bluetooth restart
+#+END_SRC
+
+It's a little strange that I mentioned only using the second step. This is
+because I was convinced that my phone wasn't running Pulse. I really thought it
+was on Pipewire, but it seems my memory failed me.
 
-# https://forum.pine64.org/showthread.php?tid=10810
-Switch to pulseaudio :(
 #+BEGIN_SRC prog
 theta:~$ sudo apk add pipewire-pulse
 ERROR: unable to select packages:
@@ -489,6 +532,12 @@ ERROR: unable to select packages:
     satisfies: world[pipewire-pulse] gnome-settings-daemon-42.1-r0[pulseaudio] postmarketos-base-ui-gnome-1-r3[pulseaudio] gnome-session-42.0-r1[pulseaudio-alsa]
 #+END_SRC
 
+It's Pulse, and I'm hesitant to screw with it's niceness because it does not
+have a reputation of being resourceful or performant. I'm wondering if these
+issues would go away if I /did/ switch over to using Pipewire, but the error from
+=apk= above makes me think that it would be a hard nut to crack. I've tried
+[[https://wiki.archlinux.org/title/PulseAudio/Troubleshooting#Setting_the_default_fragment_number_and_buffer_size_in_PulseAudio][setting a default fragment size]] in Pulse as a more reasonable workaround while I
+wait for Pulse to eventually die a slow and painful death.
 
 ** Cross Compiling Woes
 
@@ -791,13 +840,14 @@ when a video is playing, but this is easily remedied by prefixing =mpv= with
 
 ** Better Music Player
 
-AOSP has a [[https://android.googlesource.com/platform/packages/apps/Music/][Music]] app, and that's what I used when I was on Android. I didn't see
-a use in using any other music player since they all seem to use the same
-Android APIs and, hence, all suck as much as Music does. Among other things, it
-cuts out frequently (presumably the process getting killed due to memory
-pressure), and it can't even load a damned jpeg.
+LineageOS included the old Cyanogenmod Music app [[https://github.com/CyanogenMod/android_packages_apps_Eleven][Eleven]], and that's what I used
+when I was on Android. I didn't see a use in using any other music player since
+they all seem to use the same Android APIs and, hence, all suck as much as
+Eleven does. Among other things, it cuts out frequently (presumably the process
+getting killed due to memory pressure), and it can't even load a damned jpeg.
 
-# TODO: Picture
+#+CAPTION: Album artwork being mangled by some bug unknown to me.
+[[./Music on Zeta.png]]
 
 So I was quite happy to be able to use =mpd= to listen to music on the PinePhone.
 My entire library's managed with Syncthing.
@@ -898,10 +948,7 @@ the PinePhone. GTK is relatively performant, but I'm curious about whether
 something like [[https://github.com/emilk/egui][egui]] would be "snappier". Hell, maybe it would be interesting to
 try and write my own UI framework.
 
-# TODO: Bring this down there and comment on boilerplate.
-# I'd also like to try using [[https://github.com/Relm4/Relm4][Relm4]] and [[https://github.com/bodil/vgtk][vgtk]]. It's fun to experiment with these sorts of things.
-
-** "Tunes", an MPD Client for Rust
+*** "Tunes", an MPD Client for Rust
 
 To demonstrate the GTK3 and libhandy combo, I decided to write the minimum
 viable product of an application I want on my PinePhone that, to my knowledge,
@@ -926,7 +973,7 @@ as well.
 #+END_EXPORT
 
 #+BEGIN_SRC rust
-// Copyright © 2021-2022 Jakob L. Kreuze <[REDACTED (to foil web scrapers)]>
+// Copyright © 2021-2022 Jakob L. Kreuze <[REDACTED]>
 //
 // This file is part of Tunes.
 //
@@ -1714,7 +1761,7 @@ try it out on the phone.
 =pmbootstrap= comes with a nice =hello-world-rust= =APKBUILD= to get you started with
 packaging your Rust application.
 
-#+BEGIN_SRC prog
+#+BEGIN_SRC sh
 # Maintainer: Oliver Smith <[REDACTED]>
 pkgname=hello-world-rust
 pkgver="0.1.1"
@@ -1748,7 +1795,7 @@ I copied this over to a new directory under =cache_git= named =tunes=, threw my
 source tree into a tarball, and edited the template =APKBUILD= to declare the
 dependencies my application would need.
 
-#+BEGIN_SRC prog
+#+BEGIN_SRC sh
 # Maintainer: Jakob L. Kreuze <[REDACTED]>
 pkgname=tunes
 pkgver="0.1.1"
@@ -1803,7 +1850,12 @@ Final thoughts? That was much more pleasant than anything I've done in Android
 land. I've got an application that's actually useful to me that didn't take me
 more than a week -- a week where I was working late most nights, mind you.
 
-*** Comments on the =mpd= interactions
+It's still a proof-of-concept rather than a battle-tested application, ready for
+packaging upstream, but it's enough to go off of. I'm expecting to continue
+working on it, but I might pull in [[https://github.com/Relm4/Relm4][Relm4]] or [[https://github.com/bodil/vgtk][vgtk]] to cut down on some of the
+boilerplate and event loop spaghetti.
+
+**** Comments on the =mpd= interactions
 
 You may notice that I've vendored the entire =mpd= crate into the the =tunes=
 repository. In short: the =mpd= crate is pretty old and a little broken. I ran
@@ -1842,6 +1894,388 @@ But, really, these sorts of things make me want to be more involved in the
 community. Maybe I'll do something related to mobile Linux for my master's
 thesis.
 
+** Porting Software
+
+What follow from "it's easy to develop for the PinePhone because you're writing
+applications as if you were writing them for your workstation" is that it should
+be relatively easy to port existing applications as well. And this is indeed the
+case. The compile times brought me great pain, but I was successful in
+cross-compiling [[https://github.com/diamondburned/gtkcord4][diamondburned's gtkcord4]], which has no existing Alpine package
+to my knowledge, to run on the PinePhone.
+
+#+BEGIN_SRC sh
+# Contributor: Jakob L. Kreuze <[REDACTED]>
+# Maintainer: Jakob L. Kreuze <[REDACTED]>
+pkgname=gtkcord4
+pkgver=0.0.2
+pkgrel=0
+pkgdesc="GTK4 Discord client in Go"
+url="https://github.com/diamondburned/gtkcord4"
+arch="all"
+license="GPL-3.0"
+makedepends="gtk4.0-dev gobject-introspection-dev libcanberra-dev go"
+source="$pkgname-$pkgver.tar.gz::https://github.com/diamondburned/gtkcord4/archive/refs/tags/v${pkgver}.tar.gz"
+
+build() {
+    go build
+}
+
+package() {
+	install -D -m755 $pkgname "$pkgdir"/usr/bin/$pkgname
+}
+
+sha512sums="
+1c0465f4c2d54794551811c0a536b610a51d3f795c403af3cf10954a46770b42d1aadef4709818f935aa54e2b413052546bdde5214f44e89d5ad2e2d7cbdf514  gtkcord4-0.0.2.tar.gz
+"
+#+END_SRC
+
+The above is all it took. I initialized =pmbootstrap=, made a directory named
+=gtkcord4= under =cache_git/pmaports/main=, ran =pmbootstrap build --arch,=aarch64
+gktcord4=, and a couple hours later and I had a =gtkcord4-0.0.2-r0.apk= sitting
+under =packages/v21.12/aarch64=.
+
+I'm not sure diamondburned ever anticipated that gtkcord4 would be running on a
+mobile device, but thanks to their choice to use GTK4, I didn't have to make any
+changes to the code and it still runs great on my device.
+
+#+CAPTION: gtkcord4 running on the PinePhone, showing a conversation between myself and my friend.
+#+attr_html: alt="[10:46 AM] Jakob: If you managed to get enough samples, do you think you could do a TEMPEST-like attack on USB?\n[10:47 AM] Ergodic: I don't see why not\n[10:47 AM] Jakob: Or serial, or any other standard where the connection doesn't have a lot to keep it from being leaky\n[10:47 AM] Ergodic: I think Israel can dump ram from far away right?\n[10:47 AM] Ergodic: So pretty much anything\n[10:47 AM] Ergodic: Well\n[10:48 AM] Ergodic: Actually\n[10:48 AM] Ergodic: Wait\n[10:48 AM] Ergodic: With um\n[10:48 AM] Ergodic: A HdMI it doesn't matter if some data is wrong cuz you can keep resampling, same with ram\n[10:48 AM] Ergodic: But you can't with USB unless they're doing the same thing 40 times in a row 👀\n[10:49 AM] Ergodic: Like depending on the protocol, how accurate do you wanna be"
+[[./gtkcord4 on PinePhone.png]]
+
+Some applications might need to be modified to work well on a touchscreen. I
+haven't had to do that yet, and even if I did, I would expect it to be a
+difficult topic to cover in this (already quite long) article. The part that I
+will elaborate on is how we got to that magic code block above. The gtkcord4
+example is a little boring because of how little it takes to invoke the Go build
+system,[fn:14] so let's port [[https://openxcom.org/][OpenXCOM]] instead. I'll start from scratch and
+document my process as I go.
+
+Speaking of process, this is basically what I follow:
+
+1. Determine if the software in question is already packaged in another
+   source-based distribution (basically Gentoo or the Arch AUR).
+   1. If so, translate the recipe to APKBUILD. In the case of Gentoo, figure out
+      what set of =USE= flags "make sense" as a default.
+   2. Use [[https://pkgs.alpinelinux.org/packages][pkgs.alpinelinux.org]] to map each dependency in the original package
+      spec to an Alpine dependency.
+2. If it isn't...
+   1. Find a skeleton APKBUILD (like the "hello world" example in the
+       [[*Building and Installing the Application on PostmarketOS]["Building and Installing the Application on PostmarketOS"]] section).
+   2. Fill it in with the instructions to compile from upstream. I find you need
+      to specify =build= and =package= as the bare minimum if you explicitly disable
+      =check=.
+   3. Guess-and-check for dependencies. Sometimes upstream will be good about
+      enumerating them, sometimes not so much.
+
+I know that [[https://packages.gentoo.org/packages/games-engines/openxcom][openxcom is packaged in Gentoo]], so we'll start there.
+
+#+BEGIN_SRC sh
+# Copyright 1999-2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit cmake xdg-utils
+
+DESCRIPTION="Open-source reimplementation of the popular UFO: Enemy Unknown"
+HOMEPAGE="https://openxcom.org/"
+
+if [[ ${PV} == *9999 ]]; then
+	inherit git-r3
+	EGIT_REPO_URI="https://github.com/SupSuper/OpenXcom.git"
+else
+	COMMIT="ea9ac466221f8b4f8974d2db1c42dc4ad6126564"
+	SRC_URI="https://github.com/SupSuper/OpenXcom/archive/${COMMIT}.tar.gz -> ${P}.tar.gz"
+	KEYWORDS="~amd64 ~arm64 ~x86"
+	S="${WORKDIR}/OpenXcom-${COMMIT}"
+fi
+
+LICENSE="GPL-3+ CC-BY-SA-4.0"
+SLOT="0"
+IUSE="doc"
+
+RDEPEND="
+	>=dev-cpp/yaml-cpp-0.5.1
+	media-libs/libsdl[opengl,video]
+	media-libs/sdl-gfx
+	media-libs/sdl-image[png]
+	media-libs/sdl-mixer[flac,mikmod,vorbis]"
+DEPEND="${RDEPEND}"
+BDEPEND="doc? ( app-doc/doxygen )"
+
+DOCS=( README.md )
+
+src_compile() {
+	cmake_src_compile
+	use doc && cmake_build doxygen
+}
+
+src_install() {
+	use doc && local HTML_DOCS=( "${BUILD_DIR}"/docs/html/. )
+	cmake_src_install
+}
+
+pkg_postinst() {
+	xdg_icon_cache_update
+
+	elog "In order to play you need copy GEODATA, GEOGRAPH, MAPS, ROUTES, SOUND,"
+	elog "TERRAIN, UFOGRAPH, UFOINTRO, UNITS folders from original X-COM game to"
+	elog "/usr/share/${PN}/UFO"
+	elog
+	elog "If you want to play the TFTD mod, you need to copy ANIMS, FLOP_INT,"
+	elog "GEODATA, GEOGRAPH, MAPS, ROUTES, SOUND, TERRAIN, UFOGRAPH, UNITS folders"
+	elog "from the original Terror from the Deep game to"
+	elog "/usr/share/${PN}/TFTD"
+	elog
+	elog "If you need or want text in some language other than english, download:"
+	elog "https://openxcom.org/translations/latest.zip and uncompress it in"
+	elog "/usr/share/${PN}/common/Language"
+}
+
+pkg_postrm() {
+	xdg_icon_cache_update
+}
+#+END_SRC
+
+Although I probably should, I'm not going to bother with =postinst= or =postrm=
+right now. I'm also not going to build the docs. What we can tell immediately is
+that this is a CMake project (so we should find an =APKBUILD= for something else
+that uses cmake) and the dependencies are the following:
+
+- =yaml-cpp=
+- =sdl=
+- =sdl_gfx=
+- =sdl_image=
+- =sdl_mixer=
+
+All of these are packaged in Alpine except =sdl_mixer=, so we'll need to port that
+ourselves. I was able to take the =APKBUILD= for =sdl_mixer= and use that as a
+skeleton. The packages are packaged very similarly, so I was able to fill in the
+blanks with some of the info from the [[https://packages.gentoo.org/packages/media-libs/sdl-gfx][Gentoo package]].
+
+#+BEGIN_SRC sh
+# Contributor: Jakob L. Kreuze <[REDACTED]>
+# Maintainer: Jakob L. Kreuze <[REDACTED]>
+pkgname=sdl_gfx
+pkgver=2.0.26
+pkgrel=3
+pkgdesc="Graphics drawing primitives library for SDL"
+url="https://www.ferzkopp.net/wordpress/2016/01/02/sdl_gfx-sdl2_gfx/"
+arch="all"
+license="zlib"
+makedepends="sdl-dev"
+subpackages="$pkgname-dev"
+source="http://www.ferzkopp.net/Software/SDL_gfx-2.0/SDL_gfx-$pkgver.tar.gz"
+builddir="$srcdir"/SDL_gfx-$pkgver
+
+prepare() {
+    default_prepare
+    update_config_sub
+    update_config_guess
+}
+
+build() {
+	./configure \
+		--build=$CBUILD \
+		--host=$CHOST \
+		--prefix=/usr \
+		--sysconfdir=/etc \
+		--mandir=/usr/share/man \
+		--infodir=/usr/share/info
+	make
+}
+
+package() {
+	make DESTDIR="$pkgdir" install
+}
+
+sha512sums="e571caa0d7575683efd4cf8f0a41ab10f4acf913f9ece216ac823af11da22c8734fc2c0ea049009a3e1a53715e49622f5bfcfdbdafb95e5151990d0a4eb69c01  SDL_gfx-2.0.26.tar.gz"
+#+END_SRC
+
+It took a little bit of trial and error to arrive at the =APKBUILD= above. I first
+ran into an issue with autotools not recognizing the target platform.
+
+#+BEGIN_SRC prog
+>>> sdl_gfx: Building pmos/sdl_gfx 2.0.26-r3 (using abuild 3.9.0-r0) started Tue, 23 Aug 2022 01:28:27 +0000
+>>> sdl_gfx: Checking sanity of /home/pmos/build/APKBUILD...
+>>> sdl_gfx: Cleaning up srcdir
+>>> sdl_gfx: Cleaning up pkgdir
+>>> sdl_gfx: Fetching http://www.ferzkopp.net/Software/SDL_gfx-2.0/SDL_gfx-2.0.26.tar.gz
+  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
+                                 Dload  Upload   Total   Spent    Left  Speed
+100   251  100   251    0     0   1764      0 --:--:-- --:--:-- --:--:--  2127
+100 1729k  100 1729k    0     0  2103k      0 --:--:-- --:--:-- --:--:-- 2103k
+>>> sdl_gfx: Fetching http://www.ferzkopp.net/Software/SDL_gfx-2.0/SDL_gfx-2.0.26.tar.gz
+>>> sdl_gfx: Checking sha512sums...
+SDL_gfx-2.0.26.tar.gz: OK
+>>> sdl_gfx: Unpacking /var/cache/distfiles/SDL_gfx-2.0.26.tar.gz...
+checking build system type... Invalid configuration `aarch64-alpine-linux-musl': machine `aarch64-alpine-linux' not recognized
+configure: error: /bin/sh ./config.sub aarch64-alpine-linux-musl failed
+>>> ERROR: sdl_gfx: build failed
+(011680) [21:28:30] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+(011680) [21:28:30] NOTE: The failed command's output is above the ^^^ line in the log file: /home/jakob/Containers/pmbootstrap/pmbootstrap/log.txt
+(011680) [21:28:30] ERROR: Command failed (exit code 1): (buildroot_aarch64) % cd /home/pmos/build; busybox su pmos -c CARCH=aarch64 SUDO_APK='abuild-apk --no-progress' PATH=/native/usr/lib/crossdirect/aarch64:/usr/lib/ccache/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOME=/home/pmos abuild -D postmarketOS -d
+(011680) [21:28:30] See also: <https://postmarketos.org/troubleshooting>
+(011680) [21:28:30] Traceback (most recent call last):
+  File "/home/jakob/Containers/pmbootstrap/.venv/lib/python3.10/site-packages/pmb/__init__.py", line 49, in main
+    getattr(frontend, args.action)(args)
+  File "/home/jakob/Containers/pmbootstrap/.venv/lib/python3.10/site-packages/pmb/helpers/frontend.py", line 114, in build
+    if not pmb.build.package(args, package, arch_package, force,
+  File "/home/jakob/Containers/pmbootstrap/.venv/lib/python3.10/site-packages/pmb/build/_package.py", line 520, in package
+    (output, cmd, env) = run_abuild(args, apkbuild, arch, strict, force, cross,
+  File "/home/jakob/Containers/pmbootstrap/.venv/lib/python3.10/site-packages/pmb/build/_package.py", line 447, in run_abuild
+    pmb.chroot.user(args, cmd, suffix, "/home/pmos/build", env=env)
+  File "/home/jakob/Containers/pmbootstrap/.venv/lib/python3.10/site-packages/pmb/chroot/user.py", line 26, in user
+    return pmb.chroot.root(args, cmd, suffix, working_dir, output,
+  File "/home/jakob/Containers/pmbootstrap/.venv/lib/python3.10/site-packages/pmb/chroot/root.py", line 76, in root
+    return pmb.helpers.run_core.core(args, msg, cmd_sudo, None, output,
+  File "/home/jakob/Containers/pmbootstrap/.venv/lib/python3.10/site-packages/pmb/helpers/run_core.py", line 347, in core
+    check_return_code(args, code, log_message)
+  File "/home/jakob/Containers/pmbootstrap/.venv/lib/python3.10/site-packages/pmb/helpers/run_core.py", line 219, in check_return_code
+    raise RuntimeError(f"Command failed (exit code {str(code)}): " +
+RuntimeError: Command failed (exit code 1): (buildroot_aarch64) % cd /home/pmos/build; busybox su pmos -c CARCH=aarch64 SUDO_APK='abuild-apk --no-progress' PATH=/native/usr/lib/crossdirect/aarch64:/usr/lib/ccache/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOME=/home/pmos abuild -D postmarketOS -d
+#+END_SRC
+
+Fortunately, it wasn't too difficult to find the issue online. Someone had tried
+(unsuccessfully) to [[https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15673][add sdl_ttf to aports]] and ran into the same issue. The
+recommendation in the MR comments was to include the =prepare= block above.
+
+When that was sorted, I had a =sdl_gfx= package that I could use as a dependency
+for =openxcom=.
+
+#+BEGIN_SRC sh
+# Contributor: Jakob L. Kreuze <[REDACTED]>
+# Maintainer: Jakob L. Kreuze <[REDACTED]>
+_commit="ea9ac466221f8b4f8974d2db1c42dc4ad6126564"
+pkgname=openxcom
+pkgver=1.0.0
+pkgrel=1
+pkgdesc="Open-source reimplementation of the popular UFO: Enemy Unknown"
+url="https://openxcom.org/"
+arch="all"
+license="GPL-3.0-or-later"
+makedepends="cmake ninja yaml-cpp-dev sdl-dev sdl_gfx-dev sdl_image-dev sdl_mixer-dev glu-dev libexecinfo-dev"
+depends="libexecinfo"
+source="openxcom-$pkgver.tar.gz::https://github.com/OpenXcom/OpenXcom/archive/$_commit.tar.gz
+0001-Link-execinfo-unconditionally.patch"
+builddir="$srcdir"/OpenXcom-$_commit
+
+build() {
+	if [ "$CBUILD" != "$CHOST" ]; then
+		CMAKE_CROSSOPTS="-DCMAKE_SYSTEM_NAME=Linux -DCMAKE_HOST_SYSTEM_NAME=Linux"
+	fi
+	cmake -B build -G Ninja \
+		-DCMAKE_BUILD_TYPE=Release \
+		-DCMAKE_INSTALL_PREFIX=/usr \
+		-DBUILD_SHARED_LIBS=True \
+		$CMAKE_CROSSOPTS
+	cmake --build build
+}
+
+package() {
+	DESTDIR="$pkgdir" cmake --install build
+}
+
+sha512sums="57ff9a9cbbbf48b8c4f792458edf0590d7d0df9a5805eab13a4c984713311e98587afca00778e82bd66fb2f330b354ca80703b87922a92f9ae48e5bdecf68442  openxcom-1.0.0.tar.gz
+de4cc52530200992fef0e723acd59fef1b214f5b12baabec4dcca03820fbbc38c30033c0707f918fccc29e7d0d67ddef0c2a7be56d21b2bba7221899c759c282  0001-Link-execinfo-unconditionally.patch"
+#+END_SRC
+
+where =0001-Link-execinfo-unconditionally.patch= is the following:
+
+#+BEGIN_SRC diff
+From 2fe3e39c90086c7e3953d83ce75b0686ee4f5813 Mon Sep 17 00:00:00 2001
+From: "Jakob L. Kreuze" <[REDACTED]>
+Date: Tue, 23 Aug 2022 20:11:16 -0400
+Subject: [PATCH] Link execinfo unconditionally
+
+---
+ src/CMakeLists.txt | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
+index d484380ba..b7d3020bd 100644
+--- a/src/CMakeLists.txt
++++ b/src/CMakeLists.txt
+@@ -485,9 +485,7 @@ if ( WIN32 )
+ endif ()
+ 
+ # backtrace(3) requires libexecinfo on some *BSD systems
+-if (${CMAKE_SYSTEM_NAME} MATCHES FreeBSD OR ${CMAKE_SYSTEM_NAME} MATCHES NetBSD OR ${CMAKE_SYSTEM_NAME} MATCHES OpenBSD)
+-  set ( system_libs -lexecinfo )
+-endif ()
++set ( system_libs -lexecinfo )
+ 
+ target_link_libraries ( openxcom ${system_libs} ${SDLIMAGE_LIBRARY} ${SDLMIXER_LIBRARY} ${SDLGFX_LIBRARY} ${SDL_LIBRARY} ${OPENGL_LIBRARIES} debug ${YAMLCPP_LIBRARY_DEBUG} optimized ${YAMLCPP_LIBRARY} )
+ 
+-- 
+2.37.2
+
+#+END_SRC
+
+The first error I got was about a missing =mmintrin.h=. I opened up the source
+code and found that was under an =IFDEF= for =MMX= support, so I did a =./configure
+--help= to figure out how to disable that. After that, I was getting a message
+about a missing =glu.h=.
+
+#+BEGIN_SRC prog
+[63/313] Building CXX object src/CMakeFiles/openxcom.dir/Mod/RuleVideo.cpp.o
+ninja: job failed: /native/usr/lib/crossdirect/aarch64/g++ -DDATADIR=\"/usr/share/openxcom/\" -DGIT_BUILD=1 -I/usr/include/SDL -I/usr/include/yaml-cpp -I/home/pmos/build/src/OpenXcom-ea9ac466221f8b4f8974d2db1c42dc4ad6126564/build -Os -fomit-frame-pointer -O3 -DNDEBUG -std=gnu++11 -MD -MT src/CMakeFiles/openxcom.dir/Mod/RuleVideo.cpp.o -MF src/CMakeFiles/openxcom.dir/Mod/RuleVideo.cpp.o.d -o src/CMakeFiles/openxcom.dir/Mod/RuleVideo.cpp.o -c /home/pmos/build/src/OpenXcom-ea9ac466221f8b4f8974d2db1c42dc4ad6126564/src/Mod/RuleVideo.cpp
+In file included from /home/pmos/build/src/OpenXcom-ea9ac466221f8b4f8974d2db1c42dc4ad6126564/src/Mod/../Engine/OpenGL.h:15,
+                 from /home/pmos/build/src/OpenXcom-ea9ac466221f8b4f8974d2db1c42dc4ad6126564/src/Mod/../Engine/Screen.h:22,
+                 from /home/pmos/build/src/OpenXcom-ea9ac466221f8b4f8974d2db1c42dc4ad6126564/src/Mod/RuleVideo.cpp:21:
+/usr/include/SDL/SDL_opengl.h:47:10: fatal error: GL/glu.h: No such file or directory
+   47 | #include <GL/glu.h> /* Header File For The GLU Library */
+      |          ^~~~~~~~~~
+compilation terminated.
+ninja: subcommand failed
+>>> ERROR: openxcom: build failed
+#+END_SRC
+
+I went ahead and added the =glu-dev= dependency, after which point I was getting
+some warnings about redefinitions. So I have a feeling this might have been
+another thing that was behind an =IFDEF=, but that's a problem for later.
+
+#+BEGIN_SRC prog
+[218/313] Building CXX object src/CMakeFiles/openxcom.dir/Engine/AdlibMusic.cpp.o
+ninja: job failed: /native/usr/lib/crossdirect/aarch64/g++ -DDATADIR=\"/usr/share/openxcom/\" -DGIT_BUILD=1 -I/usr/include/SDL -I/usr/include/yaml-cpp -I/home/pmos/build/src/OpenXcom-ea9ac466221f8b4f8974d2db1c42dc4ad6126564/build -Os -fomit-frame-pointer -O3 -DNDEBUG -std=gnu++11 -MD -MT src/CMakeFiles/openxcom.dir/Engine/CrossPlatform.cpp.o -MF src/CMakeFiles/openxcom.dir/Engine/CrossPlatform.cpp.o.d -o src/CMakeFiles/openxcom.dir/Engine/CrossPlatform.cpp.o -c /home/pmos/build/src/OpenXcom-ea9ac466221f8b4f8974d2db1c42dc4ad6126564/src/Engine/CrossPlatform.cpp
+/home/pmos/build/src/OpenXcom-ea9ac466221f8b4f8974d2db1c42dc4ad6126564/src/Engine/CrossPlatform.cpp:68:10: fatal error: execinfo.h: No such file or directory
+   68 | #include <execinfo.h>
+      |          ^~~~~~~~~~~~
+compilation terminated.
+ninja: subcommand failed
+>>> ERROR: openxcom: build failed
+#+END_SRC
+
+The last errors I got were related to =execinfo=. This is, to my knowledge, a
+=glibc= thing. Fortunately, Alpine being a popular base image in Docker land means
+[[https://github.com/ddopson/node-segfault-handler/issues/70][the workarounds]] are easy to find on the 'net. The missing header file was one,
+thing, but then I was getting some linker errors about a missing symbol for
+=backtrace=. Searching came up with an [[https://discuss.pytorch.org/t/compiling-master-from-source-on-alpine-fails-with-undefined-reference-to-backtrace/64676][issue in PyTorch]] which gave me some
+insight, and then I found a [[https://github.com/OpenXcom/OpenXcom/pull/1123][pull request upstream]] related to it. My patch above
+just makes that unconditional; we get all the =backtrace= symbols from =execinfo=,
+but we also need to make sure it's actually linked into the binary.
+
+Then.. shit. It built correctly, but my =pmbootstrap= setup was a version behind
+the PostmarketOS on my phone (=v21.12= vs =v22.06=), so I was getting some
+dependency resolution errors. I re-initialized =pmbootstrap= and then learned that
+=sdl-dev= is no longer supported, so I had to backport it from =edge/testing=. It
+was at least smooth sailing after that.
+
+#+CAPTION: OpenXcom running on the PinePhone. It performs surprisingly well.
+[[./OpenXcom on PinePhone.png]]
+
+So porting software to the PinePhone is relatively easy.
+
+You don't even have to go through half of the mess that I did if you don't care
+about cross-compiling or having things tracked by the package manager. You could
+probably just install the =gcc= toolchain and do a =make && sudo make install= on
+your phone; Alpine/PostmarketOS have [[https://wiki.alpinelinux.org/wiki/Running_glibc_programs][glibc compatibility]]. Or, hell, use a
+Flatpak/AppImage/Snap if you want to.
+
+However you do it, the end result is the same. You get to use the same Linux
+applications on your phone that you would on your desktop, and I think that's
+great.
+
 ** Malware
 
 An unrelated aside: the only time I've heard of a trojan for Linux circulating
@@ -1873,10 +2307,27 @@ All-in-all, the people I do tell about how I use a phone running mainline Linux
 (mainly coworkers) find it cool but also very characteristic of who I am as a
 person. I think that's a fair way to conclude this section.
 
-* Surveying Other's
+* Surveying Other's Opinions
+
+I hinted at this in the introduction, but I'll say it again: the PinePhone is
+not a popular choice. I know precisely two people who own one (both of whom seem
+quite happy with theirs.) I appreciate the PinePhone, and there are others who
+appreciate it as well, but the overwhelming opinion is that it isn't ready for
+most "real life" use-cases. Come on down to the PINE64 mobile shop. We've got
+[[https://xnux.eu/log/#017][(hypothetical) exploding phones]] and [[https://www.pine64.org/2022/08/18/a-response-to-martijns-blog/][core contributors leaving in protest of
+bureaucracy]].
 
-https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and-pp/
-https://news.ycombinator.com/item?id=24596248
+The PinePhone is quite unique in that it's backed by hobbyists rather than big
+companies, and the effects of that are enough to make it a non-starter for many
+people. I find those that own a PinePhone (especially myself) tend to be
+dogmatic about software freedom and privacy, and get by without a lot of what
+typical smartphones offer.
+
+I don't want to spend too many cycles summarizing what other people have written
+about the PinePhone. I would recommend reading Amos B. Batto's article [[https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and-pp/][Comparing
+the Librem 5 USA and PinePhone Beta]] for some more articulate thoughts about
+the PinePhone's hardware and how it compares to its main "competitor," the
+Librem 5. The [[https://www.toomanyatoms.com/computer/pinephone.html][PinePhone page on toomanyatoms.com]] is also quite good.
 
 * Conclusions
 
@@ -1893,8 +2344,6 @@ https://news.ycombinator.com/item?id=24596248
 
 [fn:4] Folks message me on XMPP so infrequently that I can get by just using it on desktop.
 
-[fn:5] I fucking hate Discord. This package is broken on mobile anyway. #TODO: Elaborate
-
 [fn:6] Which is a bit of a shame. It wasn't a feature I used often on my old phone, but I was happy it was there. I have some really fond memories of sitting in the car when I was 16 and using the FM radio app on my phone to scan the airwaves as we passed through Maine during the winter.
 
 [fn:7] It was a bit of a pain to set up when I first tried it, so I gave up.
@@ -1912,3 +2361,5 @@ https://news.ycombinator.com/item?id=24596248
 [fn:12] And I can't figure out how to tell the compiler that I want to =move= the mutable =sender= into the closure and use that across all invocations. I don't think it's possible, but someone better than me at Rust is probably going to write me an email and tell me the better way to do this. When that happens, I'll update this post with an addendum.
 
 [fn:13] The =-t 3600= is to tell =pmbootstrap= not to kill itself if it doesn't see any output in half an hour. It's absolutely the most annoying thing in =pmbootstrap= because things just sometimes take a really long time to cross-compile.
+
+[fn:14] I should have included =go= as a build dependency, come to think of it.