Le Mon, 07 Feb 2022 12:03:38 +0900, Taiju HIGASHI 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 -> れいわ4). 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.