GNU bug report logs - #52576
[PATCH] gnu: ibus-anthy: Update to 1.15.12

Previous Next

Full log

View this message in rfc822 format

From: Alice BRENON <alice.brenon <at> ens-lyon.fr>
To: Taiju HIGASHI <higashi <at> taiju.info>
Cc: 52576 <at> debbugs.gnu.org, maxim.cournoyer <at> gmail.com
Subject: [bug#52576] [PATCH] gnu: ibus-anthy: Update to 1.15.12
Date: Wed, 29 Jun 2022 15:46:34 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.