Japanese input (anthy) freezes, then falls back to English keyboard

Ask Fedora
1

Hello! I’m new here, so I hope this is a good place to post.

I installed the Japanese (Anthy) input source via Settings=>Keyboard=>Input Sources a while ago, and it has been working fine until about last week. Now, when I try to switch from English to Japanese with super+space, my computer freezes for about 5 seconds, then when I try to type I just get the default layout.

Some things I’ve tried:

  • uninstall via settings => restart => reinstall
  • Chinese pinyin input, which works fine
  • completely removing the Japanese language pack and reinstalling (sudo dnf install langpacks-ja)

Also, I think this error/errors from Logs is relevant (where does Logs get its logs?)

  • dbus: Failed to construct signal
  • and: dbus: wpa_dbus_get_object_properties: failed to get object properties: (org.freedesktop.DBus.Error.Failed) failed to parse RSN IE
  • both from sender wpa_supplicant
2

Update: I updated to F39 and have the same problem.

3

Fixed it with pip install PyGObject! The problem was my conflicting Python installation via asdf.

First I noticed these lines in journalctl:

ibus-setup-anthy.desktop[33568]: Traceback (most recent call last):
ibus-setup-anthy.desktop[33568]:   File "/usr/share/ibus-anthy/setup/main.py", line 35, in <module>
ibus-setup-anthy.desktop[33568]:     from gi import require_version as gi_require_version
ibus-setup-anthy.desktop[33568]: ModuleNotFoundError: No module named 'gi'

Then with some messing around I confirmed that it was using ~/.asdf/installs/python/3.12.1/bin/python3 instead of /usr/bin/python, and only the latter could import gi. So I installed gi with pip. I don’t know why it’s using my asdf installation of python… but this fixed the problem anyhow.

4

It probably is using the version under your users home directory because of the $PATH arrangement for your user.
You can use echo $PATH to see what that value is, and you likely will see directories under your home directory listed before the system binary directories similar to this

$ echo $PATH
/home/jUSERNAME/.local/bin:/home/USERNAME/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin

The path is searched from beginning to end and the first matching executable found is the one used.
The command pip install ..... will by default install to the users python environment since a user run pip cannot write to system directories. On the other hand, sudo pip install .... will install to the system python environment (but using pip to install system-wide is usually a bad idea since it may overwrite system files installed with dnf.)

1 Like
5

When I echo $PATH, ~/.asdf/shims and ~/.asdf/bindo show up first. But the thing is, I checked ~/.bash_profile, ~/.profile, /etc/profile and the files under /etc/profile.d and I couldn’t find any mention of “asdf”, so I don’t know where asdf could be modifying my path.

Also, just based on this it seems like a bad idea to overwrite the python in PATH with a different installation. Is this right?

6

I think the general practice is to install available python packages system-wide as much as possible using dnf and the provided packages.

When it is necessary to use a python version that is different than the system-wide version then it is appropriate to install it at user level using pip. It is also appropriate to install modules that are not available as system packages at user level with pip.

Since I have not used asdf I cannot comment on whether that is appropriate or not. A python venv is almost always user level and installs under the user home directory.

You seemed to indicate that the python installed with asdf under your user home is version 3.12.1 and that is the same as the system-wide version so packages there may conflict especially if not run as a venv.

7

Did you check ~/.bashrc and possibly /etc/bashrc?

8

Did you check ~/.bashrc and possibly /etc/bashrc?

Yes I did, no mention of it there either. I didn’t mention that I’m using the fish shell as default and I do have a line that says source ~/.asdf/asdf.fish, but I figured it was unrelated, especially since commenting it out and running bash still has the same $PATH and which python output. (EDIT: commenting it out and restarting my computer changed that… I didn’t realize $PATH would transfer across shells, and across different runs of fish and bash. Weird)

I think the general practice is to install available python packages system-wide as much as possible using dnf and the provided packages.

This makes a lot of sense – I think using asdf with an overlapping python version is a bit pointless when I think about it. Thanks for the help!