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 Understood. Thank you for accomplishing this difficult task and sharing the solution.

Yes, this package doesn't include the UT dictionary, it only includes the files required for plugging Mozc into the Fcitx framework. The actual Mozc engine comes with either mozc-ut (which includes UT) or mozc (which does not).

Yes, it would be better for this package to be called fcitx5-mozc, but 1) that name is already taken by the package in the official repos, and 2) when this family of packages began their life they were not modular and included the Mozc engine and so the UT dictionary as well, so the name did fit the description. After a while I split them to accommodate more use cases, and I tried to negotiate getting the "rights" to the fcitx5-mozc name from the (at the time practically abandoned; like, more than 2 years outdated) official package but without any success, so the name kind of stuck.

I've had some thoughts about revising a few things around how the packages work and in the process refreshing the naming scheme as well, but those plans were kind of cut short about a year ago, when some needless drama made me lose interest for a while. But now things seem to be back to normal, so I'll eventually (probably) find the time to do a revision.

I'm sorry if I misunderstood. Just to confirm: Does this package really not include the UT dictionary? If so, wouldn't it be better to use a suffix other than -ut?

@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.