Ricardo Wurmus skribis:
> Ludo, the patch looks good to me. However, many ibus input methods
> are not provided by the ibus package itself, so for ibus-anthy or
> ibus-libpinyin we would need a different mechanism.
Right.
> Would it make sense to introduce another environment variable
> (e.g.
merge 47576 22707
thanks
Ludo, the patch looks good to me. However, many ibus input
methods are not provided by the ibus package itself, so for
ibus-anthy or ibus-libpinyin we would need a different mechanism.
Would it make sense to introduce another environment variable
(e.g. GUIX_IBUS_COM
Hi,
Mark H Weaver skribis:
> I found them:
>
> ~/.cache/ibus/bus/registry
> /var/lib/gdm/.cache/ibus/bus/registry
>
> On my system, those files include absolute pathnames to programs in
> /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22, which I
> compiled last December.
Looks like <
Hi Julien,
Julien Lepiller writes:
> We should probably fix ibus so it regenerates its cache when it's a
> different process. It could be as simple as using a subdirectory
> computed from the absolute name of the ibus binary, maybe.
Would you like to try?
I won't be able to work more on this bu
On Sat, 2021-04-03 at 03:12 -0400, Mark H Weaver wrote:
> [...]
>
> The following ungrafted libraries are loaded by processes from the
> mysterious old version of 'ibus' on my system: glib, cairo, and libx11.
> I still have no clue where the reference to that mysterious old version
> (/gnu/store/a
Oh! That would explain why I had so much trouble fixing/updating ibus and
ibus-anthy!
We should probably fix ibus so it regenerates its cache when it's a different
process. It could be as simple as using a subdirectory computed from the
absolute name of the ibus binary, maybe.
Le 3 avril 2021
I wrote:
> I still have no clue where the reference to that mysterious old version
> (/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22) is coming
> from.
I found them:
~/.cache/ibus/bus/registry
/var/lib/gdm/.cache/ibus/bus/registry
On my system, those files include absolute pathnames
Earlier, I wrote:
> Looking for references to the old 'glib' was the *first* thing I
> checked. I haven't yet checked anything else, so I don't know how
> widespread this problem is.
I looked for other ungrafted libraries loaded on my system, and I'm glad
to report that I see no evidence of any g
Here's an obvious check that I should have included in my last message:
--8<---cut here---start->8---
mhw@jojen ~$ guix gc --referrers
/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22
/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22
mhw@jojen ~$
Several processes on my Guix system load shared libraries from the
*ungrafted* glib: specifically, all of the subprocesses of
'ibus-daemon'.
The 'ibus-daemon' process itself seems to be properly grafted. However,
its subprocesses are from an old, ungrafted build of 'ibus':
--8<---cut
10 matches
Mail list logo
