default hamster build to /usr/local results in broken setup

[FelixSchwarz]

This is basically about #221 (opening a new ticket because I don't have any special access privilege for this project). I looked into this and this is for sure a real issue: Basically the default hamster install process is broken. A quick fix could be #276 but I'd like to fix the issue completely. The pull request just shifts the problem to the user.

From my POV all executables must ensure that the "hamster" module can be loaded via sys.path so I guess the executable must manipulate sys.path if necessary. Probably the "waf build" step is the right place to do this. Alternatively we could modify the default path for waf to /usr.

[russmac]

on Debian 8.4 with the /usr prefix (doesnt work with the /usr/local) the install process works, creates all files but the app exceptions.

not sure if its the same thing.

Traceback (most recent call last):
  File "/usr/bin/hamster", line 387, in <module>
    hamster_client.overview()
  File "/usr/bin/hamster", line 152, in overview
    self._launch_window("overview")
  File "/usr/bin/hamster", line 143, in _launch_window
    getattr(server, window_name)()
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
    **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Python.KeyError: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 707, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/lib/hamster-time-tracker/hamster-windows-service", line 38, in overview
    def overview(self): dialogs.overview.show(self.app)
  File "/usr/lib/python2.7/dist-packages/hamster/lib/configuration.py", line 149, in show
    dialog = self.get_dialog_class()(parent, **kwargs)
  File "/usr/lib/python2.7/dist-packages/hamster/overview.py", line 395, in __init__
    self.fact_tree = FactTree()
  File "/usr/lib/python2.7/dist-packages/hamster/widgets/facttree.py", line 219, in __init__
    self.date_label = Label(10, 3)
  File "/usr/lib/python2.7/dist-packages/hamster/widgets/facttree.py", line 59, in __init__
    self.layout = pangocairo.create_layout(self._label_context)
KeyError: 'could not find foreign type Context'

[RoSk0]

Having the same issue as @russmac on Ubuntu 16.04.

[ederag]

@RoSk0 @russmac thanks for the reports.
This was due to missing python-gi-cairo (#278).
And since the python3 migration (say v2.1.1), python3-gi-cairo should be used.

Improved installation instructions are on their way (#369).

[ederag]

@FelixSchwarz I fully agree with your analysis, and would tend to choose your last suggestion,
for the time being.

Since the hamster-time-tracker.schemas gconf file has to be installed by default in
/etc/gconf/schemas/ anyway (not under the prefix),
make --prefix default to /usr seems consistent.
That would avoid issues such as #425, while leaving full control on the installation path
for experienced users, thanks to --prefix and the new --gconf-dir option planned in PR #421.

[ederag]

Merged PR #421, installs to /usr by default.
So for the casual user relying on defaults, this issue is fixed.
If anyone really wants to install to /usr/local the --prefix=/usr/local option would work.
Note that the gconf schemas are still installed under /etc/gconf by default.
The --gconf-dir option is there for packagers mainly,
installing elsewhere seems highly non-standard.

Thanks for your contributions !