[PATCH] gnu: ibus-anthy: Update to 1.15.12

Hi,

I'm using GNOME (40.4) with Guix, and version 1.5.9 of ibus-anthy had

a problem with ibus-anthy not being able to save settings.

I'm assuming this is the cause, since the release notes say that

ibus-anthy version 1.5.10 includes a fix for migrating from dConf to

GSettings.

1.5.10 adds a test, but I skipped running the test. I wish I had a

better solution, but the fix including the test was difficult for me.

It also included tests for users to enter values in dialogs and to

update files under their home directories, so I thought it would be

better to skip the tests.

I have now applied this fix and am using it comfortably.

Thank you.

---

gnu/packages/ibus.scm | 7 +++++--

1 file changed, 5 insertions(+), 2 deletions(-)

The version in the subject line was wrong, it was 1.5.12.

Hi,

Taiju HIGASHI <higashi@taiju.info> skribis:

Good.

Would it be possible to arrange to skip only the test(s) that expect to

run interactively? It would be more robust than skipping all the tests.

Other than that the change LGTM.

BTW current ‘master’ has GNOME 41; it would be good to see how things

work now.

Thanks,

Ludo’.

Ludovic Courtès <ludo@gnu.org> writes:

Hi Lidovic,

Thank you for the response.

I've been working on a fix for the last few days that would allow me to

avoid skipping tests, but it's very difficult for me.

I tried to refer to how the major distributions implement it, but all of

the following seem to skip the test.

Arch:

Gentoo:

Debian:

The reason for skipping the tests in the Debian build process was described as follows.

It is my understanding that the tests run by `make check` require `make install`.

I contacted the maintainer and he said that version 5.1.13 of ibus-anthy

had been omitted from the release, so I will update to 5.1.13 as soon as

it is released.

I made a mistake, it's 1.5.13.

I'm sorry for the mistake. I did it again.

---

gnu/packages/ibus.scm | 7 +++++--

1 file changed, 5 insertions(+), 2 deletions(-)

Hi,

This case has been stopped for a while, but I'm curious about the

situation.

In the following bug reports, your wise and generous decisions have

given us a chance to expand the base of Japanese users of Guix.

This is the only other bug report that concerns me.

I may not be able to do much more about this issue, but I do recognize

that this is a relatively important issue for the Japanese.

Is there any way to move this forward?

Thanks

Hi Taiju,

Am Montag, dem 07.02.2022 um 00:56 +0900 schrieb Taiju HIGASHI:

ibus-anthy is a so-called leaf package (no other package depends on

it), so once we have a working solution, we can update it

"immediately". However, adding #:tests? #f decreases confidence in a

patch a lot. Since the problem is with a test case that was added, why

not simply disable just that test case(s)? Enabling test cases for

poppler was what gave me the confidence to push to core-updates after

all ?

Hi Liliana,

Thank you for your response.

You are right. My attitude of expecting someone else to solve the

problem was no good.

So far, I haven't even been able to get the tests to run properly on

Guix. Therefore, I can't even properly mention which test is the

problem.

I think it will take a long time to solve this problem due to my lack of

skills.

In particular, I think I will have a hard time reading the intent of the

test code. Also, other distributions skip the tests, so I have no source

to refer to.

I don't know if I will be able to start working on it right away, but I

would like to take the time to tackle it properly.

Le Mon, 07 Feb 2022 12:03:38 +0900,

Taiju HIGASHI <higashi@taiju.info> a écrit :

Hi!

I gave a look at the test failures and found a few issues. I attached

the current diff I have, but it's still not working.

The first test checks that the current year is present is a data file

that helps converting gregorian years to Japanese era (such as 2022 ->

????). However, the file stops at 2021. I fixed that by setting a

fixed year in the test, 2021. Adding 2022 to the data file would have

fixed the issue for now, but in 2023 it would have failed again, and

the time-machine wouldn't work either. That's a time bomb :)

The next test is much more important, and much more difficult to make

it work. First, it needs to open an xorg session, and it needs a bus

session to start ibus. I do that by replacing the check phase with a

call to start dbus and xfvb.

Then, the test fails to find some data in the installation directory,

so I moved the tests after the install phase. It's probably not a real

