From: Alice BRENON <alice.brenon@ens-lyon.fr>
To: Taiju HIGASHI <higashi@taiju.info>
Cc: 52576@debbugs.gnu.org, maxim.cournoyer@gmail.com
Subject: [bug#52576] [PATCH] gnu: ibus-anthy: Update to 1.15.12
Date: Wed, 29 Jun 2022 15:46:34 +0200 [thread overview]
Message-ID: <20220629154634.1af99013@ens-lyon.fr> (raw)
In-Reply-To: <8735fnizxj.fsf@taiju.info>
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,
next prev parent reply other threads:[~2022-06-29 14:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-17 13:40 [bug#52576] [PATCH] gnu: ibus-anthy: Update to 1.15.12 Taiju HIGASHI
2021-12-17 16:54 ` Taiju HIGASHI
2021-12-22 22:20 ` Ludovic Courtès
2021-12-23 5:44 ` Taiju HIGASHI
2021-12-24 9:25 ` Taiju HIGASHI
2021-12-24 9:33 ` Taiju HIGASHI
2021-12-24 23:18 ` [bug#52576] [PATCH v2] gnu: ibus-anthy: Update to 1.5.14 Taiju HIGASHI
2022-02-06 15:56 ` [bug#52576] About the upgrade of ibus-anthy Taiju HIGASHI
2022-02-06 20:51 ` Liliana Marie Prikler
2022-02-07 3:03 ` Taiju HIGASHI
2022-02-07 14:50 ` Julien Lepiller
2022-02-07 15:51 ` Taiju HIGASHI
2022-06-24 2:53 ` bug#52576: [PATCH] gnu: ibus-anthy: Update to 1.15.12 Maxim Cournoyer
2022-06-24 3:10 ` [bug#52576] " Taiju HIGASHI
2022-06-24 4:21 ` Liliana Marie Prikler
2022-06-24 14:50 ` Maxim Cournoyer
2022-06-28 8:43 ` Alice BRENON
2022-06-29 8:50 ` Taiju HIGASHI
2022-06-29 9:25 ` Taiju HIGASHI
2022-06-29 13:46 ` Alice BRENON [this message]
2022-06-29 14:06 ` Taiju HIGASHI
2022-06-29 14:19 ` Taiju HIGASHI
2022-06-29 14:35 ` Alice BRENON
2022-06-29 14:49 ` Taiju HIGASHI
2022-06-29 14:56 ` Taiju HIGASHI
2022-06-30 2:25 ` Maxim Cournoyer
2022-06-30 20:15 ` Alice BRENON
2022-07-01 4:22 ` Liliana Marie Prikler
2022-07-02 0:14 ` Liliana Marie Prikler
2022-07-03 1:13 ` Dominic Martinez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220629154634.1af99013@ens-lyon.fr \
--to=alice.brenon@ens-lyon.fr \
--cc=52576@debbugs.gnu.org \
--cc=higashi@taiju.info \
--cc=maxim.cournoyer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).