Package Details: mozc 2.28.4740.102-1

Git Clone URL: https://aur.archlinux.org/mozc.git (read-only, click to copy)
Package Base: mozc
Description: The Open Source edition of Google Japanese Input
Upstream URL: https://github.com/google/mozc
Licenses: custom, BSD, LGPL, Apache
Conflicts: mozc-ut
Submitter: ponsfoot
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 68
Popularity: 1.13
First Submitted: 2010-08-09 04:27 (UTC)
Last Updated: 2022-05-29 21:43 (UTC)

Pinned Comments

Nocifer commented on 2022-05-29 21:53 (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:53 (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.

renatoliveira commented on 2022-02-21 20:25 (UTC)

Cool, that really helped with the problem. I also had to delete the cache from pacman though. Then it worked.

Many thanks. :)

Nocifer commented on 2022-02-21 10:28 (UTC)

These errors are because the recently updated GCC 11.2 toolchain has some internal changes that make cached files from previous builds with older GCC versions no longer valid. Just delete your Bazel cache folder and it should work.

renatoliveira commented on 2022-02-21 10:21 (UTC)

Build fails during installation for me with the following error:

/home/renny/.cache/yay/mozc/src/mozc-git/src/dictionary/file/BUILD.bazel:131:16: Compiling dictionary/file/codec_factory.cc [for host] failed: undeclared inclusion(s) in rule '//dictionary/file:codec_factory':
this rule is missing dependency declarations for the following files included by 'dictionary/file/codec_factory.cc':
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stdint.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed/limits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed/syslimits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stddef.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stdarg.h'
INFO: Elapsed time: 12.803s, Critical Path: 4.26s
INFO: 9 processes: 9 internal.
FAILED: Build did NOT complete successfully
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: mozc

I'm guessing some file directive could be edited to add the dependency declarations it is missing, but I'm not really a C or C++ expert, so I don't know what to do in this case: if it is an issue with the PKGBUILD or with the program's build script. If it is the later then I'm guessing it would be better to open an issue on GitHub instead? :)

Nocifer commented on 2021-11-02 10:57 (UTC) (edited on 2021-11-02 12:42 (UTC) by Nocifer)

@ruahcra Indeed; and when we're talking about an "old commit", we're really talking about a 3-year old version which still depends on deprecated stuff like gtk2 and python2 and a deprecated build procedure/system (for better or worse, upstream has switched out Ninja for Bazel since a few months ago).

Also, yeah, Mozc only releases new versions by commit (internally they're tagged as such and the version is incremented with almost each new commit, but there are no explicitly tagged releases) so it's up to the maintainer to keep up and update the package accordingly, just like with any other package really.

Regarding the UT dictionary, Mozc is the open source version of Google Japanese Input, which is a top-quality Japanese IME (along the lines of Google Keyboard et al). But Mozc being open source unfortunately means that it doesn't come with the extensive dictionaries/definitions that actually make Google Japanese Input what it is, because Google has chosen to keep them as closed source (possibly to hold an advantage over its competition). So what the UT dictionary does is bring the open source Mozc (closer) to the quality of its closed source cousin by patching the bundled dictionaries and expanding them.

There are some people that for whatever reason do not seem to care for the UT dictionary (or seemingly even for plain Mozc/IBus, seeing as even this vanilla package isn't part of the official Arch repos as IMHO it should) but as I said in the previous comment, I just now realized that since in my version of the packages Mozc has been split into its own base package, ibus-mozc-ut is actually nothing more but plain old ibus-mozc - the UT part only concerns the base Mozc package. So it could be made that there is only one version each of ibus-mozc, emacs-mozc, fcitx-mozc, fcitx5-mozc etc in the AUR, and two choices for the base Mozc part: mozc and mozc-ut, both of which the individual packages would be compatible with, and so the choice would be left to the user on whether to use UT or not. This way I think everybody would be happy.

ruahcra commented on 2021-11-02 10:18 (UTC) (edited on 2021-11-02 10:21 (UTC) by ruahcra)

So both packages build from the same upstream source, but apart from the additional dictionaries they include, the only difference is that this package is stuck on a old commit, where-as ibus-mozc-ut is using a more recent commit?

Also since mozc does not tag releases then it is up to the PKGBUILD maintainer to update the package at an appropriate commit in order to keep it up to date?

In that case I hope you are successful in getting ownership of this package! I will be moving to ibus-mozc-ut for the time being.

Nocifer commented on 2021-11-02 10:00 (UTC)

@CyberShadow Hmm, now that you mention it... There is of course the issue that my ibus-mozc-ut package includes the unofficial UT dictionary, so it's not a one for one replacement for the vanilla ibus-mozc, but since the base Mozc functionality (along with the UT inclusion) has been split into its own package, there really isn't anything that precludes merging them all into a family of interchangeable packages.

Well, back when I created my package I didn't want to step on anyone's toes (let alone @ponsfoot's, who'd been the de facto maintainer of the Mozc AUR packages for ages) but I think you're right, this probably calls for an orphan-and-adopt procedure. Thanks for the tip.

CyberShadow commented on 2021-11-02 09:43 (UTC)

Nocifer, I think the appropriate procedure for this case is to submit a request to orphan this package and adopt it. If this package provides zero benefit over existing packages, then it could also be deleted, with the better packages having provides/replaces=mozc to provide an upgrade path.

Nocifer commented on 2021-11-02 09:39 (UTC) (edited on 2021-11-02 10:58 (UTC) by Nocifer)

Hey guys, I hope you all are aware that this package was last updated some 3 years ago and is currently unmaintained and severely out of date? I'm not usually one to tout my own horn, but there does exist an updated version in the AUR that is actively maintained (currently by me; that's the proverbial horn) and which solves the issues I see mentioned here, both the dependency on gtk2 (that's been deprecated and removed by upstream since ages ago, along with the python2 dependency) and the conflict between ibus-mozc and fcitx-mozc (you can have both installed on your system at the same time).

The updated package is ibus-mozc-ut. And again, because I dislike touting my own horn, let me just say that it's not like I stand to gain something by posting this "ad" here, it's just that the whole reason I created a new package in the first place was to spare people (myself included) from exactly the kind of issues reported in the comments here.

Just a friendly FYI.

jole commented on 2021-08-21 23:36 (UTC)

please add gtk2 as a dependency? that fixed it for me aswell

Aargonian commented on 2021-03-17 00:43 (UTC)

Installing the gtk2 package resolved the build issue mentioned by @CyberShadow for me.

CyberShadow commented on 2020-12-31 20:26 (UTC)

Seems to fail finding gtk+:

INFO: Running: /usr/bin/python2 /build/mozc/src/mozc/src/third_party/gyp/gyp_main.py --depth=. --include=./gyp/common.gypi -D abs_depth=/build/mozc/src/mozc/src -D ext_third_party_dir=/build/mozc/src/mozc/src/third_party -D python_executable=/usr/bin/python2 ./base/base.gyp ./base/base_test.gyp ./client/client.gyp ./client/client_test.gyp ./composer/composer.gyp ./composer/composer_test.gyp ./config/config.gyp ./config/config_test.gyp ./converter/converter.gyp ./converter/converter_base.gyp ./converter/converter_main.gyp ./converter/converter_test.gyp ./data/test/session/scenario/scenario.gyp ./data/test/session/scenario/usage_stats/usage_stats.gyp ./data_manager/chromeos/chromeos_data_manager.gyp ./data_manager/chromeos/chromeos_data_manager_base.gyp ./data_manager/chromeos/chromeos_data_manager_test.gyp ./data_manager/data_manager.gyp ./data_manager/data_manager_base.gyp ./data_manager/data_manager_test.gyp ./data_manager/oss/oss_data_manager.gyp ./data_manager/oss/oss_data_manager_base.gyp ./data_manager/oss/oss_data_manager_test.gyp ./data_manager/testing/mock_data_manager.gyp ./data_manager/testing/mock_data_manager_base.gyp ./data_manager/testing/mock_data_manager_test.gyp ./dictionary/dictionary.gyp ./dictionary/dictionary_base.gyp ./dictionary/dictionary_test.gyp ./dictionary/file/dictionary_file.gyp ./dictionary/file/dictionary_file_test.gyp ./dictionary/system/system_dictionary.gyp ./dictionary/system/system_dictionary_test.gyp ./engine/engine.gyp ./engine/engine_test.gyp ./gui/gui.gyp ./gyp/tests.gyp ./handwriting/handwriting.gyp ./handwriting/handwriting_test.gyp ./handwriting/zinnia.gyp ./ipc/ipc.gyp ./mac/mac.gyp ./net/jsoncpp.gyp ./net/net.gyp ./net/net_test.gyp ./prediction/prediction.gyp ./prediction/prediction_base.gyp ./prediction/prediction_test.gyp ./protobuf/protobuf.gyp ./protocol/protocol.gyp ./renderer/renderer.gyp ./request/request.gyp ./rewriter/calculator/calculator.gyp ./rewriter/rewriter.gyp ./rewriter/rewriter_base.gyp ./rewriter/rewriter_test.gyp ./server/server.gyp ./session/session.gyp ./session/session_base.gyp ./session/session_test.gyp ./storage/storage.gyp ./storage/storage_test.gyp ./testing/testing.gyp ./transliteration/transliteration.gyp ./transliteration/transliteration_test.gyp ./unix/emacs/emacs.gyp ./unix/ibus/ibus.gyp ./usage_stats/usage_stats.gyp ./usage_stats/usage_stats_base.gyp ./usage_stats/usage_stats_test.gyp -D branding=Mozc -D use_qt=YES -D qt_dir= -D use_wix=NO -D build_base=/build/mozc/src/mozc/src/out_linux -D build_short_base=out_linux -D warn_as_error=0 -D channel_dev=1 -D enable_cloud_handwriting=0 -D target_platform=Linux -D use_libibus=1 --generator-output=. -G output_dir=out_linux
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gtk+-2.0', required by 'virtual:world', not found
Package 'gdk-2.0', required by 'virtual:world', not found
gyp: Call to 'pkg-config --libs-only-l glib-2.0 gobject-2.0 gthread-2.0 gtk+-2.0 gdk-2.0' returned exit status 1 while in renderer/renderer.gyp.
Traceback (most recent call last):
  File "build_mozc.py", line 1236, in <module>
    main()
  File "build_mozc.py", line 1220, in main
    GypMain(cmd_opts, cmd_args)
  File "build_mozc.py", line 736, in GypMain
    RunOrDie(gyp_command + gyp_options)
  File "/build/mozc/src/mozc/src/build_tools/util.py", line 99, in RunOrDie
    '==========']))
