Package Details: fcitx5-mozc-ut 2.31.5712.102.20250117-1

Git Clone URL: https://aur.archlinux.org/fcitx5-mozc-ut.git (read-only, click to copy)
Package Base: fcitx5-mozc-ut
Description: Fcitx5 module for Mozc (the Open Source edition of Google Japanese Input) bundled with the UT dictionary
Upstream URL: https://github.com/google/mozc
Licenses: Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND GPL-2.0-or-later AND CC0-1.0 AND CC-BY-SA-3.0 AND CC-BY-SA-4.0 AND GPL-2.0-only AND GPL-2.0-or-later AND MIT AND NAIST-2003 AND Unicode-3.0 AND LicenseRef-Okinawa-Dictionary
Conflicts: emacs-mozc, fcitx-mozc, fcitx5-mozc, ibus-mozc, mozc, mozc-ut
Provides: fcitx5-mozc
Submitter: Nocifer
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 10
Popularity: 6.85
First Submitted: 2025-02-08 22:00 (UTC)
Last Updated: 2025-02-08 22:00 (UTC)

Required by (3)

Sources (18)

Latest Comments

1 2 Next › Last »

bsjeon commented on 2025-02-17 07:18 (UTC) (edited on 2025-02-17 07:18 (UTC) by bsjeon)

https://github.com/google/mozc

https://github.com/fcitx/mozc

Is there a functional difference in the mozc_server executable between the two?

If not, how about adding ‘mozc=2.31.5712.102’ to PKGBUILD's ‘provides’ and removing emacs-mozc and ibus-mozc from ‘conflicts’?

It seems to be essentially a problem with the official fcitx5-mozc, but the login process is weird, so I'm not able to report the issue. Ideally, it would be best if the mozc package could be separated from the official fcitx5-mozc.

hirobot commented on 2025-02-14 01:25 (UTC)

Thanks, @keiichiiownsu12. I ignored the dependency between fcitx5-mozc-ut and emacs-mozc and rebuilt it.

keiichiiownsu12 commented on 2025-02-13 17:35 (UTC)

@hirobot, wouldn't recommend this for the long term, but you could revert to commit 980858ba, update pkgver to latest version, and build.

hirobot commented on 2025-02-12 01:25 (UTC)

:: fcitx5-mozc-ut-2.31.5712.102.20250117-1 and emacs-mozc-2.31.5712.102-1 are in conflict. Remove emacs-mozc? [y/N] I hope that emacs-mozc will be available.

keiichiiownsu12 commented on 2025-02-10 21:28 (UTC) (edited on 2025-02-10 21:28 (UTC) by keiichiiownsu12)

Echoing @CryogEnix

ibus-mozc and fcitx5-mozc-ut were not previously incompatible.

The only notable incompatibility is there are a few mozc files being shared among fcitx5-mozc-ut, ibus-mozc, and mozc-ut:

fcitx5-mozc-ut

/usr/lib/mozc/mozc_server
/usr/lib/mozc/mozc_tool

ibus-mozc

/usr/lib/mozc/mozc_renderer

mozc-ut

/usr/lib/mozc/mozc_server
/usr/lib/mozc/mozc_tool

Why not provide those files thru mozc-ut as a dependency?

CryogEnix commented on 2025-02-09 21:02 (UTC)

I have a question: Ibus-mozc and Fcitx5-mozc do not have any particular incompatibilities with apps, correct?

In any case, I still use Fcitx5-mozc-ut for the UT dictionaries alone.

npreining commented on 2025-02-09 11:45 (UTC)

I have been using these packages since long, and I am surprised to see all the drama. Which packages have been removed, and where is the explanation for the removal.

@Muflone you might want to check https://wiki.archlinux.org/title/Mozc for why UT dictionaries are worth it, to quote:

Tip: Use of the UT dictionary is optional but highly recommended.

@Nocifer Thanks a lot for your work on this, greatly appreciated!

Muflone commented on 2025-02-08 23:43 (UTC)

So is this package adding some extra features with those patches? What features exactly? Additional dictionaries?

your previous comment refered only to be able to be installed alongside with IBus, not extra features

Unfortunately, they failed to realize that the critical function (at least for some people) served by the way the package was engineered up until now, was that it was possible to install the Fcitx5 version of Mozc alongside the IBus and/or the Emacs version.

Nocifer commented on 2025-02-08 23:34 (UTC) (edited on 2025-02-08 23:37 (UTC) by Nocifer)

It's not a duplicate though, it's a patched version providing extra functionality not present in the official package.

Have you even read that rule you're quoting? Here's the rest of it:

Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion the pkgname should be different to express that difference.

Perhaps you're new here? Do you even know what the UT dictionary is? Packages like this one have existed on the AUR for many years now, and it's never been a problem, precisely because they're patched versions.

Please refrain from arbitrarily deleting packages that do not break the rules. And for that matter, perhaps you should go read those rules again.

Muflone commented on 2025-02-08 23:20 (UTC)

https://wiki.archlinux.org/title/AUR_submission_guidelines

The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances.