# 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)