issue, but it avoids a few warnings. One remains.

The python script that runs the tests fails to use GDK, because the

script that runs it redefines a few variables that are required in a

guix environment, to find gi libraries. I changed the script to only

augment these variables.

Then, the python script tries to open a window on the graphical display

and waits for focus before it starts the tests. Since there is no

interaction possible, I changed the test code to ensure the window is

focused when opened. When creating the window, I use GLib.idle_add to

add an action to run when the main event loop is idle. After that, the

main event loop is started (a call to Gtk.main()). As soon as it

starts, the window is focused and the test starts.

After the window gets focus, the python script starts ibus and

ibus-anthy-test. It complains about not being able to read

/var/lib/dbus/machine-id, but this seems benign. It also complained

about not finding the "profile directory", and after investigation, I

modified anthy itself to introduce GUIX_ANTHY_HOME, which I set before

ibus-anthy tests.

After two test lines, the tests hang, either because of an issue with

ibus-anthy, or the setup of ibus, or because it's waiting for ibus'

window to get focus. At this point, I don't know how to investigate

further.

Hi Julien,

Thank you so much for looking into solving the testing problem! I am very

happy!

I have read your email and the patch, and I can see that this is a very

difficult problem for me, and not one that I can solve.

I probably would not have been able to get to the point where I could

identify and explain the specific problem as you did.

My skills may not be able to help, but if there is anything I can do to

help with verification, etc., I will cooperate.

Hello,

Julien Lepiller <julien@lepiller.eu> writes:

I tried it too; and got a different result [0]. Seeing how not even

upstream run the test suite in a containerized environment and other

projects simply disable it, I think it's reasonable to disable it too

until upstream share more information about how it's supposed to work.

Pushed as 2dc43d7d5b50b3ef6ef506dc2572c9cc3beed334, and salvaged

python-pycotap as 06902a6766f089e4da812876ddcf33e7ba8afce0 (with

improved synopsis and description).

Thanks!

Closing.

Maxim

Hi Maxim,

I'm glad to hear your opinion because I've been stuck.

Yes, I was having trouble because I had disabled testing in other

distributions and had no code to refer to.

Anyway, I'm glad this issue is closed.

Thanks,

--

Taiju

Am Donnerstag, dem 23.06.2022 um 22:53 -0400 schrieb Maxim Cournoyer:

Totally minor, but you forgot a ChangeLog :P

Hi,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Oh, and less minor, I broke the package in

39b118776bbbaed049f8bcafa27bde30d9d0b2f6. Now fixed.

Apologies!

Maxim

Hi,

I have no proof that this merge is the culprit but I updated my system

~24h ago, first time since the merge on friday June the 24th (to

97766323bc6e2b4dcfba4d6b46749a4280bca709, previous update was on the

14th of June, d1f3bba66cc4c1763c7391755d884aaa723c9bb7) and now ibus

fails to load the anthy input method upon startup. The daemon starts

without it, and any time I try to restart it (with `ibus-daemon

-xrv`) loading anthy fails, yielding this stacktrace:

```

Traceback (most recent call last):

File

"/gnu/store/93fbwxycshdz4gcqphcns3dk0x5fxayx-ibus-anthy-1.5.14/share/ibus-anthy/engine/main.py",

line 44, in <module>

import factory

File

"/gnu/store/93fbwxycshdz4gcqphcns3dk0x5fxayx-ibus-anthy-1.5.14/share/ibus-anthy/engine/factory.py",

line 33, in <module>

import engine

File

"/gnu/store/93fbwxycshdz4gcqphcns3dk0x5fxayx-ibus-anthy-1.5.14/share/ibus-anthy/engine/engine.py",

line 42, in <module>

gi_require_version('Anthy', '9000')

File

"/gnu/store/g14amgxwm9sj24p1myw0f2hh109ymjcv-python-pygobject-3.40.1/lib/python3.9/site-packages/gi/__init__.py",

line 126, in require_version

raise ValueError('Namespace %s not available' %

namespace)

ValueError: Namespace Anthy not available

```

I'm surprised to see that version '9000' is expected while anthy

reports version 9100h but I don't really know what should be expected

there.

