Package Details: ibus-mozc 2.28.4830.102-1

Git Clone URL: https://aur.archlinux.org/ibus-mozc.git (read-only, click to copy)
Package Base: ibus-mozc
Description: Mozc module for IBus
Upstream URL: https://github.com/google/mozc
Licenses: custom, BSD, LGPL, Apache
Submitter: Nocifer
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 8
Popularity: 1.33
First Submitted: 2021-12-26 10:41 (UTC)
Last Updated: 2022-09-04 09:12 (UTC)

Pinned Comments

Nocifer commented on 2022-05-29 21:56 (UTC)

Due to the recent GCC 12.1 update, if you try to update a Mozc package that was built with an older GCC version you will need to yet again delete your Bazel cache (~/.cache/bazel/... by default) in order to prevent the following error (or some such):

ERROR: /build/mozc/src/mozc-git/src/storage/louds/BUILD.bazel:167:16: Compiling storage/louds/bit_stream.cc [for host] failed: undeclared inclusion(s) in rule '//storage/louds:bit_stream':
this rule is missing dependency declarations for the following files included by 'storage/louds/bit_stream.cc':
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stddef.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stdarg.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stdint.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed/limits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed/syslimits.h'
INFO: Elapsed time: 5.362s, Critical Path: 1.28s
INFO: 36 processes: 13 internal, 23 linux-sandbox.
FAILED: Build did NOT complete successfully

It's more than likely that this error can also be prevented by removing one or more specific files within Bazel's cache instead of the whole lot of it, so in the future such toolchain updates may become much less painful; but for the time being, and unless otherwise noted, be aware that an updated toolchain will always mean that you need to delete Bazel's cache and suffer a full recompilation.

Latest Comments

Nocifer commented on 2022-05-29 21:56 (UTC)

Due to the recent GCC 12.1 update, if you try to update a Mozc package that was built with an older GCC version you will need to yet again delete your Bazel cache (~/.cache/bazel/... by default) in order to prevent the following error (or some such):

ERROR: /build/mozc/src/mozc-git/src/storage/louds/BUILD.bazel:167:16: Compiling storage/louds/bit_stream.cc [for host] failed: undeclared inclusion(s) in rule '//storage/louds:bit_stream':
this rule is missing dependency declarations for the following files included by 'storage/louds/bit_stream.cc':
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stddef.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stdarg.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stdint.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed/limits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed/syslimits.h'
INFO: Elapsed time: 5.362s, Critical Path: 1.28s
INFO: 36 processes: 13 internal, 23 linux-sandbox.
FAILED: Build did NOT complete successfully

It's more than likely that this error can also be prevented by removing one or more specific files within Bazel's cache instead of the whole lot of it, so in the future such toolchain updates may become much less painful; but for the time being, and unless otherwise noted, be aware that an updated toolchain will always mean that you need to delete Bazel's cache and suffer a full recompilation.

Nocifer commented on 2022-01-13 09:43 (UTC)

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):

error: failed to prepare transaction (could not satisfy dependencies)
:: installing mozc (2.26.4610.102-1) breaks dependency 'mozc=2.26.4596.102' required by ibus-mozc

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/ibus-mozc-2.26.4596.102-1/desc and replace

%DEPENDS%
ibus>=1.4.1
mozc=2.26.4596.20211205

with

%DEPENDS%
ibus>=1.4.1
mozc>=2.26.4596.20211205

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.

DeinAlptraum commented on 2021-12-27 14:23 (UTC) (edited on 2021-12-27 14:23 (UTC) by DeinAlptraum)

Thanks a lot, that worked

Nocifer commented on 2021-12-26 21:13 (UTC)

Yeah, that's because this new version is a huge update, both in terms of how Mozc is built and how it is packaged, and it conflicts with its previous incarnation. I should have expected this really.

The best and easiest solution is to first uninstall the previous version and then install this new one.

I'll pin this for the time being.

DeinAlptraum commented on 2021-12-26 21:02 (UTC) (edited on 2021-12-26 21:03 (UTC) by DeinAlptraum)

