Re: [lmi] Headless GUI tests

[Vadim Zeitlin]

On Wed, 14 Oct 2020 22:51:40 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> I try running the GUI test, both with and without xvfb:
GC> 
GC> /opt/lmi/src/lmi[130]$time ./gui_test.sh         
GC> NOTE: starting the test suite
GC> SUCCESS: 21 tests successfully completed.
GC> NOTE: 4 tests were skipped
GC> ./gui_test.sh  26.98s user 6.79s system 78% cpu 43.092 total
GC> 
GC> /opt/lmi/src/lmi[0]$time xvfb-run ./gui_test.sh
GC> NOTE: starting the test suite
GC> SUCCESS: 21 tests successfully completed.
GC> NOTE: 4 tests were skipped
GC> X connection to :99 broken (explicit kill or server shutdown).
GC> X connection to :99 broken (explicit kill or server shutdown).
GC> xvfb-run ./gui_test.sh  28.58s user 9.35s system 37% cpu 1:41.22 total
GC> 
GC> Apparently it's working fine, except that when the test
GC> completes, 'xvfb-run' seems to wait one minute and then
GC> shut down, issuing a "shutdown" diagnostic twice.

 I think I know why do you get these error messages: I believe that the X
server connection is actually opened not by wine itself, but by wineserver
which is launches. But xvfb-run exits once wine command itself does, while
wineserver exits slightly later, so it loses its connection to the server
because it exists earlier.

 This is probably harmless, but the messages are, of course, annoying. To
get rid of them we would need to either use a helper script, which would
run "wine whatever" first and then wait until wineserver exits too before
exiting itself and run this script under xvfb-run. Or avoid using xvfb-run
and have our own wine-xvfb-run script which would do the same thing as
xvfb-run does, i.e. start Xvfb server, launch the program, but then wait
until both it and wineserver exit before killing Xvfb server. I don't know
which one of these approaches is preferable/less ugly, but AFAICS they
should both work.

 But I don't really know where does the one minute delay come from. This is
probably something specific to the GUI test, as I don't see it with a
simple example (unlike the error messages that I do see perfectly well).
I'll try to debug this later, unless you tell me not to (e.g. because
you've decided to use Xpra or because you've already found the reason for
it yourself).


GC> $time xvfb-run ./gui_test.sh                                    
GC> NOTE: starting the test suite
GC> Abnormal-termination handler called. Please report this problem.

 Should I/we look into this or are you already looking or have already
found the source of this problem?

GC> Workaround #2: Because 'xvfb' doesn't seem to be working ideally, I
GC> looked into 'xpra' as an alternative;

 This is very useful too, but I'd be more interested in making xvfb work,
personally, as this would allow us to run GUI tests in GitHub CI builds
too, while Xpra can't be used there.

GC> but when I tried to install it:
GC> 
GC>   (lmi_bullseye_3)root@ugolyok:/opt/lmi/src/lmi# apt-get install xpra
GC>   Reading package lists... Done
GC>   Building dependency tree       
GC>   Reading state information... Done
GC>   Package xpra is not available, but is referred to by another package.
GC>   This may mean that the package is missing, has been obsoleted, or
GC>   is only available from another source
GC> 
GC>   E: Package 'xpra' has no installation candidate
GC> 
GC> What puzzles me is that it's available for everything except bullseye:
GC>   https://packages.debian.org/search?keywords=xpra
GC> How can a package be in [old][old]stable, sid, and experimental,
GC> but not in testing?

 There seems to be a problem with having it in testing due to some
incompatible change in the version 3 which is included in Sid, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963555 and
https://packages.qa.debian.org/x/xpra/news/20200721T043914Z.html

GC> I thought that if testing included a sid
GC> version, and that version wasn't good enough, then the
GC> maintainer would just revert testing to the stable version.

 Apparently the policy is to remove it from testing instead. I don't have a
testing system for testing, but I think you should be able to install the
version of the package from stable on it, shouldn't you?

 Regards,
VZ

pgpnnaGYmgO5K.pgp
Description: PGP signature