At least one other person, dominicm could reproduce the issue (see

I don't understand much about the inner workings of ibus, anthy or

pygobject which seems to be doing the actual work of loading Anthy, but

I've tried clearing all caches I could think of as advised by @rekado

and still face the issue. I've tried to diff the working and broken

systems to look for anthy modules and except version differences, added

translations and an appdata XML file removed, I don't see anything (I

removed the number in system-<number>-link to get a relevant diff, and

/dev/fd/63 is the one that used to work, /dev/fd/62 the new one that's

broken as can be acertained by looking at the versions associated to

ibus-anthy).

```

--- /dev/fd/63 2022-06-27 21:31:09.399685309 +0200

+++ /dev/fd/62 2022-06-27 21:31:09.399685309 +0200

@@ -5,9 +5,9 @@

/var/guix/profiles/system-link/profile/lib/libanthydic.so.0

/var/guix/profiles/system-link/profile/lib/libanthyinput.la

/var/guix/profiles/system-link/profile/lib/libanthy.la

+/var/guix/profiles/system-link/profile/lib/libanthygobject-1.0.so.5.0.514

/var/guix/profiles/system-link/profile/lib/libanthygobject-1.0.la

/var/guix/profiles/system-link/profile/lib/libanthygobject-1.0.so.5

-/var/guix/profiles/system-link/profile/lib/libanthygobject-1.0.so.5.0.509

/var/guix/profiles/system-link/profile/lib/libanthydic.so

/var/guix/profiles/system-link/profile/lib/libanthy.so.0.1.0

/var/guix/profiles/system-link/profile/lib/libanthydic.so.0.1.0

@@ -31,15 +31,23 @@

/var/guix/profiles/system-link/profile/share/icons/hicolor/scalable/apps/ibus-anthy.svg

/var/guix/profiles/system-link/profile/share/applications/ibus-setup-anthy.desktop

/var/guix/profiles/system-link/profile/share/ibus-anthy

+/var/guix/profiles/system-link/profile/share/doc/ibus-anthy-1.5.14

/var/guix/profiles/system-link/profile/share/doc/anthy-9100h

-/var/guix/profiles/system-link/profile/share/doc/ibus-anthy-1.5.9

/var/guix/profiles/system-link/profile/share/anthy

/var/guix/profiles/system-link/profile/share/ibus/component/anthy.xml

+/var/guix/profiles/system-link/profile/share/glib-2.0/schemas/org.freedesktop.ibus.engine.anthy.gschema.xml

+/var/guix/profiles/system-link/profile/share/metainfo/org.freedesktop.ibus.engine.anthy.metainfo.xml

/var/guix/profiles/system-link/profile/share/locale/zh_CN/LC_MESSAGES/ibus-anthy.mo

/var/guix/profiles/system-link/profile/share/locale/ja/LC_MESSAGES/ibus-anthy.mo

+/var/guix/profiles/system-link/profile/share/locale/cs/LC_MESSAGES/ibus-anthy.mo

/var/guix/profiles/system-link/profile/share/locale/pt_BR/LC_MESSAGES/ibus-anthy.mo

+/var/guix/profiles/system-link/profile/share/locale/tr/LC_MESSAGES/ibus-anthy.mo

+/var/guix/profiles/system-link/profile/share/locale/hu/LC_MESSAGES/ibus-anthy.mo

+/var/guix/profiles/system-link/profile/share/locale/fi/LC_MESSAGES/ibus-anthy.mo

/var/guix/profiles/system-link/profile/share/locale/fr/LC_MESSAGES/ibus-anthy.mo

+/var/guix/profiles/system-link/profile/share/locale/ko/LC_MESSAGES/ibus-anthy.mo

/var/guix/profiles/system-link/profile/share/locale/el/LC_MESSAGES/ibus-anthy.mo

/var/guix/profiles/system-link/profile/share/locale/uk/LC_MESSAGES/ibus-anthy.mo

+/var/guix/profiles/system-link/profile/share/locale/de/LC_MESSAGES/ibus-anthy.mo

+/var/guix/profiles/system-link/profile/share/locale/es/LC_MESSAGES/ibus-anthy.mo

/var/guix/profiles/system-link/profile/share/locale/ca/LC_MESSAGES/ibus-anthy.mo

-/var/guix/profiles/system-link/profile/share/appdata/ibus-anthy.appdata.xml

```

