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 677120 - Pinpoint fails to load files if the pinpoint binary is not in the current working directory
Pinpoint fails to load files if the pinpoint binary is not in the current wor...
Status: RESOLVED WONTFIX
Product: pinpoint
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Pinpoint maintainer(s)
Pinpoint maintainer(s)
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2012-05-30 20:10 UTC by Jean-François Fortin Tam
Modified: 2018-08-17 19:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
makes pinpoint look for transitions it its source directory no matter what is the current working directory (1.25 KB, patch)
2012-05-30 20:47 UTC, Antonio Terceiro
rejected Details | Review
better fix (1.28 KB, patch)
2012-05-30 22:16 UTC, Antonio Terceiro
rejected Details | Review

Description Jean-François Fortin Tam 2012-05-30 20:10:59 UTC
jeff@krom:~/Documents/présentations/foo bar$
    ~/dev/pinpoint/pinpoint baz.pinpoint

(pinpoint:3950): Clutter-CRITICAL **: clutter_script_load_from_file:
assertion `filename != NULL' failed



(same thing happens if I do:

    /home/jeff/dev/pinpoint/pinpoint \
    "/home/jeff/Documents/présentations/foo bar/baz.pinpoint" 



But not if I do:

jeff@krom:~/dev/pinpoint$
  ./pinpoint "/home/jeff/Documents/présentations/foo bar/baz.pinpoint"
Comment 1 Antonio Terceiro 2012-05-30 20:47:49 UTC
Created attachment 215280 [details] [review]
makes pinpoint look for transitions it its source directory no matter what is the current working directory
Comment 2 Jean-François Fortin Tam 2012-05-30 20:55:48 UTC
I can confirm that the patch solves the issue on my side! Seems pretty trivial too.
Comment 3 Antonio Terceiro 2012-05-30 22:16:46 UTC
Created attachment 215290 [details] [review]
better fix

this will not leak a hardcoded path in the final binary
Comment 4 Lionel Landwerlin 2012-05-31 00:19:55 UTC
I'm not sure you can actually call this a "bug" or "failure". It's just pinpoint not working a your very particular case.

Is there really a lot of interest in adding a new script and making the main function a little bit more complicated just for this use case?

Where a simple :

#!/bin/sh

set -e

srcdir=$(dirname $0 | xargs readlink -f)

cd $srcdir && ./pinpoint


would avoid changing the C code.
Comment 5 Antonio Terceiro 2012-05-31 18:48:32 UTC
I think it's better to just assume (and maybe document it somewhere) that when uninstalled, pinpoint will only work when run from its source directory.
Comment 6 Jean-François Fortin Tam 2012-06-01 18:10:21 UTC
Then it needs to be clearly documented on the wiki, README, and ideally pinpoint should throw a more informative error in cases like this instead of the cryptic stuff above that makes you think of a fatal bug. But showing a nice error might be almost as much work as handling paths automatically no? ;)
Comment 7 Emmanuele Bassi (:ebassi) 2015-07-29 11:15:42 UTC
Review of attachment 215280 [details] [review]:

No, this is not acceptable.
Comment 8 Emmanuele Bassi (:ebassi) 2015-07-29 11:16:03 UTC
Review of attachment 215290 [details] [review]:

And neither is this.
Comment 9 Emmanuele Bassi (:ebassi) 2015-07-29 11:17:50 UTC
You expect something that is not installed to behave like an installed application, which is completely unreasonable to me. Look at how many applications expose their source directory to themselves when uninstalled.

Either you install Pinpoint into a system location, or you run it uninstalled from within the source directory.
Comment 10 André Klapper 2018-08-17 19:57:16 UTC
pinpoint is not under active development anymore since 2015.
Its codebase has been archived:
https://gitlab.gnome.org/Archive/pinpoint/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the
responsibility for active development again.