[bug#52576] gnu: ibus-anthy: Update to 1.15.12

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
https://logs.guix.gnu.org/guix/2022-06-27.log).

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

```
```

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,

> Higashi-san, Maxim Cournoyer, isn't any of you using ibus-anthy ? Don't
> you face this issue too ?

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,

>> Higashi-san, Maxim Cournoyer, isn't any of you using ibus-anthy ? Don't
>> you face this issue too ?
>
> I am currently using ibus-anthy 1.15.14 and have not experienced any
> problems.

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,

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 :

> >> Higashi-san, Maxim Cournoyer, isn't any of you using ibus-anthy ?
> >> Don't you face this issue too ?  
> >
> > I am currently using ibus-anthy 1.15.14 and have not experienced any
> > problems.  
> 
> 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,

> 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 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,

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

> ```
> $ echo $GI_TYPELIB_PATH
> /gnu/store/hwz7vhykh8iijwdrcbn…

Ohhh that's really interesting, the variable is set for you whenever
you enter a prompt ? In my regular user environment, it is unset !

> /gnu/store/…

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.

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

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

>> ```
>> $ cat ~/.guix-profile/libexec/ibus-setup-anthy
>>
>
> 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.

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
```

> Higashi-san, thanks a lot for your tremendous support in addition to
> having provided the original version upgrade !

You're welcome. This package is very important for Japanese users and I
am willing to help you to solve the problem.

Regards,

> 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
> ```

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
```

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

[...]

>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.

[...]

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,

Am Mittwoch, dem 29.06.2022 um 22:25 -0400 schrieb Maxim Cournoyer:
> 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.
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:
> I can push a fix today at night or tomorrow at latest.
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:

> Pushed a fix after doing some basic checks in qemu.  I hope this solves
> all our Japanese typing and ibus-anthy package style issues.

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