I then tried to skip PATH resolution and call `ibus-daemon` directly

from the working and broken profiles, and both yield the same error. I

tried diffing these wrappers directly but I didn't get a clear

understanding of the differences between the variables `XDG_DATA_DIRS`,

`GTK_PATH` and `GIO_EXTRA_MODULES` that they set. Finally, I repeat

that my setup was working flawlessly before the upgrade (and still does

if I boot on the older profile), in particular my

$GUIX_GTK3_IM_MODULE_FILE variable is set properly to

/run/current-system/profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache as

advised once by lilyp, and looking at the caches in the directries near

didn't yield anything relevant either.

Higashi-san, Maxim Cournoyer, isn't any of you using ibus-anthy ? Don't

you face this issue too ?

Regards,

Alice

Hi Alice,

I am currently using ibus-anthy 1.15.14 and have not experienced any

problems.

```

$ guix package -I | grep ibus-anthy

ibus-anthy 1.5.14 out /gnu/store/93fbwxycshdz4gcqphcns3dk0x5fxayx-ibus-anthy-1.5.14

```

If I have a different condition than yours, it is that I was using

ibus-anthy, which I maintain on a private channel, so I did not update

from an older version to a newer version.

I just removed ibus-anthy from my private channel as it was recently

fixed by upstream[0].

I would like to help you solve your problem.

I'm not very familiar with IBus or ibus-anthy either, so if you have any

settings or command execution results you would like to compare with my

environment, please let me know.

[0]: https://git.sr.ht/~taiju/taix/commit/d834c66

Best Regards,

--

Taiju

Since the cache (~/.cache/ibus) seemed to refer to the old path, I

expected that deleting it would reproduce the problem in my environment,

but deleting it did not cause the problem.

Regards,

--

Taiju

Hi !

Thanks a lot for taking the time to provide such precious feedback. I

see you're using exactly the same version as I do so it made me think

it must be something in the environment. In particular, I notice you're

using Gnome so that may have a link.

On my side, I finally figured out how the gi lib finds its module