build_tools.util.RunOrDieError: 
==========
 ERROR: /usr/bin/python2 /build/mozc/src/mozc/src/third_party/gyp/gyp_main.py --depth=. --include=./gyp/common.gypi -D abs_depth=/build/mozc/src/mozc/src -D ext_third_party_dir=/build/mozc/src/mozc/src/third_party -D python_executable=/usr/bin/python2 ./base/base.gyp ./base/base_test.gyp ./client/client.gyp ./client/client_test.gyp ./composer/composer.gyp ./composer/composer_test.gyp ./config/config.gyp ./config/config_test.gyp ./converter/converter.gyp ./converter/converter_base.gyp ./converter/converter_main.gyp ./converter/converter_test.gyp ./data/test/session/scenario/scenario.gyp ./data/test/session/scenario/usage_stats/usage_stats.gyp ./data_manager/chromeos/chromeos_data_manager.gyp ./data_manager/chromeos/chromeos_data_manager_base.gyp ./data_manager/chromeos/chromeos_data_manager_test.gyp ./data_manager/data_manager.gyp ./data_manager/data_manager_base.gyp ./data_manager/data_manager_test.gyp ./data_manager/oss/oss_data_manager.gyp ./data_manager/oss/oss_data_manager_base.gyp ./data_manager/oss/oss_data_manager_test.gyp ./data_manager/testing/mock_data_manager.gyp ./data_manager/testing/mock_data_manager_base.gyp ./data_manager/testing/mock_data_manager_test.gyp ./dictionary/dictionary.gyp ./dictionary/dictionary_base.gyp ./dictionary/dictionary_test.gyp ./dictionary/file/dictionary_file.gyp ./dictionary/file/dictionary_file_test.gyp ./dictionary/system/system_dictionary.gyp ./dictionary/system/system_dictionary_test.gyp ./engine/engine.gyp ./engine/engine_test.gyp ./gui/gui.gyp ./gyp/tests.gyp ./handwriting/handwriting.gyp ./handwriting/handwriting_test.gyp ./handwriting/zinnia.gyp ./ipc/ipc.gyp ./mac/mac.gyp ./net/jsoncpp.gyp ./net/net.gyp ./net/net_test.gyp ./prediction/prediction.gyp ./prediction/prediction_base.gyp ./prediction/prediction_test.gyp ./protobuf/protobuf.gyp ./protocol/protocol.gyp ./renderer/renderer.gyp ./request/request.gyp ./rewriter/calculator/calculator.gyp ./rewriter/rewriter.gyp ./rewriter/rewriter_base.gyp ./rewriter/rewriter_test.gyp ./server/server.gyp ./session/session.gyp ./session/session_base.gyp ./session/session_test.gyp ./storage/storage.gyp ./storage/storage_test.gyp ./testing/testing.gyp ./transliteration/transliteration.gyp ./transliteration/transliteration_test.gyp ./unix/emacs/emacs.gyp ./unix/ibus/ibus.gyp ./usage_stats/usage_stats.gyp ./usage_stats/usage_stats_base.gyp ./usage_stats/usage_stats_test.gyp -D branding=Mozc -D use_qt=YES -D qt_dir= -D use_wix=NO -D build_base=/build/mozc/src/mozc/src/out_linux -D build_short_base=out_linux -D warn_as_error=0 -D channel_dev=1 -D enable_cloud_handwriting=0 -D target_platform=Linux -D use_libibus=1 --generator-output=. -G output_dir=out_linux
==========
==> ERROR: A failure occurred in build().
    Aborting...

Missing dependency?

npzaak commented on 2020-01-25 02:50 (UTC) (edited on 2021-02-22 14:30 (UTC) by npzaak)

@cobaltspace :

To avoid conflict with fcitx-mozc,

Option A. Modify fcitx-mozc (community) package to build mozc_emacs_helper with it.

