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 698655 - desktop-app-info test relies on true being in /usr/bin/
desktop-app-info test relies on true being in /usr/bin/
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-04-23 13:22 UTC by Mike Ruprecht
Modified: 2013-05-14 21:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tests: Use /bin if we don't have /usr/bin/true (1.44 KB, patch)
2013-04-23 19:06 UTC, Allison Karlitskaya (desrt)
none Details | Review
gio/tests: Find "true" in PATH opposed to hardcoding the location (1.15 KB, patch)
2013-04-25 07:53 UTC, Mike Ruprecht
committed Details | Review

Description Mike Ruprecht 2013-04-23 13:22:19 UTC
When I run the desktop-app-info test in the gio testsuite, it fails in the test_default test with the following output:

TEST: desktop-app-info... (pid=6027)
  /desktop-app-info/delete:                                            OK
  /desktop-app-info/default:                                           **
GLib-GIO:ERROR:desktop-app-info.c:114:test_default: assertion failed: (g_list_length (list) == 2)
FAIL

This is caused due to create_app_info() using '/usr/bin/true' for the command. On my debian (mostly sid + bits of experimental) system, true is at '/bin/true'.

Is there an acceptable way to locate true, such as or similar to the 'which' command? Would another application be in a more reliably consistent location cross-distro/platform?
Comment 1 Allison Karlitskaya (desrt) 2013-04-23 19:06:08 UTC
Created attachment 242284 [details] [review]
tests: Use /bin if we don't have /usr/bin/true

Some systems don't have /usr/bin/true but have it in /bin/true instead.
Fall back in that case.



Can you take this for a spin and tell me if it fixes the issue?
Comment 2 Matthias Clasen 2013-04-24 00:14:47 UTC
I must say I really hate this kind of obfuscation.

If your system doesn't have /usr/bin/true, you can a) create that or b) live with a failing glib testcase. Its not the end of the world...
Comment 3 Matthias Clasen 2013-04-24 00:30:00 UTC
we could just switch to /bin/true outright, if that is more widely present - I certainly have that on my fedora system.
Comment 4 Colin Walters 2013-04-24 00:51:40 UTC
Do we even need to hardcode the path at all instead of just searching $PATH?
Comment 5 Mike Ruprecht 2013-04-24 01:48:05 UTC
desrt,

The concept works (using access()), but the patch itself does not. access()
returns 0 on success. This patch is backwards, checking for a truthy value
instead.


Matthias,

I'd *really* prefer to not have to mess with a package managed portion of my filesystem, but I'd feel a lot more comfortable writing patches for glib having all tests run. Granted, I could modify it locally, but still.

Also, does Fedora also have /usr/bin/true? I'm kind of curious where that path came from.
Comment 6 Matthias Clasen 2013-04-24 23:01:29 UTC
yes, my system has both /bin/true and /usr/bin/true
Comment 7 Matthias Clasen 2013-04-24 23:15:36 UTC
oh, of course, thats just because of the /bin -> /usr/bin symlink
Comment 8 Mike Ruprecht 2013-04-25 07:53:17 UTC
Created attachment 242392 [details] [review]
gio/tests: Find "true" in PATH opposed to hardcoding the location

Not all systems have /usr/bin/true. Some have it in /bin/true.
Instead of trying to guess a hardcoded path to find it, let
g_app_info_create_from_commandline() internally search PATH
to find the program.
Comment 9 Mike Ruprecht 2013-04-25 07:55:21 UTC
I did some more digging in the code and found that it accepts relative paths. So I cooked up the above patch and with it the testsuite passes for me.
Comment 10 Colin Walters 2013-04-25 09:26:28 UTC
Review of attachment 242392 [details] [review]:

Looks good then, thanks!
Comment 11 Mike Ruprecht 2013-04-25 12:52:06 UTC
Attachment 242392 [details] pushed as c027e88 - gio/tests: Find "true" in PATH opposed to hardcoding the location
Comment 12 Pacho Ramos 2013-05-14 21:46:25 UTC
Could this be committed also to 2.36 branch?