Arch Linux User Repository

To any and all future inquiries as to the nature of this package:

TL;DR this package is NOT a duplicate of extra/fcitx5-mozc, so please DO NOT report it as such.

To elaborate:

• Mozc operates with a server <-> client model.

• The extra/fcitx5-mozc package comes with both the Mozc server binaries and the Fcitx5-specific client binaries. This means that the package will conflict with any other Mozc client package, e.g. for IBus or Emacs.

• This package contains ONLY the Fcitx5-specific client binaries, and relies on mozc or mozc-ut for pulling in Mozc's server binaries. This means that a user can install this package alongside the equivalent IBus-specific and/or Emacs-specific packages (also currently present in the AUR) and enjoy Mozc across a variety of different but simultaneously installed environments (e.g. in the case of a shared PC with one user using KDE + Fcitx and another user using GNOME + IBus, or in the case of an Emacs user because of course Emacs comes with its own IMF >.>), with zero conflicts because all three of these client packages contain only the relevant client-specific binaries and share a dependency on mozc/mozc-ut for the server binaries.

• Unfortunately, even though this package does not in fact contain any UT patches (those are only applied to the mozc/mozc-ut server packages), it is named with a -ut suffix because of the existence of the extra/fcitx5-mozc package.

For more info you can read the Arch Wiki entry on Mozc.

If you're getting compilation errors (especially complaints about missing GCC headers) please delete your Bazel cache (~/.cache/bazel by default).

@Nocifer I did what you told me to do and everything is working! ありがとう、兄貴！

@Hufenbacke Yeah, that's absolutely normal and you should let the update process remove the currently installed fcitx5-mozc-ut package, it will be properly reinstalled at a later stage.

Also, unrelated but I'd suggest that you install mozc-ut instead of mozc, otherwise you'll be missing all the goodness of the UT dictionary.

@Nocifer, first of all thanks for this package! Since my swap from Windows and a few hours with problems during the setup/configuration of the fcitx5-mozc black hole, this has been working like a charm. I saw the update today and started it. But I get the following error message:

:: mozc-2.32.5981.102-1 and fcitx5-mozc-ut-2.31.5851.102.20250602-2 are in conflict. Remove fcitx5-mozc-ut?

Is this correlated to the comments of today? And what should I do?

@vatai Well, we were stuck, but now we're at long last unstuck, at least until the next time somebody comes and decides to summarily delete the package without even so much as trying to reach out to the packager before doing so ;)

Though to be fair, TUs have enough on their platters already and tens if not hundreds of AUR package requests to process each and every day, so it's very easy to be hasty and make such a mistake, especially when you're unfamiliar with the finer details and the two packages do look identical on the surface.

So no hard feelings for anybody (...except maybe for the person who originally reported this as a duplicate and prompted @Muflone to delete it).

Also, thanks!

To any and all future inquiries as to the nature of this package:

TL;DR this package is NOT a duplicate of extra/fcitx5-mozc, so please DO NOT report it as such.

To elaborate:

• Mozc operates with a server <-> client model.

• The extra/fcitx5-mozc package comes with both the Mozc server binaries and the Fcitx5-specific client binaries. This means that the package will conflict with any other Mozc client package, e.g. for IBus or Emacs.

• This package contains ONLY the Fcitx5-specific client binaries, and relies on mozc or mozc-ut for pulling in Mozc's server binaries. This means that a user can install this package alongside the equivalent IBus-specific and/or Emacs-specific packages (also currently present in the AUR) and enjoy Mozc across a variety of different but simultaneously installed environments (e.g. in the case of a shared PC with one user using KDE + Fcitx and another user using GNOME + IBus, or in the case of an Emacs user because of course Emacs comes with its own IMF >.>), with zero conflicts because all three of these client packages contain only the relevant client-specific binaries and share a dependency on mozc/mozc-ut for the server binaries.

• Unfortunately, even though this package does not in fact contain any UT patches (those are only applied to the mozc/mozc-ut server packages), it is named with a -ut suffix because of the existence of the extra/fcitx5-mozc package.

For more info you can read the Arch Wiki entry on Mozc.

@Nocifer, thanks for clarifying. After parsing the comments here, I was under the impression that we're stuck in this ungodly state of affairs :)

Thanks for maintaining all mozc related package!

m(_ _)m お疲れ様でした