Option B. Or, remove conflicted modules from mozc (AUR) package.

Both ways need to edit PKGBUILD by yourself.

For Option A, following posts are useful (if you can read or translate Japanese).

https://qiita.com/yutopp/items/7e042c04331b47506e95 , https://noyuno.github.io/2018-06-01-mozc

And, there is modified PKGBUILD at https://github.com/nozaki87/svntogit-community/blob/fcitx-mozc-w-emacshelper/fcitx-mozc/trunk/PKGBUILD .

You can use this PKGBUILD off-the-shelf at your own risk.

For Option B, there are good posts (also written in Japanese).

http://ain0204.hatenablog.com/entry/2016/08/12/235206 , https://qiita.com/hattorix@github/items/909df7f4bf01e57320c0

Sorry if this is off-topic...

cobaltspace commented on 2019-12-24 10:52 (UTC)

Is there a way to not conflict with fcitx-mozc?

ponsfoot commented on 2019-11-05 11:11 (UTC)

@adam900710: Emacs should not be required as deps/makedeps by default. Only required when `_emacs_mozc="yes"' is defined in PKGBUILD (uncomment line 4).

adam900710 commented on 2019-11-04 02:38 (UTC)

Can we have a PKGBUILD for guys don't care about Emacs? That dep for Emacs is pretty annoying, even just a makedep.

xuanruiqi commented on 2019-02-18 06:20 (UTC)

Sorry for this question which might be stupid. Is there a way such that I can use Mozc in both fcitx and Emacs? If I try to install the Mozc package here, then it conflicts with fcitx-mozc. But if I do not, then I cannot install emacs-mozc.

ponsfoot commented on 2019-02-04 12:06 (UTC)

@god:

Could you make the Kana input mode's layout to that of Windows (en-US) or at least add an option to set it so?

I think, it's not related to mozc, related to IM framework (i.e. ibus, uim). I can input 'ろ' (` key) with Kana input mode on en_US.UTF-8 (I use ASCII layout keyboard and uim). If you set the input mode only on mozc setting, check IM framework setting.

Could you make the Mozc Settings dialogue scale properly on high DPI Wayland, or at least make the dialogue resizeable?

