blog: patching Gentoo packages in the wild

2 files changed, 49 insertions, 0 deletions

diff --git a/blog/2022-04-18.md b/blog/2022-04-18.md
new file mode 100644
index 0000000..4f817a8
--- /dev/null
+++ b/blog/2022-04-18.md
@@ -0,0 +1,48 @@
+# Patching Gentoo :gentoo: packages in the wild
+Everyone who has ever used **st** - [suckless terminal](https://st.suckless.org) - has experienced [weird crash](https://github.com/LukeSmithxyz/voidrice/issues/284) when trying to render some very specific unicode characters. In this short post I'm showing how easy it is to solve this problem on Gentoo with the help of patches.
+
+# libXft
+The original problem is solved by installing a couple of fallback fonts and a **patched version** of `libXft`. Guys from Arch Linux can just install patched version [libxft-bgra from aur](https://aur.archlinux.org/packages/libxft-bgra), why don't we have something similar on Gentoo? :thinking:
+
+We don't need it! Here's the process *of me* solving this problem in a matter of 5 minutes:
+
+1. Find patched version from comments on GitHub - https://github.com/uditkarode/libxft-bgra
+2. Find upstream source code - https://gitlab.freedesktop.org/xorg/lib/libxft
+3. Clone the patched repo and pull tags from upstream:
+  ```bash
+  git clone git@github.com:uditkarode/libxft-bgra.git
+  git remote add upstream git@gitlab.freedesktop.org:xorg/lib/libxft.git
+  git pull upstream --tags
+  ```
+4. Checking `git log --oneline` on `master` branch, looks like we are only interested in commit `72e54c0` (the actual *PATCH*). The latest tag before the patch seems to be **2.3.3**.
+  ```bash
+  072cd20 (HEAD -> master, origin/master, origin/HEAD) README: instructions i guess
+  72e54c0 [PATCH] Add support for BGRA glyphs display and scaling
+  6e7da3c Remove call to FcNameRegisterObjectTypes
+  26a3a49 Skip 'render' pattern elements with invalid type
+  972fa05 build-fix for c89
+  86c2355 minor typography fix
+  ed8bb96 fix most type-conversion warnings from gcc-normal, without obje
+  ct-file changes
+  a266847 (tag: libXft-2.3.3) libXft 2.3.3
+  fab5adf Add description of libXft to README.md
+  b397ffb Update configure.ac bug URL for gitlab migration
+  ```
+
+5. Create patches from the diff: `git format-patch libXft-2.3.3`
+6. Move the generated `.patch` to `/etc/portage/patches/x11-libs/libXft`
+7. Reinstall libXft: `emerge -av libXft`
+8. Profit!!!
+
+Well, actually, I did something on top of that - I *rebased* patched branch to the latest **2.3.4** tag to make sure that the patch still works with the latest version of the library. If it wasn't the case - I could just pin the version when emerging: `emerge -av "=libXft-2.3.3"` because we know that the patch is working on that version.
+
+From now on, I will keep receiving updates to my `libXft` from Portage and each new version will be patched (hopefully successfully) until the fix is released to the upstream.
+
+# Grab the patch
+Well, everything above was "head-on" way. Taking a closer look to the upstream repo, there's already a [merge request](https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1) with our fix, so we don't have to do git magic and we can easily grab the raw diff by appending `.patch` to the URL:
+
+https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1.patch
+
+# See also
+ - [Running Gentoo :gentoo: on multiple workstations](2022-04-17.md)
+ - [DWM - useless gaps are useless!](2022-04-02.md)
diff --git a/blog/index.md b/blog/index.md
index e3c2d1f..d9c72fe 100644
--- a/blog/index.md
+++ b/blog/index.md
@@ -4,6 +4,7 @@
 
 ### April
 
+- [Patching Gentoo :gentoo: packages in the wild](2022-04-18.md)
 - [Running Gentoo :gentoo: on multiple workstations](2022-04-17.md)
 - [DWM - useless gaps are useless!](2022-04-02.md)