Search Criteria
Package Details: fcitx5-mozc-ut 2.28.4715.102-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/fcitx5-mozc-ut.git (read-only, click to copy) |
---|---|
Package Base: | fcitx5-mozc-ut |
Description: | Mozc module for Fcitx5 |
Upstream URL: | https://github.com/fcitx/mozc |
Licenses: | custom, BSD, LGPL, Apache |
Conflicts: | fcitx5-mozc |
Provides: | fcitx5-mozc |
Submitter: | Nocifer |
Maintainer: | Nocifer |
Last Packager: | Nocifer |
Votes: | 12 |
Popularity: | 1.73 |
First Submitted: | 2020-12-08 09:21 (UTC) |
Last Updated: | 2022-04-30 07:34 (UTC) |
Dependencies (7)
- fcitx5 (fcitx5-git)
- mozc (mozc-ut-united, mozc-ut)
- bazel (bazel-git, bazel024-bin, bazel024, bazel2, bazel3, bazel3-bin, bazel31, bazel31-bin, bazelisk, bazelisk-bin) (make)
- git (git-git, git-vfs, git-run-command-patch-git) (make)
- python (python38, python37, python3.7, nogil-python, python311, python39, python36) (make)
- qt5-base (qt5-base-git, qt5-base-headless) (make)
- fcitx5-configtool (fcitx5-configtool-git) (optional)
Latest Comments
Nocifer commented on 2022-02-25 19:18 (UTC)
Nah, it's already a hard dependency of
bazel
so it's guaranteed to be present on the system.ruahcra commented on 2022-02-25 01:36 (UTC)
Should the PKGBUILD have 'java-environment==11' in
makedepends
?ruahcra commented on 2022-02-01 12:17 (UTC)
I just tried it one more time before trying one of your suggestions and it just happened to work :P Thanks anyway, I will try deleting the cache next time if it happens.
Nocifer commented on 2022-02-01 11:22 (UTC)
Hmm, I just tried it twice and the file downloaded without problem. Does the package build with makepkg itself? If so, it could be something to do with paru. Also, if you haven't already, you could try removing Bazel's cache; even though it sounds counterintuitive in regards to this particular issue, Bazel is known for producing such weird quirks from time to time.
ruahcra commented on 2022-02-01 09:51 (UTC) (edited on 2022-02-01 09:52 (UTC) by ruahcra)
Is anyone else having trouble during install with Bazel failing to download the files from the japan post site (works fine in browser though...)?
Nocifer commented on 2022-01-13 09:37 (UTC) (edited on 2022-01-13 09:44 (UTC) by Nocifer)
Due to a mistake I made in the previous release, newer versions of this package may fail to gracefully update over a preexisting
2.26.4596.102
setup (installing fresh won't be an issue) with the following error (or something similar):The TL;DR version of it is that you will need to do one of the following:
1) Uninstall this package and then reinstall it; or
2) Edit the file /var/lib/pacman/local/fcitx5-mozc-ut-2.26.4596.102-1/desc and replace
with
and then proceed to update as per usual.
(In other words, the
mozc
version dependency should be a lax>=
instead of a strict=
; which AFAIR is also standard PKGBUILD practice, but somehow I completely forgot about it.)Hopefully this is now fixed, but I'll wait for your input (if any) before I can be certain. Sorry for the inconvenience.
Nocifer commented on 2022-01-10 21:14 (UTC)
@lionslancer Yup, I'd say you've summed it up pretty nicely. The naming/packaging situation is a bit of a mess right now, but contacting the maintainers of
fcitx5-mozc
andmozc-ut
in order to try and find a proper solution is already on my to-do list. Hopefully things won't prove to be too confusing for the users in the meantime.lionslancer commented on 2022-01-10 20:03 (UTC) (edited on 2022-01-10 20:05 (UTC) by lionslancer)
Hi! I recently ran into an issue where I had to reinstall this package because the new release depends on
mozc
, whichmozc-ut-common
didn't provide pre-update, causing it do attempt to install themozc
package which conflicts with the former.From looking at various PKBUILDs, it looks like you've become the maintainer of
mozc
and this change is to make the various framework module packages compatible with bothmozc
andmozc-ut-common
. Am I then correct in assuming that the relevant packages going forward are the following?mozc
andmozc-ut-common
for the enginefcitx5-mozc-ut
,ibus-mozc
, andemacs-mozc
for the modulesIf I've understood correctly, there's no longer anything UT-specific about this package, and the names
fcitx5-mozc
andmozc-ut
would have been used if not for the naming conflict with existing packages. Is this accurate?(edit: I accidentally deleted my comment while initially trying to edit the formatting, sorry if you received multiple notifications.)
river_wunsch commented on 2021-04-28 12:53 (UTC)
Thank you for your patience. I completely understand it now.
Nocifer commented on 2021-04-28 08:22 (UTC) (edited on 2021-04-28 08:23 (UTC) by Nocifer)
No such thing as a stupid question.
If you've managed to install this package then that means you are indeed using Mozc with the UT dictionary, as the latter is compiled into the Mozc binary during build time and used by default. AFAIK the only way to check for sure would be to compare the word candidates that this Mozc gives you with the candidates a non-UT Mozc would give you, but I don't really think that is necessary.
As to the second question: some time around 2016 the UT dictionary was deprecated by its creator in favor of two new dictionaries, UT2 and Neologd. They were supposed to replace UT, but in 2020 they were instead merged back into UT, and thus UT again became the de facto "UT dictionary" for Mozc. fcitx-mozc-ut-unified makes use of this latest UT dictionary, hence the "unified" part, which I assume was only added because there was already a package called fcitx-mozc-ut in the AUR (which was unmaintained at the time and was stuck using the old, pre-unification UT dictionary - this is no longer the case).
This package also uses the exact same UT dictionary, but because there weren't any Fcitx5 packages already in the AUR, I saw fit to just call it fcitx5-mozc-ut for consistency's sake (because from today's point of view, there is only a single UT dictionary). The only real difference between fcitx-mozc-ut-unified and fcitx5-mozc-ut is that the former is based on Fcitx, while the latter is based on Fcitx5, which is the Qt5-based successor of Fcitx. Do keep in mind though that Fcitx is still widely in use, as some language modules do not yet support Fcitx5 (e.g. the Baidu IME for Chinese).
Any *-ut2 packages can safely be considered as deprecated.
river_wunsch commented on 2021-04-27 13:49 (UTC) (edited on 2021-04-27 13:49 (UTC) by river_wunsch)
Sorry for my stupid questions cause I just learned about UT this week.
First, I installed this package using yay. However, there seems no differences in mozc. Do I need some config to enable UT dictionary? Or is there any methods to check if I'm using mozc with UT dictionary?
Second, there's seem to be multiple version of UT dictionary, such as fcitx-mozc-ut, fcitx-mozc-ut2, and fcitx-mozc-ut-unified in fcitx. I only find this package in fcitx5. I guess it's the same version as fcitx-mozc-ut-unified?
Apologies again for my stupid question.
Nocifer commented on 2021-01-07 19:36 (UTC)
@YEK
To be fair, utuhiro's PKGBUILD does have at least one advantage, namely, the fact that it doesn't rely on Fcitx's mirrored Mozc repo. I got bitten by this just now when, trying to update my mozc packages to their latest versions, I realized that while Mozc has been updated to version 2.26.4237 since 29/12/2020, the Fcitx mirror is still at version 2.26.4220.
This would normally mean that either I'd need to postpone updating this particular package (the ibus and emacs packages were already properly updated) and wait for the Fcitx developers to update their mirrored Mozc repo, or I'd need to update this package to only 2.26.4220 instead of the latest 2.26.4237 like the rest of the packages.
Enter utuhiro who, on top of providing UT in the first place, he also provides a patch for adding the needed Fcitx5 support directly to the upstream Mozc repo, without having to rely on the Fcitx devs to update their Mozc mirror. This patch literally saved the day.
So in fact I've now decided to modify my PKGBUILD to more closely resemble utuhiro's, by pulling directly from the official Mozc repo and using utuhiro's patch, along with the Fcitx5 iconset zip that he also provides on his website, in order to add Fcitx5 support on top of that.
I still think that the rest of the flaws I described, even though they're mostly minor, should really be addressed; but at least now we're even closer to convergence.
By the way, I'd welcome any suggestions you might have, now or in the future, for making this PKGBUILD better. We can always make the first step in fixing this non user-friendly AUR situation by cooperating ourselves :)
YEK commented on 2021-01-04 15:37 (UTC)
Thank you for the detailed explanation.
After deep consideration, I decided not to make an official PKGBUILD version and leave it to you.
Actually, I feel that the official PKGBUILD has a lot of changes and a lot of room for improvement. The variety of packages in Mozc is not user-friendly, and I think the idea is a very good one.
Thank you very much.
Nocifer commented on 2021-01-03 12:15 (UTC) (edited on 2021-01-03 12:16 (UTC) by Nocifer)
Hello @YEK,
Unfortunately, my choice to use a PKGBUILD different than the one provided by utuhiro is based on the fact that, as far as I can tell, there are a few flaws with it:
As such, at this time I think I prefer my own PKGBUILD instead of utuhiro's. I'm very open to the idea of collaboration between us and the rest of the various Mozc packagers in the AUR, and even with utuhiro, in order to create one common PKGBUILD template and use it to provide the whole gamut of Mozc packages (which would come with the added benefit that new users looking to install Mozc won't feel confused by the many different choices), but for the time being feel free to create a separate fcitx5-mozc-ut-unified package and I'll make sure to add it as an option in the ArchWiki's Mozc page (or you can also do it yourself, of course).
Thanks for contacting me, I appreciate it.
YEK commented on 2021-01-02 18:17 (UTC)
Hi, I'm maintainer of
fcitx-mozc-ut-unified
package. Now UT's upstream (utuhiro's project) supports fcitx5 officially withfcitx-mozc-ut-*-PKGBUILD.txt
.Will you follow it in this package? (If you won't, I will create fcitx5-mozc-ut-unified package.)