blob: 4f817a80b32e963f99a32da2ee0bfc0f170f249c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
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)
|
