Currently it has a mix of: - google/mozc, which is the overall upstream, along with patches against it. - fcitx/mozc, which is fcitx's upstream. - fcitx/mozc-cmake, which serves as the cmake base, along with patches against it.
I'm considering options such as: - Tracking google/mozc as upstream, managed via a git repo (izkluxcvy/mozc-ports). - Tracking google/mozc as upstream, managed via patches of ports. - Tracking fcitx/mozc and fcitx/mozc-cmake forks as upstream, and managing the __OpenBSD__ changes via patches. What would be the best approach? I'd appreciate any feedback. On 2026/08/26 3:56, akizu matsuo wrote: > Hi, > > This is a new port of Mozc, a japanese input method engine. This port > builds from a personal fork (https://github.com/izkluxcvy/mozc-ports) > that replaces upstream's bazel build with CMake (based on > fcitx/mozc-cmake) and adds OpenBSD support. > > The port produces three packages: > - mozc: core engine (mozc_server) and config tool (mozc_tool) > - fcitx-mozc: fcitx5 input method > - ibus-mozc: ibus input method > > Tested on OpenBSD/amd64 -current. > I'm new to OpenBSD packaging, so please let me know if I missed > something. Although the guide states that __OpenBSD__ should be avoided, > I used __OpenBSD__ to sync with the upstream codebase. > > Port tarball attached.