(they're apparently called "typelib"): there's a GI_TYPELIB_PATH

variable (how could I not stumble upon it earlier ? it's right in the

middle of Maxim Cournoyer's commit) governing it. And, looking at it in

detail, I notice the way it's set has changed in

39b118776bbbaed049f8bcaf which now appends the lib/girepository-1.0

found in the *inputs* instead of simply concatenating

/lib/girepository-1.0, to the *outputs*. Looking at the wrapped scripts

`ibus-{engine,setup}-anthy` (that's in the same store object as the

`ibus-daemon` so it should be the same on your system) `ibus-anthy` is

missing from the `GI_TYPELIB_PATH` export in both of them.

I checked that this choice on the way to set the variable indeed has an

inpact on the resolution of modules for pygobject, and, eventually, the

correct loading of ibus-daemon: manually re-exporting my

GI_TYPELIB_PATH to the lib/girepository-1.0 of my current-system

(because, after all, the files — including Anthy-9000.typelib — are

there) allows me to temporarily fix the faulty resolution and run

ibus-daemon correctly (no warning, and anthy is back again).

Higashi-san, could you determine where the ibus-anthy's component of

lib/girepository-1.0 ends up in GI_TYPELIB_PATH ? Maxim Cournoyer, is

the choice to look in inputs instead of outputs deliberate ? If so,

what would be needed to retain your improvement while keeping

GI_TYPELIB_PATH functional ?

I find it strange that we need to manually add the component

corresponding to each and every GI module there in a wrapper script

while guix already assembles them all when a profile is built and it

should be enough to point the variable to the directory in the resulting

profile (I understand there's a problem of when the resolution occurs

here, and my quickfix above is just that : dropping everything and

setting GI_TYPELIB_PATH from the resulting profile I have). Can't

packages carry with them information about how to set the environment,

only once profiles are built out of them ? Or is there a good reason

why guix is designed in a way that this is not possible ?

Best regards,

Alice

Le Wed, 29 Jun 2022 18:25:44 +0900,

Taiju HIGASHI <higashi@taiju.info> a écrit :

I didn't know much about it due to my lack of knowledge, but should I

tell you the value of $GI_TYPELIB_PATH?

The values of the environment variables were as follows.

```

$ echo $GI_TYPELIB_PATH

/gnu/store/hwz7vhykh8iijwdrcbn806gwhpgql8yd-gobject-introspection-1.66.1/lib/girepository-1.0:/gnu/store/d96cmwas9z79q9395h1zgc4f014nm7g4-accountsservice-0.6.55/lib/girepository-1.0:/gnu/store/hyhzc9kg175m4zaq6d1jy0p0d689a7j6-caribou-0.4.21/lib/girepository-1.0:/gnu/store/zgdkkf9i4kq4lgwghrqfphzdhr0m66na-evolution-data-server-3.42.1/lib/girepository-1.0:/gnu/store/1n6r37g4azz6z0dhkgah7xlx89y5mymv-gcr-3.41.0/lib/girepository-1.0:/gnu/store/ry6k1jbaq06d80v5f84na3hm8xxi418f-gdm-40.1/lib/girepository-1.0:/gnu/store/jq5qbzhx0dkz5igih09cpx9x51zh00aj-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/8mwgv1l4byr0jw71dwgpnqmqcrbczcmb-gtk-4.6.1/lib/girepository-1.0:/gnu/store/8shlr35mwqk4vnrbiznmbicfxns6x7qy-gnome-autoar-0.4.3/lib/girepository-1.0:/gnu/store/l0lshbwgibchyh26sq0a3r2w6xs1dpya-gnome-bluetooth-3.34.5/lib/girepository-1.0:/gnu/store/qm1lghgm4x8c72c0qrv76p1nfrsywy6g-gnome-desktop-40.4/lib/girepository-1.0:/gnu/store/13a4n3400i38mqmxcqf5yba6r32iy1r8-graphene-1.10.6/lib/girepository-1.0:/gnu/store/3i2hc8cr8hz9ry3ilkssam2q0bccw12y-gst-plugins-base-1.18.5/lib/girepository-1.0:/gnu/store/0vwc428ypg7g141d4adpndmsyrlvw13p-ibus-1.5.24/lib/girepository-1.0:/gnu/store/1h6m7q1wck6byfsyf8f7ga7qc0n9km09-libgweather-40.0/lib/girepository-1.0:/gnu/store/1g42ms70b8nmbwjg4ynskffxj4higxdd-libnma-1.8.28/lib/girepository-1.0:/gnu/store/zn4w1n62ww8hlwm37sqmfnp0gphlky3l-libsoup-3.0.4/lib/girepository-1.0:/gnu/store/bx3rczvkxf817hgvnanyg6wjpnkwp047-polkit-0.120/lib/girepository-1.0:/gnu/store/2n64l0spfd3w8s962zddpi8n3sbkzfcv-telepathy-logger-0.8.2/lib/girepository-1.0:/gnu/store/d4j77l6rd5arm52p236v4wpm11y1b0ms-upower-0.99.15/lib/girepository-1.0:/gnu/store/php9c1823385l4hs0nzhc872q67nh62i-geoclue-2.5.7/lib/girepository-1.0:/gnu/store/j1civ48k7fl7fjwzl05ci5lxlrhjbvi1-gtk+-3.24.30/lib/girepository-1.0:/gnu/store/rkik4kzh5f6z64i2b1vfzc83ilxrlwxl-libxklavier-5.4/lib/girepository-1.0:/gnu/store/mcbziy6h427j5dhnq1qdjmk3cqa9yfbs-libgee-0.20.3/lib/girepository-1.0:/gnu/store/iy11rhdzjrmdisk3zxvlsd1cdb1qj0iy-libsoup-minimal-2.72.0/lib/girepository-1.0:/gnu/store/mvc4hczjdpzw1h3m83w6wgy36llfhl7n-libsecret-0.20.4/lib/girepository-1.0:/gnu/store/4njhadjz79kdjzrhijq7d01l3a9438gg-libical-3.0.10/lib/girepository-1.0:/gnu/store/pazkqmzcgkq9h2wpjjh0nb32ppslmnkr-gdk-pixbuf-2.42.4/lib/girepository-1.0:/gnu/store/1jgwrm3avgb5qjz4r7jai6cniy3i1a1h-pango-1.50.4/lib/girepository-1.0:/gnu/store/5nqkzrcgwbbk9lnfz73g1nidfp57szlm-gsettings-desktop-schemas-41.0/lib/girepository-1.0:/gnu/store/pcg92yzzkc69q0q4r58bpdii394sik5n-gstreamer-1.18.5/lib/girepository-1.0:/gnu/store/zxnkl4fyswa4778rz2y9fd96h9vqfw4f-geocode-glib-3.26.2/lib/girepository-1.0:/gnu/store/4f6dnap0kvl3mypl4bqgx2f7258l9d03-pango-1.48.10/lib/girepository-1.0:/gnu/store/5shxq8f4f3li37ivi7f9nvwk8ci8srz1-json-glib-1.6.2/lib/girepository-1.0:/gnu/store/p2d403rc23gsgyp4qrgrhnjdq2gr9pvi-atk-2.36.0/lib/girepository-1.0:/gnu/store/03b103kizgjxwab2s5bvfygy0r7qlfik-network-manager-1.32.12/lib/girepository-1.0:/gnu/store/6cv29hxxwb5vj916v9np1lrwbja01g6z-telepathy-glib-0.24.2/lib/girepository-1.0:/gnu/store/32mcq3cfjkinzz8zc3d7ss11mf3a7g9p-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/j61ilxk4aiiaw1v9qx8wm90pr188s4nk-harfbuzz-2.8.2/lib/girepository-1.0:/gnu/store/yk0hfds80z2xx8bjs5gmi1z59gp39pkn-at-spi2-core-2.40.0/lib/girepository-1.0:/home/taiju/.guix-profile/lib/girepository-1.0:/home/taiju/.guix-profile/lib/girepository-1.0

```

I do not explicitly set this environment variable in .bash_profile or

elsewhere.

Regards,

--

Taiju

In addition, I will share the contents of the following file.

```

$ cat ~/.guix-profile/libexec/ibus-setup-anthy

#!/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash

export GUIX_PYTHONPATH="/gnu/store/x5qnvlqgcb73nksrzavpq8pg9xgrfwqv-python-3.9.9/lib/python3.9/site-packages:/gnu/store/0vwc428ypg7g141d4adpndmsyrlvw13p-ibus-1.5.24/lib/python3.9/site-packages:/gnu/store/g14amgxwm9sj24p1myw0f2hh109ymjcv-python-pygobject-3.40.1/lib/python3.9/site-packages${GUIX_PYTHONPATH:+:}$GUIX_PYTHONPATH"

export GI_TYPELIB_PATH="/gnu/store/j1civ48k7fl7fjwzl05ci5lxlrhjbvi1-gtk+-3.24.30/lib/girepository-1.0:/gnu/store/0vwc428ypg7g141d4adpndmsyrlvw13p-ibus-1.5.24/lib/girepository-1.0:/gnu/store/hwz7vhykh8iijwdrcbn806gwhpgql8yd-gobject-introspection-1.66.1/lib/girepository-1.0:/gnu/store/4f6dnap0kvl3mypl4bqgx2f7258l9d03-pango-1.48.10/lib/girepository-1.0:/gnu/store/32mcq3cfjkinzz8zc3d7ss11mf3a7g9p-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/p2d403rc23gsgyp4qrgrhnjdq2gr9pvi-atk-2.36.0/lib/girepository-1.0:/gnu/store/j61ilxk4aiiaw1v9qx8wm90pr188s4nk-harfbuzz-2.8.2/lib/girepository-1.0:/gnu/store/pazkqmzcgkq9h2wpjjh0nb32ppslmnkr-gdk-pixbuf-2.42.4/lib/girepository-1.0:/gnu/store/yk0hfds80z2xx8bjs5gmi1z59gp39pkn-at-spi2-core-2.40.0/lib/girepository-1.0:/gnu/store/j1civ48k7fl7fjwzl05ci5lxlrhjbvi1-gtk+-3.24.30/lib/girepository-1.0${GI_TYPELIB_PATH:+:}$GI_TYPELIB_PATH"

exec -a "$0" "/gnu/store/93fbwxycshdz4gcqphcns3dk0x5fxayx-ibus-anthy-1.5.14/libexec/.ibus-setup-anthy-real" "$@"

```

Regards,

--

Taiju

Ohhh that's really interesting, the variable is set for you whenever

you enter a prompt ? In my regular user environment, it is unset !

I don't see ibus-anthy directly in what you have pasted but since there

are personal profiles in there I assume that's where it comes from.

Indeed, this script being in your user profile suggests that ibus-anthy

is installed for your user, not for the system. That explains why it

works for you (the ibus-anthy package at

/gnu/store/93fbwxycshdz4gcqphcns3dk0x5fxayx-ibus-anthy-1.5.14 contains

lib/girepository-1.0 with Anthy-9000.typelib so it must be in

/home/taiju/.guix-profile/lib/girepository-1.0 too). Since your typelib

contains /home/taiju/.guix-profile/lib/girepository-1.0 (twice, by the

way, you might want to check that), that explains why it happens to

work on your system.

At this point I'm ready to assume that the general behaviour of

installing on a pure system will be that the package is broken and that

it works on your system due to your particular setup and possibly

history of hacking on ibus-anthy. I propose this temporary fix until

this is completely sorted out:

add one of the following lines to ~/.bash_profile:

if ibus-anthy is install system-wide:

```

export GI_TYPELIB_PATH="/run/current-system/profile/lib/girepository-1.0/"

```

otherwise:

```

export GI_TYPELIB_PATH="${HOME}/.guix-profile/lib/girepository-1.0/"

```

And now all I want to know is if we can revert `inputs` back to

`outputs` or if there is a good reason not to do so, and hence what

should be done in that case, but it seems that it is a matter on which

Maxim Cournoyer has the expertise, since he was the one to introduce

the change.

Higashi-san, thanks a lot for your tremendous support in addition to

having provided the original version upgrade !

Kind regards,

Alice

I see, so the problem just doesn't happen to occur in my environment.

Indeed, /home/taiju/.guix-profile/lib/girepository-1.0 has appeared

twice in my environment.

As you might have guessed, there was also Anthy-9000.typelib.

```

ls /gnu/store/93fbwxycshdz4gcqphcns3dk0x5fxayx-ibus-anthy-1.5.14/lib/girepository-1.0

Anthy-9000.typelib

```

You're welcome. This package is very important for Japanese users and I

am willing to help you to solve the problem.

Regards,

--

Taiju

It also existed under ~/.guix-profile.

```

$ ls /home/taiju/.guix-profile/lib/girepository-1.0/Anthy-9000.typelib

/home/taiju/.guix-profile/lib/girepository-1.0/Anthy-9000.typelib

```

--

Taiju

On June 29, 2022 10:35:04 AM EDT, Alice BRENON <alice.brenon@ens-lyon.fr> wrote:

[...]

[...]

Seems an oversight on my part, apologies! 'inputs' in

+ ,(search-input-directory

+ inputs "lib/girepository-1.0")))))

Should have been 'outputs'. Unfortunately I'm nowhere near a keyboard for a week, so won't be able to commit the trivial fix in that time.

Thanks,

Maxim

Hi,

Alright, thanks for the last missing piece of the puzzle.

Here is a fix hopefully not too different from the one you'd have

written. If everyone agrees on it, I think someone with commit rights

could merge it on master even before you come back closer to a proper

keyboard to avoid more users hitting the problem. And, in any case,

before this happens there's the quickfix I suggested above : )

Cheers,

Alice

Le Wed, 29 Jun 2022 22:25:24 -0400,

Maxim Cournoyer <maxim.cournoyer@gmail.com> a écrit :

Am Mittwoch, dem 29.06.2022 um 22:25 -0400 schrieb Maxim Cournoyer:

Actually it shouldn't. search-input-directory is as the name implies

meant for inputs, not outputs. outputs should as far as I'm aware

still be used in combination with assoc-ref.

I can push a fix today at night or tomorrow at latest.

Cheers

Am Freitag, dem 01.07.2022 um 06:22 +0200 schrieb Liliana Marie

Prikler:

Pushed a fix after doing some basic checks in qemu. I hope this solves

all our Japanese typing and ibus-anthy package style issues.

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

I can confirm this fixed it for me; thank you!