The latest update failed for me with the error:
:: installing mozc (2.26.4596.102-1) breaks dependency 'mozc=2.23.2815.102' required by ibus-mozc

Nocifer commented on 2020-12-07 01:08 (UTC)

Ah, yes, I completely forgot about direct input. Well, I just tried using the compose key with it and it didn't work on my end either. But you're saying it actually works with Debian's ibus-mozc package? Weird. Maybe they were using some Mozc version older than 2.23 (or a custom-patched 2.23) and the more recent versions have some bug that breaks this functionality? It wouldn't surprise me, as there is at least one bug that wasn't present in 2.23 but bugs the hell out of me in 2.25 (it doesn't remember the selected input mode across reboots and always resets it to direct input). Same goes for the instability problems you're experiencing (even though I don't have them).

The thing with Anthy is that it works good and is very well integrated with IBus, but it lacks the dictionary quality of Mozc, especially when combined with the expanded UT dictionary... Fcitx on the other hand is a very good choice, so if it integrates well with Xfce then I'd say just go for it.

Re → Edit: You mean you added an English layout inside IBus but outside of Mozc? Yeah, that will work for sure, that's how I've been doing it since ages: one IBus layout/IME for each language, with e.g. Mozc used only for Japanese, an English IBus layout for English, and so on and so forth. In my case it's even completely transparent because I use GNOME, which uses IBus as its default layout switcher.

davinosuke commented on 2020-12-06 16:56 (UTC) (edited on 2020-12-06 17:23 (UTC) by davinosuke)

@NOctifer: Thank you for the response. I'm sorry if I wasn't clear. I meant that the compose key is unresponsive when mozc is the selected composer, but ibus is in direct input mode. It should pass the multikey input through, so that I can compose with it when using English. I used this combination for years on Debian without incident.

As for other versions, I have now also tried ibus-mozc and ibus-mozc-ut2, and they are showing the same compose key behavior, but not the instability problems. ibus-mozc-ut-united refuses to compile at this time (missing a dependency). And the compose input method seems to be completely opaque, awkward, and unsuitable for regular use. I'm wondering if I should try switching to fcitx. Anthy is good, but mozc is definitely the better Japanese IM.

Edit: I think I have a workaround. I added an English input method to the list and it works with the compose key. I just have to reconfigure the keybindings I use to cycle between the two and hopefully it should be good enough for my purposes.

Nocifer commented on 2020-12-06 14:31 (UTC) (edited on 2020-12-06 15:10 (UTC) by Nocifer)

1) I don't think the compose key can work inside external IMEs like Mozc, I think it only does so in those layouts that IBus directly controls (Anthy is one of them). I could be wrong, but have you actually tested this with previous versions (or a different package) of Mozc and found it working? Besides, what would you compose while writing via a Japanese IME, which is a text composer itself?

2) & 3) To be honest I haven't ever tested Mozc in Xfce, only in GNOME and KDE, but all these years I've been using it I can't say I've ever had any issues like you describe. Your best bet would be to try your luck with one of the other ibus-mozc packages currently in the repos. They're a bit outdated but not too much, so if they work for you then you can certainly use them. And if they don't work, then we can at least rule out this package being at fault and start looking into other possible causes.

EDIT: Alright, I just installed and tested this package in a Manjaro Xfce Live CD instance. I didn't have any issues, neither with using Mozc in general nor with any of its menus freezing open and needing me to restart IBus in order to unfreeze them. I did notice the blinking tray icon, but that seems to me more like a matter of (im)proper integration between IBus and Xfce.

I also tested the compose key with Anthy and indeed it does work in principle, but predictably it does nothing useful (i.e. as soon as you enter a character it simply closes itself and input returns to Anthy's text composer).

davinosuke commented on 2020-12-06 13:42 (UTC)

I'm getting a few annoying bugs with this package [ibus-mozc-ut 2.26.4206.102.20201129-1]. 1) My compose key does not function when mozc is selected (it works properly when I switch to anthy). 2) The mozc menu from the ibus tray freezes open, and can only be made to collapse by restarting ibus. 3) The tray icon disappears and reappears with just about every action.

(For the record, I'm new to Arch, and currently running xfce.)