After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 684690 - /appinfo/launch fails due to not having a terminal installed.
/appinfo/launch fails due to not having a terminal installed.
Status: RESOLVED DUPLICATE of bug 790914
Product: glib
Classification: Platform
Component: gio
2.33.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-09-23 23:14 UTC by Wouter van Kesteren
Modified: 2018-02-23 14:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Wouter van Kesteren 2012-09-23 23:14:15 UTC
In commit f89e9deaec3bf279eac5073a30d6d3d7b2a1568b gio/tests/appinfo-test.desktop got a new line saying 'Terminal=true'. 
This line causes failures when the tests are not run under X.

--

When i have none of the terminals specified in gio/gdesktopappinfo.c i get:

  /appinfo/launch:
(gio/tests/.libs/appinfo:2265002): GLib-GIO-WARNING **: couldn't find a terminal, falling back to xterm
FAIL

--

However, when i install xterm i get the following:

  /appinfo/launch:                                                     OK
/usr/bin/xterm: Xt error: Can't open display: 
/usr/bin/xterm: DISPLAY is not set
/usr/bin/xterm: Xt error: Can't open display: 
/usr/bin/xterm: DISPLAY is not set
/usr/bin/xterm: Xt error: Can't open display: 
/usr/bin/xterm: DISPLAY is not set
/usr/bin/xterm: Xt error: Can't open display: 
/usr/bin/xterm: DISPLAY is not set

Obviously this is even worse since the test passes despite there being something horribly wrong.

--

On a side note, the logic in gio/gdesktopappinfo.c, prepend_terminal_to_vector() is quite dodgy.
It checks for terminals, including xterm, and when it can't find it glib gives an error and falls back to xterm...
Comment 1 Martin Pitt 2013-01-15 15:28:52 UTC
For the record, we have the same problem in the Debian/Ubuntu packages, as when we build them we do not have any terminal installed in the build environment. Thus we dropped the Terminal=true flag from it and modified the test:

  http://anonscm.debian.org/viewvc/pkg-gnome/desktop/experimental/glib2.0/debian/patches/92_revert_appinfo_command_line.patch?revision=36583&view=markup

This is not a completely upstreamable patch yet, but if you agree to the general approach of not requiring a Terminal for that test, we can certainly work something out?
Comment 2 Matthias Clasen 2013-01-15 21:22:20 UTC
Well, if we drop the Terminal=true flag, we won't exercise the code paths for launching apps in a terminal anymore. Stating the obvious, I guess.
Comment 3 Martin Pitt 2013-01-16 09:52:23 UTC
Indeed it turns out that xterm is sufficient for that test, and it is not too heavy in terms of build dependencies. So I just installed it in our GNOME git CI environment, and it works all fine now.
Comment 4 Wouter van Kesteren 2013-01-16 17:13:14 UTC
Martin: are you sure they actually pass? As opposed to passing falsely?

I would like to restate that having xterm installed, but running the testsuite WITHOUT X, will result in the above Xt errors and the immediate termination of xterm.

No X + No xterm = FAIL
No X + xterm = FALSE PASS (xterm quits due to lacking X and does NOT run its -e arguement)

This pratically nullifies the test to the point where it might aswell use /bin/true instead of xterm.

I would also like to note that it is pretty undesireable for people not being able to build+test glib (a low level library used in various non graphical things) without pulling in a load of X things. Which has worked fine for ages.

I think the right thing to do is to skip the test when X isn't running and also maybe skip it when a suitable terminal can't be found.
Comment 5 Martin Pitt 2013-01-17 06:26:58 UTC
(In reply to comment #4)
> I would like to restate that having xterm installed, but running the testsuite
> WITHOUT X, will result in the above Xt errors and the immediate termination of
> xterm.
> 
> No X + No xterm = FAIL
> No X + xterm = FALSE PASS (xterm quits due to lacking X and does NOT run its -e
> arguement)
> 
> This pratically nullifies the test to the point where it might aswell use
> /bin/true instead of xterm.

Indeed. In our jhbuild CI server we run everything under xvfb, and that looks fine:


TEST: appinfo... (pid=70020)
  /appinfo/basic:                                                      OK
  /appinfo/text:                                                       OK
  /appinfo/launch:                                                     OK
  /appinfo/show-in:                                                    OK
  /appinfo/commandline:                                                OK
  /appinfo/launch-context:                                             OK
  /appinfo/launch-context-signals:                                     OK
  /appinfo/tryexec:                                                    OK
  /appinfo/associations:                                               **
GLib-GIO:ERROR:appinfo-test.c:11:main: assertion failed: (envvar != NULL)
OK
  /appinfo/environment:                                                OK
  /appinfo/startup-wm-class:                                           OK
  /appinfo/supported-types:                                            OK
  /appinfo/from-keyfile:                                               OK

(The assertion is mentioned in bug 689369). However, I see the same Xt failure in our glib package build, which runs the test suite without X.

> I would also like to note that it is pretty undesireable for people not being
> able to build+test glib (a low level library used in various non graphical
> things) without pulling in a load of X things.

It's not that bad actually. xterm just pulls in a few client-side libraries, no X.org stack, which is why I just added it as a build dependency. That might cause some pain for specialized server-side oriented distros which do not package the X stack, of course.
Comment 6 Matthias Clasen 2013-01-17 22:38:05 UTC
We could just skip the test if DISPLAY is not set.
Would that address your issue ?
Comment 7 Wouter van Kesteren 2013-01-17 23:45:31 UTC
I think it will yes. If you have a patch i'd be happy to try it out for you, if it's too much trouble for you to reproduce locally. (I can imagine you're not to keen on uninstalling all graphical terminals gnome knows about.) :P
Comment 8 Philip Withnall 2018-02-23 14:43:46 UTC
This was fixed in GLib 2.55.1 with bug #790914.

*** This bug has been marked as a duplicate of bug 790914 ***