utf8proc: add new package

[betonmischer86]

📦 Package Details

Maintainer: @betonmischer86
_{(You can find this by checking the history of the package Makefile.)}

Description:
utf8proc is a small, clean C library that provides Unicode normalization, case-folding, and other operations for data in the UTF-8 encoding.

---

🧪 Run Testing Details

• OpenWrt Version: OpenWrt SNAPSHOT r31813
• OpenWrt Target/Subtarget: mediatek/filogic
• OpenWrt Device: Banana Pi BPI-R4 (2x SFP+)

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

If your PR contains a patch:

• It can be applied using git am
• It has been refreshed to avoid offsets, fuzzes, etc., using

  make package/<your-package>/refresh V=s

• It is structured in a way that it is potentially upstreamable
  _{(e.g., subject line, commit description, etc.)
  We must try to upstream patches to reduce maintenance burden.}

[GeorgeSapkin]

Unless something is going to depend on this library, and nothing indicates this in either the PR or commit message, there's no point adding it.

As with the other PRs, you need to set yourself as the maintainer and don't need to include the license file.

[betonmischer86]

As with the other PRs, you need to set yourself as the maintainer and don't need to include the license file.

Done.

Unless something is going to depend on this library, and nothing indicates this in either the PR or commit message, there's no point adding it.

I ported utf8proc (and unibilium, #27951) as build-time dependencies of Neovim before hitting a roadblock with Neovim itself. At some point, the Neovim build process starts running its own compiled code, including the actual nvim binary. So in order to cross-compile Neovim for OpenWrt, I would first need to build it (and all of the dependencies) as a host package to bootstrap the target build. Let me know whether a complicated build sequence like this would be accepted. If it's fine, should I hold off with utf8proc and unibilium PRs until the Neovim package is ready?

Also, utf8proc is already used by subversion as a bundled dependency. Perhaps the maintainer (@krant) would consider using a separate package instead.

[openwrt-ai]

Reviewed the new libs/utf8proc package (1 commit; message matches the diff). Two inline comments below: one on the pkg-config prefix that results from installing via utf8proc's upstream Makefile (/usr/local) rather than CMake, and one nit about a missing ABI_VERSION. No CI runs have been recorded on the head commit yet.

---

Generated by Claude Code

[openwrt-ai]

Everything here is installed from $(PKG_INSTALL_DIR)/usr/local/..., i.e. this relies on utf8proc's upstream Makefile default prefix=/usr/local instead of building via CMake. The headers and libs are re-homed correctly by the $(INSTALL_DATA)/$(CP) lines, but the libutf8proc.pc copied on this line is generated with that same prefix, so it will embed prefix=/usr/local and emit -I/usr/local/include -L/usr/local/lib. Once staged, any package that resolves utf8proc through pkg-config gets paths that don't exist in the OpenWrt sysroot — which would break exactly the build-time-dependency use case described in the PR discussion.

utf8proc ships a CMakeLists.txt, so the idiomatic fix is to build via CMake (CMAKE_INSTALL:=1 + include $(INCLUDE_DIR)/cmake.mk), matching sibling libraries such as libs/libcbor; that installs under /usr and produces a correct .pc, and also removes the need for the /usr/local paths throughout this file. Alternatively, pass prefix=/usr to the install step. Could you confirm the generated .pc prefix and adjust accordingly?

---

Generated by Claude Code

[openwrt-ai]

nit: this shared library has no ABI_VERSION. Sibling library packages (e.g. libs/libcbor) set ABI_VERSION to match the produced soname (libutf8proc.so.<N>) so opkg can track ABI changes across version bumps and rebuild dependents. Consider adding it to this Package/libutf8proc block.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The only change since the previous review is the PKG_VERSION 2.11.2 → 2.11.3 bump with the matching PKG_HASH; PKG_RELEASE correctly stays at 1 for a version upgrade. The two earlier inline comments (/usr/local prefix leaking into the staged libutf8proc.pc, and the missing ABI_VERSION) are unchanged by this bump and still apply. Formality checks are green on the head commit; no build/test runs have been recorded.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 1 new commits; no new issues found.

---

Generated by Claude Code