It's a Qt5 issue, isn't it? (I don't have HiDPI monitor) Same issue has been reported in the past: https://github.com/google/mozc/issues/326

god commented on 2019-02-04 10:05 (UTC)

Thank you for your work. I have two wishes:

  1. Could you make the Kana input mode's layout to that of Windows (en-US) or at least add an option to set it so? That is, the ` key should input ろ, not ゛, like this picture (https://i.stack.imgur.com/wPzcp.jpg). Fcitx-Mozc also works this way, but unfortunately, I could not get fcitx-mozc work on Gnome.

  2. Could you make the Mozc Settings dialogue scale properly on high DPI Wayland, or at least make the dialogue resizeable? Currently, it looks like this: https://imgur.com/a/MXaiJcU

redboltz commented on 2018-12-01 07:59 (UTC)

Thank you! I can get the version 2.23.2815.102-3 now.

ponsfoot commented on 2018-12-01 05:54 (UTC)

@redboltz : It should be fixed now. Thank you for the feedback.

redboltz commented on 2018-12-01 04:16 (UTC) (edited on 2018-12-01 04:17 (UTC) by redboltz)

It seems that mozc version is still 2.20.2673.102-2.

I did

pacman -Syu

then

pacman -Ss mozc

got the following result:

community/fcitx-mozc 2.23.2815.102-2
    Fcitx Module of A Japanese Input Method for Chromium OS, Windows, Mac and Linux (the Open Source Edition of Google Japanese Input)
pnsft-pur/emacs-mozc 2.23.2815.102-2 (mozc-im)
    Mozc for Emacs
pnsft-pur/ibus-mozc 2.23.2815.102-3 (mozc-im)
    IBus engine module for Mozc
pnsft-pur/mozc 2.20.2673.102-2 (mozc-im)
    A Japanese Input Method for Chromium OS, Windows, Mac and Linux (the Open Source Edition of Google Japanese Input)
pnsft-pur/uim-mozc 2.23.2815.102-1 (mozc-im)
    uim plugin module for Mozc

My /etc/pacman.conf contains the following setting:

[pnsft-pur]
SigLevel = Optional TrustAll
Server = https://osdn.net/projects/ponsfoot-aur/storage/pur/x86_64

Am I missing something?

ponsfoot commented on 2018-10-31 10:21 (UTC)

@MaxMilton: Okay. I'll move them. Please wait.

MaxMilton commented on 2018-10-30 19:35 (UTC)

Package fails to install due to SHA1 sum mismatch. Looks like instead of downloading the jigyosyo-201805.zip and x-ken-all-201805.zip files, it instead fetches the sourceforge download page. Please move your packages away from sourceforge -- GitHub etc. is be a much better option now-a-days.

ponsfoot commented on 2018-05-31 12:32 (UTC)

@MightyPork: Applied, Thank you for the patch.

MightyPork commented on 2018-05-27 10:26 (UTC) (edited on 2018-05-27 10:29 (UTC) by MightyPork)

This package does not build.

Fix by using custom.patch (fixes the build error and also enables hiragana by default, so you don't need to click in the tray menu)

https://gist.githubusercontent.com/MightyPork/6b93f56b404e526268ac133f1a783afd/raw/40b3b9569d4b0741d78c511b247b26d2b1e7a2ae/mozc.patch

and adding

patch -Np0 -i "${srcdir}/custom.patch"

at the top of prepare () {

then run updpkgsums and makepkg -f

ponsfoot commented on 2018-03-02 13:15 (UTC)

Hi,

I intend to bump latest commit of mozc (which fixes ibus-mozc issue) with latest zipcode but cannot it due to sf.net trouble. Please give me some time. I might change file hosting service.

Thx

polm23 commented on 2017-09-11 07:14 (UTC)

Minor issue: This requires pkg-config, but it's not listed as a dependency. Noticed setting it up on a fresh machine.

linkmauve commented on 2017-04-20 13:43 (UTC)

Hi, on an up to date ArchLinux, using clang 4.0 from testing, I get this error when building this PKGBUILD: clang-4.0: error: unknown argument: '-fvar-tracking-assignments' If I remove it from the DEBUG_CFLAGS and the DEBUG_CXXFLAGS in /etc/makepkg.conf it does build. Since this argument is present in the default configuration, you should probably workaround it somehow.

ponsfoot commented on 2017-04-16 09:59 (UTC)

@Eschwartz: It should be fixed on 2.20.2673.102-2. Thank you for the info.

eschwartz commented on 2017-04-14 17:13 (UTC)

Someone on IRC was having problems building this package with pacaur, and it turned out that the build system was calling `python` when it expected to get `python2`.[1] Doing some investigating in this PKGBUILD, I see you do actually try to work around this. However... makepkg supports doing the download/extraction/prepare separate from the build, using the logic `makepkg --nobuild && makepkg --noextract`.[2] This is a perfectly valid use case, and PKGBUILDs are expected to work when used like that. Setting environment variables -- in this case $PATH -- within the prepare() function and expecting them to still be available in the build() function breaks this logic and WILL NOT WORK. Please fix your PKGBUILD to conform to proper makepkg standards. :) [1] This is a definite upstream bug, and on my advice that IRC user opened the following bug report which if fixed should remove the need for such hacks: https://github.com/google/mozc/issues/417 [2] pacaur happens to trigger this issue, because it uses separate extraction and build steps for internal reasons. A number of PKGBUILDs that are flawed like this one is, have been discovered as a result.

ponsfoot commented on 2017-01-10 07:38 (UTC)

@mkasu: Please ask fcitx-mozc maintainer if emacs-mozc is not available in it.

mkasu commented on 2017-01-10 05:18 (UTC)

I'm interested in using emacs-mozc together with fcitx-mozc. Down below you said you'd integrate it into a "mozc-svn" package, but I couldn't find one with that name. Any advice?

ponsfoot commented on 2016-11-15 10:48 (UTC)

@AKremlin: Please see nash's latest comment. Is the HiDPI problem fixed on qt5 version? If so, I'll change to use qt5.

AKremlin commented on 2016-11-10 12:21 (UTC)

I understand the reason for keeping the dependency on qt4 until upstream bumps it (it's being held back because of lack of Windows support, but the Github master uses qt5 for linux and OSX). However, I would like to pkgbuild it using qt5, because I can't use the settings dialogue on my high-DPI display. How can I get it to build with qt5? I have qt5 installed on my system.

ponsfoot commented on 2016-10-29 08:30 (UTC) (edited on 2016-10-29 08:32 (UTC) by ponsfoot)

@nash: Specifying version is based on Release History. https://github.com/google/mozc/blob/master/docs/release_history.md Latest version on it is still using qt4.

nash commented on 2016-10-28 22:54 (UTC)

Hi, Is there any reason to use QT4 still? The upstream default is QT5 now and it works well on Arch. --- PKGBUILD.orig 2016-10-28 18:17:19.068887450 +0900 +++ PKGBUILD 2016-10-28 18:19:58.193104521 +0900 @@ -38,7 +38,7 @@ arch=('i686' 'x86_64') url="http://code.google.com/p/mozc/" license=('BSD' 'custom') -makedepends=('python2' 'git' 'ninja' 'clang' 'qt4') +makedepends=('python2' 'git' 'ninja' 'clang' 'qt5-base') #source=("${_svndir}/${_svnmod}::svn+${_svntrunk}" source=( mozc::git+https://github.com/google/mozc.git#commit=${_mozcrev} @@ -105,13 +105,6 @@ done msg2 '=====================================================' - # Use Qt4 - _rcc_loc=`pkg-config QtCore --variable=rcc_location` - _qt4dir=${_rcc_loc%%/bin/rcc} - _qt4i=`pkg-config --cflags-only-I QtGui` - CFLAGS+=" $_qt4i" - CXXFLAGS+=" $_qt4i" - cd "${srcdir}/${pkgbase}/src" msg "Starting make..." @@ -122,8 +115,8 @@ unset CC CC_host CC_target CXX CXX_host CXX_target LINK AR AR_host AR_target \ NM NM_host NM_target READELF READELF_host READELF_target - QTDIR=$_qt4dir GYP_DEFINES="document_dir=/usr/share/licenses/${pkgbase}" \ - python2 build_mozc.py gyp --target_platform=Linux + GYP_DEFINES="document_dir=/usr/share/licenses/${pkgbase}" \ + python2 build_mozc.py gyp --target_platform=Linux --qtver=5 python2 build_mozc.py build -c $_bldtype $_targets if [[ "$_ibus_mozc" == "yes" ]]; then @@ -137,7 +130,7 @@ pkgdesc="A Japanese Input Method for Chromium OS, Windows, Mac and Linux (the Open Source Edition of Google Japanese Input)" arch=('i686' 'x86_64') groups=('mozc-im') - depends=('qt4' 'zinnia') + depends=('qt5-base' 'zinnia') replaces=('mozc-server' 'mozc-utils-gui') conflicts=('mozc-server' 'mozc-utils-gui') optdepends=('tegaki-models-zinnia-japanese: hand-writing recognition support') @@ -190,4 +183,4 @@ # Global pkgdesc and depends are here so that they will be picked up by AUR pkgdesc="A Japanese Input Method for Chromium OS, Windows, Mac and Linux (the Open Source Edition of Google Japanese Input)" -depends=('qt4' 'ibus>=1.4.1' 'zinnia') +depends=('qt5-base' 'ibus>=1.4.1' 'zinnia')

ponsfoot commented on 2016-10-27 12:24 (UTC)

@ploop: It should be fixed now. Thank you for the feedback. FYI, unofficial user repository is available, please see pinned comment (I pinned just now).

ploop commented on 2016-10-26 22:12 (UTC)

When attempting to build mozc, I get this: ==> Starting make... INFO: Generating version definition file... INFO: Version string is 2.18.2612.102 INFO: Running: /usr/bin/python2 /tmp/packerbuild-1000/mozc/mozc/src/mozc/src/build_tools/ensure_gyp_module_path.py --expected=/tmp/packerbuild-1000/mozc/mozc/src/mozc/src/third_party/gyp/pylib/gyp INFO: Running: pkg-config --exists ibus-1.0 >= 1.4.1 INFO: Building GYP command line... INFO: Running: pkg-config --exists QtCore >= 4.0 QtCore < 5.0 QtGui >= 4.0 QtGui < 5.0 INFO: Running GYP... INFO: Running: /usr/bin/python2 /tmp/packerbuild-1000/mozc/mozc/src/mozc/src/third_party/gyp/gyp_main.py --depth=. --include=./gyp/common.gypi -D abs_depth=/tmp/packerbuild-1000/mozc/mozc/src/mozc/src -D ext_third_party_dir=/tmp/packerbuild-1000/mozc/mozc/src/mozc/src/third_party -D python_executable=/usr/bin/python2 ./base/base.gyp ./base/base_test.gyp ./client/client.gyp ./client/client_test.gyp ./composer/composer.gyp ./composer/composer_test.gyp ./config/config.gyp ./config/config_test.gyp ./converter/converter.gyp ./converter/converter_base.gyp ./converter/converter_main.gyp ./converter/converter_test.gyp ./data/test/session/scenario/scenario.gyp ./data/test/session/scenario/usage_stats/usage_stats.gyp ./data_manager/chromeos/chromeos_data_manager.gyp ./data_manager/chromeos/chromeos_data_manager_base.gyp ./data_manager/chromeos/chromeos_data_manager_test.gyp ./data_manager/data_manager.gyp ./data_manager/data_manager_base.gyp ./data_manager/data_manager_test.gyp ./data_manager/oss/oss_data_manager.gyp ./data_manager/oss/oss_data_manager_base.gyp ./data_manager/oss/oss_data_manager_test.gyp ./data_manager/testing/mock_data_manager.gyp ./data_manager/testing/mock_data_manager_base.gyp ./data_manager/testing/mock_data_manager_test.gyp ./dictionary/dictionary.gyp ./dictionary/dictionary_base.gyp ./dictionary/dictionary_test.gyp ./dictionary/file/dictionary_file.gyp ./dictionary/file/dictionary_file_test.gyp ./dictionary/system/system_dictionary.gyp ./dictionary/system/system_dictionary_test.gyp ./engine/engine.gyp ./engine/engine_test.gyp ./gui/gui.gyp ./gyp/tests.gyp ./handwriting/handwriting.gyp ./handwriting/handwriting_test.gyp ./handwriting/zinnia.gyp ./ipc/ipc.gyp ./mac/mac.gyp ./net/jsoncpp.gyp ./net/net.gyp ./net/net_test.gyp ./prediction/prediction.gyp ./prediction/prediction_base.gyp ./prediction/prediction_test.gyp ./protobuf/protobuf.gyp ./protocol/protocol.gyp ./renderer/renderer.gyp ./request/request.gyp ./rewriter/calculator/calculator.gyp ./rewriter/rewriter.gyp ./rewriter/rewriter_base.gyp ./rewriter/rewriter_test.gyp ./server/server.gyp ./session/session.gyp ./session/session_base.gyp ./session/session_test.gyp ./storage/storage.gyp ./storage/storage_test.gyp ./testing/testing.gyp ./transliteration/transliteration.gyp ./transliteration/transliteration_test.gyp ./unix/emacs/emacs.gyp ./unix/ibus/ibus.gyp ./usage_stats/usage_stats.gyp ./usage_stats/usage_stats_base.gyp ./usage_stats/usage_stats_test.gyp -D branding=Mozc -D use_qt=YES -D qt_dir= -D qt_ver=4 -D use_wix=NO -D enable_gtk_renderer=1 -D build_base=/tmp/packerbuild-1000/mozc/mozc/src/mozc/src/out_linux -D build_short_base=out_linux -D warn_as_error=0 -D channel_dev=1 -D enable_cloud_handwriting=0 -D target_platform=Linux -D use_libibus=1 --generator-output=. -G output_dir=out_linux INFO: Done INFO: Running: ninja -C out_linux/Release mozc_server mozc_tool ibus_mozc mozc_renderer ninja: Entering directory `out_linux/Release' [70/801] ACTION Generating Resource file from word_register_dialog.qrc FAILED: gen/gui/word_register_dialog/qrc_word_register_dialog.cc cd ../../gui; /usr/bin/rcc -o ../out_linux/Release/gen/gui/word_register_dialog/qrc_word_register_dialog.cc -name qrc_word_register_dialog word_register_dialog/word_register_dialog.qrc /bin/sh: /usr/bin/rcc: No such file or directory [72/801] CXX obj.host/data_manager/gen/proto_out/data_manager/dataset_proto.dataset.pb.o ninja: build stopped: subcommand failed. Traceback (most recent call last): File "build_mozc.py", line 1235, in <module> main() File "build_mozc.py", line 1222, in main BuildMain(cmd_opts, cmd_args) File "build_mozc.py", line 852, in BuildMain BuildWithNinja(options, targets) File "build_mozc.py", line 826, in BuildWithNinja RunOrDie([ninja, '-C', build_arg] + ninja_targets) File "/tmp/packerbuild-1000/mozc/mozc/src/mozc/src/build_tools/util.py", line 99, in RunOrDie '=========='])) build_tools.util.RunOrDieError: ========== ERROR: ninja -C out_linux/Release mozc_server mozc_tool ibus_mozc mozc_renderer ========== ==> ERROR: A failure occurred in build(). Aborting... The build failed.

ponsfoot commented on 2015-07-18 03:39 (UTC)

@k2_8191: It's not reproduced on my system. Recently, sf.net was under maintenance mode for some hours. Please try again.

k2_8191 commented on 2015-07-17 22:56 (UTC)

During makepkg I got these sha1 errors for now: ==> Validating source files with sha1sums... mozc ... Skipped jsoncpp ... Skipped gyp ... Skipped protobuf ... Skipped japanese_usage_dictionary ... Skipped x-ken-all-201504.zip ... FAILED jigyosyo-201504.zip ... FAILED I'm not sure if it is safely bypassed.

ponsfoot commented on 2015-05-18 15:05 (UTC)

All, Remove $SRCDEST/mozc if it existent (again). The upstream force-updated existing commit hashes. NOTE: pkgrel is not changed because this change doesn't affect the existing 2.17.2095.102 users. @nash: Thank you for the info.

ishitatsuyuki commented on 2015-05-18 09:01 (UTC)

Pacaur: ==> Extracting sources... -> Creating working copy of mozc git repo... fatal: reference is not a tree: 40f67e035d32365dab823d292c173a0d67ad23c7

nash commented on 2015-05-18 02:07 (UTC)

We need to revise the commit id (_mozcrev) in PKGBUILD. https://github.com/google/mozc/issues/290

ponsfoot commented on 2015-05-16 08:25 (UTC)

If you use mozc 2.16.2072.102-1 or earlier and build mozc yourself, remove $SRCDEST/{mozc,gyp} before building 2.17.2095.102-1.

ponsfoot commented on 2015-02-09 10:51 (UTC)

@wiegraffolles: Build preparation (ln -sf `which python2` $srcdir/python in PKGBUILD) seems to failed. Try again. It's not reproduced on my system. If you don't have a strong insistence, try to use unofficial user repository: https://wiki.archlinux.org/index.php/Mozc#Unofficial_user_repository Note: Please show me full build log using http://pastebin.com/ from the next time.

wiegraffolles commented on 2015-02-09 09:55 (UTC)

I get this error when trying to build the latest update: INFO: Running: ninja -j 8 -C out_linux/Release mozc_server mozc_tool ibus_mozc mozc_renderer ninja: Entering directory `out_linux/Release' [8/841] ACTION Generating gen/gui/character_pad/data/cp932_map.h. FAILED: cd ../../gui; python ../build_tools/redirect.py ../out_linux/Release/gen/gui/character_pad/data/cp932_map.h character_pad/data/gen_cp932_map.py ../data/unicode/CP932.TXT File "../build_tools/redirect.py", line 61 print '==========' ^ SyntaxError: Missing parentheses in call to 'print' [8/841] ACTION Generating Resource file from config_dialog.qrc ninja: build stopped: subcommand failed. Traceback (most recent call last): File "build_mozc.py", line 1454, in <module> main() File "build_mozc.py", line 1450, in main procedure[1](cmd_opts, cmd_args, original_directory_name) File "build_mozc.py", line 1070, in BuildMain BuildOnLinux(options, targets, original_directory_name) File "build_mozc.py", line 1026, in BuildOnLinux RunOrDie([make_command] + build_args + target_names) File "/tmp/makepkg/mozc/src/mozc/build_tools/util.py", line 99, in RunOrDie '=========='])) build_tools.util.RunOrDieError: ========== ERROR: ninja -j 8 -C out_linux/Release mozc_server mozc_tool ibus_mozc mozc_renderer ========== ==> ERROR: A failure occurred in build(). Aborting... :: mozc cleaning skipped :: failed to build ibus-mozc,mozc package(s) Any ideas on how to fix it?

m13253 commented on 2015-01-25 14:20 (UTC)

It seems that the latest Mozc source requiers gyp available as a command: Traceback (most recent call last): File "build_mozc.py", line 1478, in <module> main() File "build_mozc.py", line 1474, in main procedure[1](cmd_opts, cmd_args, original_directory_name) File "build_mozc.py", line 958, in GypMain RunOrDie(gyp_command + gyp_options) File "/tmp/yaourt-tmp-brilliant/aur-mozc/src/mozc/build_tools/util.py", line 99, in RunOrDie Maybe we should depend on gyp / gyp-svn, or set $PATH to enable gyp instantly?

ponsfoot commented on 2014-11-03 06:06 (UTC)

ninja is unnecessary as makedepends anymore.

taro-k commented on 2014-10-13 06:48 (UTC)

@ponsfoot Thanks lot for your immediate reply and understanding. Also I am happy about you understood this is general security thing on AUR (and beyond, as you stated.) I am looking forward to the next release.

ponsfoot commented on 2014-10-13 05:26 (UTC)

@taro-k: I can see how you feel (but, in your opinion, all binary repos and many other distros which provides source tar balls themselves like debian, fedora etc. have same concern). Actually, getting source from upstream directly is easier than current style for maintenance. You think 1 min for download is just 'only' (and you should downloaded depot_tools using git, too), I will accommodate a request from you (on the next release) if there is no opposition from other people. mozc-svn is suitable for your concern.

taro-k commented on 2014-10-13 03:25 (UTC)

@ponsfoot thx. IMO, not trivial amount of users have concern about security/privacy especially for this kind of program. The direct download from upstream must make this point clear at least. If you don't like to do that, I will submit another package based on your great work. For such users, some additional makedepends don't matter. Also I just downloaded by svn but it took only 1 min. with narrow band not in developed country.

ponsfoot commented on 2014-10-13 02:08 (UTC)

@taro-k: The upstream doesn't provide source tar balls for each version's any more. If you want to get latest version of Mozc from upstream, you have to clone from svn repo. I think it's not efficient for end users as AUR package which requires longer download time and svn as makedepends.

taro-k commented on 2014-10-13 01:32 (UTC)

Hi, thx lot for your contribution. The "source" seems to be the private storage, not official/upstream source tree. I feel it's better the source is downloaded from upstream directly like many of other AUR packages.

ponsfoot commented on 2014-06-07 04:08 (UTC)

@hagabaka: It means that you will build all packages (and install all depends/makedepends) even if there are packages which you won't use. BTW, I noticed that ibus-mozc isn't mandatory (for uim-mozc users). I'll make it configurable.

hagabaka commented on 2014-06-07 02:44 (UTC)

AUR supports split packages without the "true && pkgname" hack now.

felixonmars commented on 2013-12-27 04:55 (UTC)

@julroy67 No, patch is in 'base-devel' group. Building an AUR package expects that you've installed the group.

julroy67 commented on 2013-12-11 20:49 (UTC)

Patch should be in makedepends

ponsfoot commented on 2013-05-28 07:43 (UTC) (edited on 2018-11-30 12:02 (UTC) by ponsfoot)

(repository moved)
Unofficial user repository of Mozc is ready.
If you want to use the repo, add the following into your /etc/pacman.conf

[pnsft-pur]

SigLevel = Optional TrustAll

Server = https://osdn.net/projects/ponsfoot-aur/storage/pur/x86_64

You can specify `pacman -S mozc-im' to choose all of Mozc packages.

See https://wiki.archlinux.org/index.php/Mozc for more detail.

ponsfoot commented on 2013-03-25 11:22 (UTC)

@andrew67: You're right. Fixed in 1.6.1187.102-5. Thank you for the info.

andrew67 commented on 2013-03-25 05:42 (UTC)

Although zinnia only appears as a build dependency, removing it after installation and attempting to launch things results in this: /usr/lib/mozc/mozc_tool: error while loading shared libraries: libzinnia.so.0: cannot open shared object file: No such file or directory So, shouldn't it also be a package dependency?

salviati commented on 2012-10-16 11:42 (UTC)

@ponsfoot Very nice, but your repo doesn't have i686 builds, so only Server = http://downloads.sourceforge.net/project/pnsft-aur/pur/x86_64 makes sense.

ponsfoot commented on 2012-05-11 15:35 (UTC)

@cuihao: Please see the csslayer's comment and my reply on here at Mar. of this year.

cuihao commented on 2012-05-11 12:12 (UTC)

Would you like to add mozc-fcitx to this package? New patch is out: https://code.google.com/p/fcitx/downloads/detail?name=fcitx-mozc-1.5.1053.102-1.patch

ponsfoot commented on 2012-03-30 10:49 (UTC)

Unofficial user repository of Mozc is ready. If you want to use the repo, add the following into your /etc/pacman.conf --- [pnsft-pur] Server = http://downloads.sourceforge.net/project/pnsft-aur/pur/$arch --- You can specify `pacman -S mozc-im' to choose all of Mozc packages. NOTE: It is available x86_64 only and there is no plan to provide i686 packages now.

ponsfoot commented on 2012-03-28 10:45 (UTC)

1.4.1033.102-1: gtest has been removed from makedepends according to upstream.

sokuban commented on 2012-03-27 02:45 (UTC)

A bad habit of installing PKGBUILDs manually is that once I install them I never update them for years until something breaks. I wouldn't be surprised if I last installed it before Apr. 2011. Sorry about that.

ponsfoot commented on 2012-03-26 15:20 (UTC)

@sokuban: Just after starting build the mozc, PKGBUILD tells you which packages will be generated. Some of aur helper tool like yaourt installs all generated packages at once. Mozc was split since Apr. 2011. Please see here's comment log.

sokuban commented on 2012-03-26 14:08 (UTC)

Strange, it has it... Wait... "ibus-mozc"? Oh, I get it now, I feel really dumb; I only installed the mozc package; I didn't notice there was another ibus-mozc package. (I swear before you didn't have to install 2 packages?)

ponsfoot commented on 2012-03-26 11:05 (UTC)

@sokuban: Make sure that there is the mozc.xml in ibus-mozc-*.pkg.tar.xz. If not, it wasn't packaged properly. ibus-mozc-*.pkg.tar.xz should include the followings: $ tar tf ibus-mozc-1.4.1033.102-1-x86_64.pkg.tar.xz .PKGINFO .CHANGELOG usr/ usr/lib/ usr/share/ usr/share/ibus/ usr/share/ibus-mozc/ usr/share/ibus-mozc/dictionary.png usr/share/ibus-mozc/direct.png usr/share/ibus-mozc/tool.png usr/share/ibus-mozc/alpha_full.png usr/share/ibus-mozc/product_icon.png usr/share/ibus-mozc/katakana_half.png usr/share/ibus-mozc/alpha_half.png usr/share/ibus-mozc/katakana_full.png usr/share/ibus-mozc/hiragana.png usr/share/ibus-mozc/properties.png usr/share/ibus/component/ usr/share/ibus/component/mozc.xml usr/lib/ibus-mozc/ usr/lib/ibus-mozc/ibus-engine-mozc

sokuban commented on 2012-03-26 05:19 (UTC)

Indeed mozc.xml is non-existent for some reason.

ponsfoot commented on 2012-03-25 12:43 (UTC)

@sokuban: This works fine on my system. "nothing in ibus's menu" means that Mozc isn't listed in "Select an input method" drop down list of ibus-setup? Then, make sure the /usr/share/ibus/component/mozc.xml is existent. ibus reads it and recognize the ibus-mozc. If mozc.xml is non-existent, ibus-mozc may be not installed properly.

sokuban commented on 2012-03-25 08:50 (UTC)

For some reason it doesn't work for me now. It builds, but when I install it there is nothing in ibus's menu. I didn't touch the PKGBUILD, but it seems ibus is the default so it should work fine right? It had used to work for me last year, but it stopped working after an update so I tried to install the new version, and the new version doesn't seem to work either. I did update gtest to the new version and rebuild as well just in case but that didn't help. Could anyone help?

ponsfoot commented on 2012-03-18 03:19 (UTC)

@csslayer: Added fcitx-mozc in mozc-svn. Thx

csslayer commented on 2012-03-17 16:11 (UTC)

That's where fcitx-mozc get developed. https://github.com/fcitx/mozc/ I'm not sure if this is what you want.

ponsfoot commented on 2012-03-17 10:11 (UTC)

@csslayer: For now, I don't include any external modules (i.e. uim-mozc) into this plain mozc and include them into mozc-svn/-ut. Because such modules have to be updated sometimes to sync new versions of mozc so it will bring on the delay of/frequent release(es) on aur. I'd like to avoid them as for the plain mozc at least. So, I'd like to add fcitx-mozc into mozc-svn. Could you provide it as a git repo? Thx

csslayer commented on 2012-03-17 07:28 (UTC)

Hi, could you please add this patch for Fcitx? http://code.google.com/p/fcitx/downloads/detail?name=fcitx-mozc-1.4.1003.102.patch&can=2&q=#makechanges I have add this for chakra package, you can take this as a reference. (I also take your PKGBUILD as reference too :D ) http://gitorious.org/chakra-packages/apps/blobs/master/mozc/PKGBUILD

ponsfoot commented on 2012-03-08 15:47 (UTC)

1.4.1003.102-3: Sorry, I forgot to remove 'protobuf' from depends. protobuf is always linked statically now so it's unnecessary anymore.

ponsfoot commented on 2012-03-08 14:20 (UTC)

1.4.1003.102-2: makedepends are reverted back to 'gtest' from 'gmock' by upstream (r103)

ponsfoot commented on 2012-03-07 16:14 (UTC)

1.4.1003.102-1: From this release, check and find Qt4 oneself in PKGBUILD without depending on Mozc. If you get any problems during build, please tell me it and you install qt3 or not.

ponsfoot commented on 2012-02-07 12:02 (UTC)

1.3.975.102-2: Reverted the temporary change of $QTDIR (which was for Qt3 users).

ponsfoot commented on 2011-11-30 13:01 (UTC)

1.3.911.102-1: From this release, "emacs-mozc-bin" and "emacs-mozc" are integrated into "emacs-mozc".

ponsfoot commented on 2011-11-30 10:37 (UTC)

@myuhe: FYI. mozc will be bumped to 1.3.911.102 soon.

myuhe commented on 2011-11-30 10:15 (UTC)

To ponsfoot Thank you for your reply!! I confirmed that out of memory :( I will try to build again with increasing swap.

ponsfoot commented on 2011-11-30 02:06 (UTC)

@myuhe: Did you run out of memory?

myuhe commented on 2011-11-29 23:33 (UTC)

I tried to build mozc. but occured error. log is http://pastebin.com/WznPCuH2 I would like some advice!!

commented on 2011-10-30 11:14 (UTC)

Thanks for your help!

ponsfoot commented on 2011-10-30 07:31 (UTC)

@wasabi: Thank you for the log. Unfortunately, I cannot catch cause of your problem. ibus reads /usr/share/ibus/component/*.xml to recognize im modules. ibus-mozc installs /usr/share/ibus/component/mozc.xml. If /usr/share/ibus/component/mozc.xml is existent, ibus doesn't/cannot read it or ibus-mozc may have some problems for what ever reason. Try to run ibus-daemon in verbose mode, ibus may output some messages: $ killall ibus-daemon && ibus-daemon -v (After confirming, Ctrl+C to stop ibus-daemon -v) If /usr/share/ibus/component/mozc.xml is non-existent, ibus-mozc isn't installed properly.

commented on 2011-10-29 16:12 (UTC)

http://pastebin.com/TwWL2ccN

ponsfoot commented on 2011-10-29 15:10 (UTC)

@wasabi: For example; makepkg -sf 2>&1 | tee /tmp/buildlog.txt

commented on 2011-10-29 14:56 (UTC)

How do I get my full build log?

commented on 2011-10-29 12:03 (UTC)

Yes, I can use Anthy. Anthy works in qtFM and urxvt but not in Chromium.

commented on 2011-10-29 11:36 (UTC)

Hi ponsfoot! Thanks for your help. It was 100% my mistake. I didn't change the QT4 option. Now, I have installed ibus-qt and then tried to compile and install mozc (not mozc-svn, by the way) again with makepkg -s, pacman -U , but there is still no Japanese option in ibus-setup. ( I changed qtconfig to ibus).

ponsfoot commented on 2011-10-29 11:07 (UTC)

@wasabi: Can you use other IMs such as anthy properly? Did you install ibus-mozc properly? I'd like to be shown your full build log (using pastebin.com for example).

commented on 2011-10-29 09:37 (UTC)

No, I don't know what happened. Do you want me to give some log info?

ponsfoot commented on 2011-10-29 03:08 (UTC)

@wasabi: Isn't mozc listed in "Select an input method" > "Japanese" dropdown list?

commented on 2011-10-28 22:19 (UTC)

I just installed this but I can't select mozc in ibus-setup. Got no errors like w1ntermute. Any ideas?

ponsfoot commented on 2011-10-03 14:08 (UTC)

1.2.855.102-1: From this release, "mozc-server" and "mozc-utils-gui" are integrated into "mozc" and group name is changed to "mozc-im" to avoid conflict with package name.

ponsfoot commented on 2011-08-25 10:10 (UTC)

@w1ntermute: You can add words into user dictionary using Dictionary tool (or word register dialog). It can be called from language bar of ibus.

w1ntermute commented on 2011-08-24 19:11 (UTC)

Got it to work - the problem is that I was using yaourt, which this package isn't compatible with due to the generation of multiple packages. When I installed it manually, it worked fine. Only one other question - is it possible to edit the mozc dictionary? On the whole, it's much better than Anthy, but there are some words I'd like to add.

ponsfoot commented on 2011-08-23 05:43 (UTC)

@w1ntermute: "all packages" means packages generated by makepkg for mozc, i.e. mozc-server, mozc-utils-gui, and so on (depended on your choice). You cannot find those package files? Then, you may have failed to build. Check build log.

w1ntermute commented on 2011-08-23 05:10 (UTC)

What do you mean by "all packages"? I can't find a package named "mozc-server" or "ibus-mozc".

ponsfoot commented on 2011-08-23 04:37 (UTC)

@w1ntermute: Try to install all packages at once. Each packages are specified to keep the version the same.

w1ntermute commented on 2011-08-22 23:29 (UTC)

OK, I managed to install mozc, albeit with this error message: resolving dependencies... warning: cannot resolve "mozc-server=1.2.809.102", a dependency of "ibus-mozc" :: The following package cannot be upgraded due to unresolvable dependencies: ibus-mozc Do you want to skip the above package for this upgrade? [y/N] y looking for inter-conflicts... Now when I go to the IBus settings and try to add Mozc, it's not listed as an input method under "Japanese".

ponsfoot commented on 2011-08-22 10:24 (UTC)

1.2.809.102-2: From this release, $QTDIR is changed temporarily and forcibly in PKGBUILD by default for Qt3 users. If you are Qt3 user, you don't have to take care $QTDIR now. If you are Qt4 user and set $QTDIR for your customization, uncomment _qtdir= line in PKGBUILD. Please tell me if you are Qt4 user and this change is inconvenient. I'll revert it. If you are using mozc 1.2.809.102-1, you don't need to upgrade to this.

ponsfoot commented on 2011-08-03 16:06 (UTC)

@w1ntermute: Do you have modified gui/qt_libraries.gypi or downgraded libpng to 1.2? Then, $QTDIR should be set '/usr', not '/usr/lib/qt' for mozc at least. And I made temporary patch for this problem and update package. Please try it. If you cannot resolve, please show me full build log next time (using pastebin.com, for example). Actually, you don't paste your actual error message. It should be shown just above line you pasted ;) However, I was able to find the exact cause of the problem by you. Thank you, I will report to upstream.

w1ntermute commented on 2011-08-03 13:07 (UTC)

My QTDIR was set to /opt/qt, which is for Qt3. I set it to /usr/lib/qt (which is for Qt4), but I got this error when I tried again: make: *** [out_linux/Release/obj/gen/gui/tool/qrc_mozc_tool.cc] Error 127 make: *** Waiting for unfinished jobs.... Traceback (most recent call last): File "build_mozc.py", line 898, in <module> main() File "build_mozc.py", line 884, in main BuildMain(original_directory_name) File "build_mozc.py", line 829, in BuildMain BuildOnLinux(options, targets) File "build_mozc.py", line 744, in BuildOnLinux RunOrDie([make_command] + build_args + target_names) File "build_mozc.py", line 549, in RunOrDie '=========='])) __main__.RunOrDieError: ========== ERROR: make -j4 MAKE_JOBS=4 BUILDTYPE=Release mozc_server mozc_tool ibus_mozc

ponsfoot commented on 2011-07-31 06:53 (UTC)

@w1ntermute: Do you use qt3 as default? or customize qt configuration? If yes, please try the following if you have installed qt4 without any customization: `QTDIR= makepkg' (Or set your qt4's path to $QTDIR)

w1ntermute commented on 2011-07-31 04:39 (UTC)

Hi, I'm getting the following error (x64). I saw that aaaarch had a similar issue, but I don't think this is related. In any case, I have pkg-config installed. Exception: Call to 'pkg-config --libs-only-L --libs-only-l xrender xrandr xcursor xfixes xinerama fontconfig freetype2 xi xt xext x11 sm ice gobject-2.0 libpng12' returned exit status 1. while trying to load gui/gui.gyp Traceback (most recent call last): File "build_mozc.py", line 898, in <module> main() File "build_mozc.py", line 890, in main GypMain(deps_file_name) File "build_mozc.py", line 418, in GypMain RunOrDie(command_line) File "build_mozc.py", line 549, in RunOrDie '=========='])) __main__.RunOrDieError: ========== ERROR: /usr/bin/python2 third_party/gyp/gyp --depth=. --include=./gyp/common.gypi -D python_executable=/usr/bin/python2 ./base/base.gyp ./base/base_test.gyp ./build_tools/build_tools.gyp ./build_tools/primitive_tools/primitive_tools.gyp ./client/client.gyp ./client/client_test.gyp ./composer/composer.gyp ./converter/converter.gyp ./converter/converter_base.gyp ./converter/converter_test.gyp ./dictionary/dictionary.gyp ./dictionary/dictionary_base.gyp ./dictionary/dictionary_test.gyp ./dictionary/file/dictionary_file.gyp ./dictionary/system/system_dictionary.gyp ./gui/gui.gyp ./gui/zinnia.gyp ./gyp/tests.gyp ./ipc/ipc.gyp ./mac/mac.gyp ./net/net.gyp ./prediction/prediction.gyp ./protobuf/protobuf.gyp ./renderer/renderer.gyp ./rewriter/rewriter.gyp ./rewriter/rewriter_base.gyp ./rewriter/rewriter_test.gyp ./server/server.gyp ./session/session.gyp ./session/session_base.gyp ./session/session_test.gyp ./storage/storage.gyp ./testing/testing.gyp ./transliteration/transliteration.gyp ./unix/emacs/emacs.gyp ./unix/ibus/ibus.gyp ./unix/scim/scim.gyp ./usage_stats/usage_stats.gyp third_party/rx/rx.gyp -D branding=Mozc -D use_qt=YES -D qt_dir=/opt/qt -D build_base=out_linux -D target_platform=None -D dictionary=desktop

ponsfoot commented on 2011-07-29 10:18 (UTC)

1.1.773.102-2: Due to a change of zipcode archives to .zip files, lha/bin32-lha are dropped from makedepends.

ponsfoot commented on 2011-04-15 15:04 (UTC)

From 1.1.690.102-2, package is split according to upstream as follows: * mozc-server: Server part of the Mozc input method * mozc-utils-gui: Mozc GUI uitilities * ibus-mozc: IBus engine module for Mozc (choosable, default) * scim-mozc: SCIM IMEngine module for Mozc (choosable) * emacs-mozc: Mozc for Emacs (optional) * emacs-mozc-bin: Helper module for emacs-mozc (optional) You can choose which packages to be built. Please see PKGBUILD for detail. Comments, suggestions or bug reports are welcome.

ponsfoot commented on 2010-09-02 04:49 (UTC)

@sokuban: Fixed. Thank you for your report.

sokuban commented on 2010-09-02 01:05 (UTC)

For scim, the icons are in the wrong place, they should be in /usr/share/scim/icons/

ponsfoot commented on 2010-08-11 15:37 (UTC)

@aaaaarch: Is the pkg-config installed on your system?

commented on 2010-08-11 14:30 (UTC)

Compile error: ==> Validating source files with sha1sums... mozc-0.12.422.102.tar.bz2 ... Passed ==> Extracting Sources... -> Extracting mozc-0.12.422.102.tar.bz2 with bsdtar ==> Starting build()... Copying file to: third_party/rx/rx.gyp Build tool: make Running: pkg-config --exists ibus-1.0 Traceback (most recent call last): File "build_mozc.py", line 775, in <module> main() File "build_mozc.py", line 767, in main GypMain(deps_file_name) File "build_mozc.py", line 304, in GypMain gyp_file_names = GetGypFileNames() File "build_mozc.py", line 167, in GetGypFileNames RunOrDie(['pkg-config', '--exists', 'ibus-1.0']) File "build_mozc.py", line 458, in RunOrDie process = subprocess.Popen(argv) File "/usr/lib/python2.6/subprocess.py", line 633, in __init__ errread, errwrite) File "/usr/lib/python2.6/subprocess.py", line 1139, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Aborting... What's the problem? Thanks!

ponsfoot commented on 2010-08-10 08:08 (UTC)

You can choose the input method framework to use either ibus, scim or both. Only ibus-mozc is enabled by default. If you want to use with scim, edit PKGBUILD, i.e. uncomment "_scim_mozc=" line and you can comment out "_ibus_mozc=" to disable ibus-mozc if unnecessary. The dependencies (ibus, scim or both) are modified in accordance with your choice automatically. Please see PKGBUILD for detail.