Re: [Plplot-devel] Qt(5) problems

[Alan W. I. <ir...@be...>]

On 2017-08-28 15:06+0200 Ole Streicher wrote:

> Hi,
>
> on my path to get plplot compiled for Debian, I have a number of
> problems during the execution to the Qt tests. I first was trying to use
> Qt5, since Qt4 is going to be deprecated very soon in Debian [1], but I
> see the same problems with Qt4.
>
> Occasionally, I get now lots messages like
>
> Qt: Session management error: Could not open network socket
> Qt: Session management error: networkIdsList argument is NULL
> QXcbConnection: Could not connect to display :99
>
> The errors may be related to the specific environment that is used
> (xvfb-run); ":99" is the (automatically generated) DISPLAY for that
> case.
>

> Do you have an idea what happens here?

Hi Ole:

I did notice during my recent comprehensive testing with my usual 
X-terminal setup (using a local X server to display a remote desktop
where I was building and testing PLplot on a much more powerful
machine than my local one) that the *noninteractive* part of the tests
failed because of some temporary glitch in my local X server
In this case, I was in a last-minute rush with the
release, and the problem could not be reliably reproduced (the next
attempt of the noninteractive part of the comprehensive tests
succeeded without issues) so all I could do was note the issue and
move on at that time.  But it did seem peculiar to me that any
of our noninteractive tests were dependent on the X server working.

To investigate this potential issue further, I have just now built and
tested PLplot in an environment (Linux console mode) where no X server
is running at all (although all the X headers, etc., were available).
In response to the lack of an X server, our build system's
wish-related part of the Tk configuration failed which in turn
disabled tk.  However, this is the expected result from some Cygwin
experiments Arjen has tried where he attempted to configure PLplot
without the Cygwin X server running.  That was the only difference in
that configuration compared to a more ordinary configuration with an X
server running so all seemed well.  Furthermore, the subsequent build
of the test_noninteractive target (the same one that intermittently
failed due to an X server glitch above) had absolutely no issues with
the lack of X server!  Furthermore, the combination of

# Build all ctest dependencies:
make -j4 all >& all.out

ctest --extra-verbose -j4 >& ctest.out

also showed no issues with the lack of X server (which makes sense
since the "all" target builds no targets that do run-time testing, and
ctest runs essentially the same noninteractive tests as the
test_noninteractive target).  By the way, this was all done with
Qt4, but I don't think Qt5 would be any different.

Of course, in that environment any attempt at interactive testing will fail.  For
example, an attempt to build the test_c_qtwidget target failed as
follows

make VERBOSE=1 test_qtwidget
[...]
Testing subset of C examples for device qtwidget
x01c
/home/software/plplot/HEAD/build_dir/plplot_test/test_c_interactive.sh: line 46: 19881 Aborted                 $DEBUG_CMD "$cdir"/x${index}${lang} -dev $device $NP_OPTION 2> test.error >| "${OUTPUT_DIR}"/x${index}${lang}_${device}.txt
QWidget: Cannot create a QWidget when no GUI is being used
examples/CMakeFiles/test_c_qtwidget.dir/build.make:57: recipe for target 'examples/CMakeFiles/test_c_qtwidget' failed
make[3]: *** [examples/CMakeFiles/test_c_qtwidget] Error 1
make[3]: Leaving directory '/home/software/plplot/HEAD/build_dir'
CMakeFiles/Makefile2:7247: recipe for target 'examples/CMakeFiles/test_c_qtwidget.dir/all' failed
make[2]: *** [examples/CMakeFiles/test_c_qtwidget.dir/all] Error 2
make[2]: Leaving directory '/home/software/plplot/HEAD/build_dir'
CMakeFiles/Makefile2:7254: recipe for target 'examples/CMakeFiles/test_c_qtwidget.dir/rule' failed
make[1]: *** [examples/CMakeFiles/test_c_qtwidget.dir/rule] Error 2
make[1]: Leaving directory '/home/software/plplot/HEAD/build_dir'
Makefile:2106: recipe for target 'test_c_qtwidget' failed
make: *** [test_c_qtwidget] Error 2

So my conclusion is (a) our noninteractive tests are independent of
whether an X server is running or not (as they should be) and (b) the
above problem with the X server that killed "make test_noninteractive"
was likely due to the X server glitch affecting the overall KDE
desktop which in turn created a konsole command-line failure which
killed off that attempt to build the test_noninteractive target.
(Which, of course, has nothing to do with PLplot.)

> Is there a way to disable the Qt tests for a moment?

I would focus for now on making sure the test_noninteractive target
and ctest works, and those results should be independent of any X
server glitches unless such failures are affecting your entire desktop.

But let's assume later on you want to build the test_interactive target to test
the large subset of our interactive components which previous tests
have shown to be reliable which would include for the Qt5 case the test_c_qtwidget
target as well as the test_qt_example and test_pyqt5_example targets.

(By the way, use "make help |grep test | less" in the top of the build
tree to figure out what test targets are available to do run-time
testing.)

However, if that test shows one of the above qt test targets is
failing due to some X server issue, you can simply disable 
test_c_qtwidget, test_qt_example, and/or test_pyqt4_example targets
using respectively -DPLD_qtwidget=OFF, -DPLD_extqt=OFF, and/or
-DENABLE_pyqt5=OFF.

Or a more crude approach for such interactive testing without any
Qt-related components of PLplot would be to disable all such components
using the cmake options -DENABLE_qt=OFF and
-DDEFAULT_NO_QT_DEVICES=ON.

I hope this advice allows you to get through the rest of your
noninteractive testing of PLplot without issues, and once that
result is nailed down, it will be extremely interesting to see
what is going on with your X server and interactive tests
of PLplot.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________