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

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

[Taiju HIGASHI]

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

diff --git a/gnu/packages/ibus.scm b/gnu/packages/ibus.scm
index edaeb59641..889b71f3c2 100644
--- a/gnu/packages/ibus.scm
+++ b/gnu/packages/ibus.scm
@@ -9,6 +9,7 @@
 ;;; Copyright © 2020 Vincent Legoll <vincent.legoll@gmail.com>
 ;;; Copyright © 2021 Felix Gruber <felgru@posteo.net>
 ;;; Copyright © 2021 Songlin Jiang <hollowman@hollowman.ml>
+;;; Copyright © 2021 Taiju HIGASHI <higashi@taiju.info>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -307,7 +308,7 @@ (define-public libpinyin
 (define-public ibus-anthy
   (package
     (name "ibus-anthy")
-    (version "1.5.9")
+    (version "1.5.12")
     (source (origin
               (method url-fetch)
               (uri (string-append
@@ -315,12 +316,13 @@ (define-public ibus-anthy
                     version "/ibus-anthy-" version ".tar.gz"))
               (sha256
                (base32
-                "1y8sf837rmp662bv6zakny0xcm7c9c5qda7f9kq9riv9ywpcbw6x"))))
+                "1fspvzgxr3r086515kap187n684gza3i25xbdqvr5qkaskfmirz9"))))
     (build-system gnu-build-system)
     (arguments
      '(#:configure-flags
        ;; Use absolute exec path in the anthy.xml.
        (list (string-append "--libexecdir=" %output "/libexec"))
+       #:tests? #f ; The tests in this package include test cases with user input, so skip them.
        #:phases
        (modify-phases %standard-phases
          (add-after 'install 'wrap-programs
@@ -338,6 +340,7 @@ (define-public ibus-anthy
                #t))))))
     (native-inputs
      `(("gettext" ,gettext-minimal)
+       ("glib:bin" ,glib "bin")
        ("intltool" ,intltool)
        ("pkg-config" ,pkg-config)
        ("python" ,python)))
-- 
2.34.0

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

[Taiju HIGASHI]

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

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

[Ludovic Courtès]

Hi,

Taiju HIGASHI <higashi@taiju.info> skribis:

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

Good.

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

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

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

[Taiju HIGASHI]

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

Hi Lidovic,

Thank you for the response.

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

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:
https://github.com/archlinux/svntogit-community/blob/dce2fe2721db394fdf91cea5268dc9d636df0249/trunk/PKGBUILD

Gentoo:
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-i18n/ibus-anthy/ibus-anthy-1.5.13.ebuild?id=fc38e3f625d2aee08a90e2eb19a80ccadf945094

Debian:
http://deb.debian.org/debian/pool/main/i/ibus-anthy/ibus-anthy_1.5.13-1.debian.tar.xz

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

> we do not make test for now since it needs a running ibus-daemon instance.

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

> Hi,
>
> Taiju HIGASHI <higashi@taiju.info> skribis:
>
>> 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.
>
> Good.
>
>> 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.
>
> 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’.

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

[Taiju HIGASHI]

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.

https://github.com/ibus/ibus-anthy/issues/26

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

[Taiju HIGASHI]

I made a mistake, it's 1.5.13.
I'm sorry for the mistake. I did it again.

[bug#52576] [PATCH v2] gnu: ibus-anthy: Update to 1.5.14

[Taiju HIGASHI]

---
 gnu/packages/ibus.scm | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/ibus.scm b/gnu/packages/ibus.scm
index edaeb59641..11eececb4f 100644
--- a/gnu/packages/ibus.scm
+++ b/gnu/packages/ibus.scm
@@ -9,6 +9,7 @@
 ;;; Copyright © 2020 Vincent Legoll <vincent.legoll@gmail.com>
 ;;; Copyright © 2021 Felix Gruber <felgru@posteo.net>
 ;;; Copyright © 2021 Songlin Jiang <hollowman@hollowman.ml>
+;;; Copyright © 2021 Taiju HIGASHI <higashi@taiju.info>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -307,7 +308,7 @@ (define-public libpinyin
 (define-public ibus-anthy
   (package
     (name "ibus-anthy")
-    (version "1.5.9")
+    (version "1.5.14")
     (source (origin
               (method url-fetch)
               (uri (string-append
@@ -315,12 +316,13 @@ (define-public ibus-anthy
                     version "/ibus-anthy-" version ".tar.gz"))
               (sha256
                (base32
-                "1y8sf837rmp662bv6zakny0xcm7c9c5qda7f9kq9riv9ywpcbw6x"))))
+                "16vd0k8wm13s38869jqs3dnwmjvywgn0snnpyi41m28binhlssf8"))))
     (build-system gnu-build-system)
     (arguments
      '(#:configure-flags
        ;; Use absolute exec path in the anthy.xml.
        (list (string-append "--libexecdir=" %output "/libexec"))
+       #:tests? #f ; The tests in this package include test cases with user input, so skip them.
        #:phases
        (modify-phases %standard-phases
          (add-after 'install 'wrap-programs
@@ -338,6 +340,7 @@ (define-public ibus-anthy
                #t))))))
     (native-inputs
      `(("gettext" ,gettext-minimal)
+       ("glib:bin" ,glib "bin")
        ("intltool" ,intltool)
        ("pkg-config" ,pkg-config)
        ("python" ,python)))
-- 
2.34.0

[bug#52576] About the upgrade of ibus-anthy

[Taiju HIGASHI]

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.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53536

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

[bug#52576] About the upgrade of ibus-anthy

[Liliana Marie Prikler]

Hi Taiju,

Am Montag, dem 07.02.2022 um 00:56 +0900 schrieb Taiju HIGASHI:
> Is there any way to move this forward?
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 🙂

[bug#52576] About the upgrade of ibus-anthy

[Taiju HIGASHI]

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.

[bug#52576] About the upgrade of ibus-anthy

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]

Le Mon, 07 Feb 2022 12:03:38 +0900,
Taiju HIGASHI <higashi@taiju.info> a écrit :

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

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.

[-- Attachment #2: ibus-anthy.diff --]
[-- Type: text/x-patch, Size: 6612 bytes --]

diff --git a/gnu/packages/anthy.scm b/gnu/packages/anthy.scm
index 0d86347e88..b662d48d2c 100644
--- a/gnu/packages/anthy.scm
+++ b/gnu/packages/anthy.scm
@@ -48,7 +48,17 @@ (define-public anthy
          (replace 'check
            (lambda _
              (with-directory-excursion "test"
-               (invoke "./anthy" "--all")))))))
+               (invoke "./anthy" "--all"))))
+         (add-after 'unpack 'support-guix-anthy-home
+           (lambda _
+             ;; This is required to test ibus-anthy
+             (with-fluids ((%default-port-encoding "ISO-8859-1"))
+               (substitute* "src-diclib/conf.c"
+                 (("add_val\\(\"HOME\", pw->pw_dir")
+                  "char* home = getenv(\"GUIX_ANTHY_HOME\");
+if(home == NULL)
+  home = pw->pw_dir;
+add_val(\"HOME\", home"))))))))
     (home-page "https://anthy.osdn.jp/")
     (synopsis "Japanese input method")
     (description "Anthy is a Japanese input method for converting
diff --git a/gnu/packages/ibus.scm b/gnu/packages/ibus.scm
index edaeb59641..b8a17df4b5 100644
--- a/gnu/packages/ibus.scm
+++ b/gnu/packages/ibus.scm
@@ -52,10 +52,12 @@ (define-module (gnu packages ibus)
   #:use-module (gnu packages gnome)
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages iso-codes)
+  #:use-module (gnu packages linux)
   #:use-module (gnu packages logging)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages python)
+  #:use-module (gnu packages python-check)
   #:use-module (gnu packages python-xyz)
   #:use-module (gnu packages python-web)
   #:use-module (gnu packages serialization)
@@ -307,7 +309,7 @@ (define-public libpinyin
 (define-public ibus-anthy
   (package
     (name "ibus-anthy")
-    (version "1.5.9")
+    (version "1.5.14")
     (source (origin
               (method url-fetch)
               (uri (string-append
@@ -315,7 +317,7 @@ (define-public ibus-anthy
                     version "/ibus-anthy-" version ".tar.gz"))
               (sha256
                (base32
-                "1y8sf837rmp662bv6zakny0xcm7c9c5qda7f9kq9riv9ywpcbw6x"))))
+                "16vd0k8wm13s38869jqs3dnwmjvywgn0snnpyi41m28binhlssf8"))))
     (build-system gnu-build-system)
     (arguments
      '(#:configure-flags
@@ -323,6 +325,46 @@ (define-public ibus-anthy
        (list (string-append "--libexecdir=" %output "/libexec"))
        #:phases
        (modify-phases %standard-phases
+         (add-after 'unpack 'fix-date
+           (lambda _
+             (substitute* "data/Makefile.in"
+               ;; The test would get the current year and check if its data
+               ;; contains it.  However, this will fail in the future, as
+               ;; running this test in a later year would fail.
+               ;; XXX: Future versions will have more recent years, change this
+               ;; to the most recent year in data/era.t (last line).
+               (("S_YEAR=.*;") "S_YEAR=2021;"))))
+         (add-before 'check 'pre-check
+           (lambda _
+             ;; Fix running ibus
+             (substitute* "tests/test-build.sh"
+               (("export GSETTINGS_SCHEMA_DIR=")
+                "export GSETTINGS_SCHEMA_DIR=$GSETTINGS_SCHEMA_DIR${GSETTINGS_SCHEMA_DIR:+:}")
+               (("export GI_TYPELIB_PATH=")
+                "export GI_TYPELIB_PATH=$GI_TYPELIB_PATH${GI_TYPELIB_PATH:+:}"))
+             ;; Do not wait for focus, but wait for the window to be available
+             (substitute* "tests/anthytest.py"
+               (("window =") "self.window =")
+               (("window\\.") "self.window.")
+               (("window.show_all\\(\\)")
+                "window.show_all()
+        GLib.idle_add(self.bring_to_front)
+
+    def bring_to_front(self):
+        self.window.present()"))))
+         (delete 'check)
+         (add-after 'install 'check
+           (lambda* (#:key tests? #:allow-other-keys)
+             (when tests?
+               (setenv "HOME" (getcwd))
+               (setenv "GUIX_ANTHY_HOME" (getcwd))
+               (setenv "XDG_DATA_HOME" (getcwd))
+               (setenv "XVFB_SERVER_ARGS" "+iglx -noreset")
+               (setenv "XDG_RUNTIME_DIR" (string-append (getcwd) "/runtime-dir"))
+               (mkdir-p (getenv "XDG_RUNTIME_DIR"))
+               (invoke "dbus-run-session" "--"
+                       "xvfb-run" "-a" "-s" (getenv "XVFB_SERVER_ARGS")
+                       "make" "check"))))
          (add-after 'install 'wrap-programs
            (lambda* (#:key outputs #:allow-other-keys)
              (let ((out (assoc-ref outputs "out")))
@@ -337,12 +379,18 @@ (define-public ibus-anthy
                 '("ibus-engine-anthy" "ibus-setup-anthy"))
                #t))))))
     (native-inputs
-     `(("gettext" ,gettext-minimal)
+     `(("dbus" ,dbus)
+       ("gettext" ,gettext-minimal)
+       ("glib" ,glib "bin") ;for glib-compile-schemas, used by tests
        ("intltool" ,intltool)
        ("pkg-config" ,pkg-config)
-       ("python" ,python)))
+       ("procps" ,procps)
+       ("python-pycotap" ,python-pycotap)
+       ("python-wrapper" ,python-wrapper)
+       ("util-linux" ,util-linux) ;for getopt, used by tests
+       ("xvfb-run" ,xvfb-run)))
     (inputs
-     (list anthy gtk+ ibus gobject-introspection python-pygobject))
+     (list anthy gdk-pixbuf gtk+ ibus gobject-introspection python-pygobject python-pycairo))
     (synopsis "Anthy Japanese language input method for IBus")
     (description "IBus-Anthy is an engine for the input bus \"IBus\").  It
 adds the Anthy Japanese language input method to IBus.  Because most graphical
diff --git a/gnu/packages/python-check.scm b/gnu/packages/python-check.scm
index 05a378601f..3d3067a770 100644
--- a/gnu/packages/python-check.scm
+++ b/gnu/packages/python-check.scm
@@ -2004,3 +2004,21 @@ (define-public python-xunitparser
 Python objects.  It tries to use the objects available in the standard
 @code{unittest} module.")
     (license license:expat)))
+
+(define-public python-pycotap
+  (package
+    (name "python-pycotap")
+    (version "1.2.2")
+    (source
+      (origin
+        (method url-fetch)
+        (uri (pypi-uri "pycotap" version))
+        (sha256
+          (base32 "1v69fxial9i5wlap6wc4igq3hydvxbak7dlgb7cikk8wjgafqf7r"))))
+    (build-system python-build-system)
+    (home-page "https://el-tramo.be/pycotap")
+    (synopsis "Tiny test runner that outputs TAP results to standard output.")
+    (description
+      "This package provides a tiny test runner that outputs TAP results to standard
+output.")
+    (license license:expat)))

[bug#52576] About the upgrade of ibus-anthy

[Taiju HIGASHI]

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.

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

[Maxim Cournoyer]

Hello,

Julien Lepiller <julien@lepiller.eu> writes:

> Le Mon, 07 Feb 2022 12:03:38 +0900,
> Taiju HIGASHI <higashi@taiju.info> a écrit :
>
>> 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.
>> 
>> 
>> 
>
> 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.

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

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

[Taiju HIGASHI]

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

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

[Liliana Marie Prikler]

Am Donnerstag, dem 23.06.2022 um 22:53 -0400 schrieb Maxim Cournoyer:
> Pushed as 2dc43d7d5b50b3ef6ef506dc2572c9cc3beed334, and salvaged
> python-pycotap as 06902a6766f089e4da812876ddcf33e7ba8afce0 (with
> improved synopsis and description).
Totally minor, but you forgot a ChangeLog :P

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

[Maxim Cournoyer]

Hi,

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

> Am Donnerstag, dem 23.06.2022 um 22:53 -0400 schrieb Maxim Cournoyer:
>> Pushed as 2dc43d7d5b50b3ef6ef506dc2572c9cc3beed334, and salvaged
>> python-pycotap as 06902a6766f089e4da812876ddcf33e7ba8afce0 (with
>> improved synopsis and description).
> Totally minor, but you forgot a ChangeLog :P

Oh, and less minor, I broke the package in
39b118776bbbaed049f8bcafa27bde30d9d0b2f6.  Now fixed.

Apologies!

Maxim

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

[Alice BRENON]

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

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

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

[Taiju HIGASHI]

[-- Attachment #1: Type: text/plain, Size: 193 bytes --]

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.

[-- Attachment #2: a screen shot --]
[-- Type: image/png, Size: 77239 bytes --]

[-- Attachment #3: Type: text/plain, Size: 734 bytes --]


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

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

[Taiju HIGASHI]

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

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

[Alice BRENON]

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,

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

[Taiju HIGASHI]

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

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

[Taiju HIGASHI]

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

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

[Alice BRENON]

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

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

[Taiju HIGASHI]

>> ```
>> $ 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,
-- 
Taiju

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

[Taiju HIGASHI]

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

-- 
Taiju

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

[Maxim Cournoyer]

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,

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

[Alice BRENON]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

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 :

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


[-- Attachment #2: 0001-gnu-ibus-anthy-Fix-wrapped-programs.patch --]
[-- Type: text/x-patch, Size: 1676 bytes --]

From e851ab2c68cb2fab26bf686d56fdb1488ef9e78d Mon Sep 17 00:00:00 2001
From: Alice BRENON <alice.brenon@ens-lyon.fr>
Date: Thu, 30 Jun 2022 22:02:22 +0200
Subject: [PATCH] gnu: ibus-anthy: Fix wrapped programs

This is in follow up to 89db6e7ec77bf0f33474e47945755f5ab45e9f06, the
proper fix wasn't to add inputs to the arguments but to use outputs to
set the GI_TYPELIB_PATH.

* gnu/packages/ibus.scm (ibus-anthy)
[phase]{wrap-programs}: Search within outputs instead of inputs to set
GI_TYPELIB_PATH.
---
 gnu/packages/ibus.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/ibus.scm b/gnu/packages/ibus.scm
index 234d4bd75f..9e8b0f124b 100644
--- a/gnu/packages/ibus.scm
+++ b/gnu/packages/ibus.scm
@@ -329,7 +329,7 @@ (define-public ibus-anthy
        #:phases
        (modify-phases %standard-phases
          (add-after 'install 'wrap-programs
-           (lambda* (#:key inputs outputs #:allow-other-keys)
+           (lambda* (#:key outputs #:allow-other-keys)
              (for-each (lambda (prog)
                          (wrap-program (search-input-file
                                         outputs (string-append "libexec/" prog))
@@ -338,7 +338,7 @@ (define-public ibus-anthy
                            `("GI_TYPELIB_PATH" ":" prefix
                              (,(getenv "GI_TYPELIB_PATH")
                               ,(search-input-directory
-                                inputs "lib/girepository-1.0")))))
+                                outputs "lib/girepository-1.0")))))
                        '("ibus-engine-anthy" "ibus-setup-anthy")))))))
     (native-inputs
      (list gettext-minimal
-- 
2.36.1

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

[Liliana Marie Prikler]

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

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

[Liliana Marie Prikler]

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.

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

[Dominic Martinez]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]


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!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]