@vatai The reason you can't have the various mozc packages installed in parallel anymore is indeed an administrative error/oversight and not a technical issue, but as far as I'm concerned I've reached the conclusion for a while now that this whole matter was a misunderstanding and that there is no reason not to revert this package back to its old self.

The only reason I've delayed the remake is that I'd been waiting for Mozc's next update (my thinking was to spare users from an extra rebuild with no actual version bump, which in retrospect I realize may have been a mistake, because reverting the split is actually rather important) and for some reason Mozc hasn't seen any updates for a few months now - or at least, that was the case until about 2 weeks ago when build 5981 was released, which apparently I totally missed because I had other stuff going on and due to the long period of no updates I'd grown negligent of following Mozc's releases.

TL;DR, I'll update this package today and with the new update I'll revert it to a split version again.

mozc-ut-full is available. Today, there is an issue with the PKGBUILD sha512sums, but it can be built with a simple fix. There is a slight difference in the dictionary data files built into mozc_server compared to the package maintained by @Nocifer.

Looking at the PKGBUILD for mozc-ut-full, a single build produces mozc-ut, ibus-mozc-ut, fcitx5-mozc-ut, and emacs-mozc-ut (with -full suffix). It's configured so all packages can be installed together without dependency issues. It does not generate the fcitx-mozc-ut-full package.

A noteworthy point is that mozc-ut-full remains in the AUR repository and is not being removed. It seems the claim mentioned in @Nocifer's comment is no longer valid. Therefore, I believe reverting to the old method should not cause any claim. If possible, it would be good to modify the PKGBUILD to build all related packages at once, using mozc-ut-full as a reference.

If the claim is raised again, it must be clearly explained. Even if the list of packaged files is identical to fcitx5-mozc, mozc_server is different. This is not a duplicate because the mozc_server executable itself contains dictionary data. Update: I was a bit confused. Since the separate package fcitx5-mozc-ut originally only included the fcitx5 mozc module and did not contain mozc_server, it could not be considered redundant.

The official mozc repository only includes the emacs and ibus frontends. To build the fcitx module, we must use the mozc repository maintained by the fcitx project. Except for the addition of fcitx frontends, it is identical to the official repository. I think it's fine to build ibus-mozc-ut, emacs-mozc-ut using this repository as well.

Dear @Muflone (or whom ever can help with this),

I'm trying to get Mozc working both in fcitx5 and emacs, possibly with the UT dictionary, and you seem to be the person to talk to -- if not, and you know whom to contact, please let me know.

As described in the Mozc Arch wiki [1], Mozc consists of servers/backend and modules/frontend. These can be built in a single integrated package or as split packages, implementing different versions of the servers/backends and various modules/frontends. The extra/fcitx5-mozc package takes the integrated package approach, which means no other server or frontend can coexist with it on the system. There used to be a fcitx5-mozc-ut AUR package, which implemented a different server/backend (UT dictionaries) and followed the split approach, which meant it could be installed in parallel with ibus-mozc{-ut} and emacs-mozc{-ut} AUR packages. The first/oldest comment of the new incarnation of the fcitx5-mozc-ut package [2] from the package maintainer says that due to some admin issues, they have to follow the integrated packaging approach for the new fcitx5-mozc-ut AUR package. You replied to this comment and asked "So is this package adding some extra features with those patches? What features exactly? Additional dictionaries?" to which a user directed you to [1], but then the conversation stopped there.

I'm mentioning @Muflone explicitly because:

• The current situation of not being able to install Mozc with both fcitx and other (ibus and emacs) backends is frustrating.
• The reply to your question did not explicitly mention the non-trivial feature of the split approach, which allows multiple modules/frontends to be installed next to fcitx. So, to answer your question as explicitly as I can: The (old) fcitx5-mozc-ut AUR package (which followed the split packaging method) implements the feature of allowing multiple frontends to be installed in parallel (a feature not present in extras/fcitx5-mozc).
• Just in case you missed that reply, I wanted to bring your attention to it.

[1] https://wiki.archlinux.org/title/Mozc

[2] https://aur.archlinux.org/packages/fcitx5-mozc-ut?O=20

I wanted to paste this here, before I email @Muflone directly. As I understand the reason I can't have {fcitx5,ibus,emacs}-mozc[-ut] installed in parallel is administrative, not technical. If this is not correct or if @Muflone is not the correct person to contact (arch-dev-public@lists.archlinux.org perhaps?) please let me know.

Best, E

@Nocifer Thanks. Didn't realize it was upstream with the Mozc-ut package.