Unable to get Subsurface running on Ubuntu 19.10 (eoan)

38 views
Skip to first unread message

Siggi

unread,
Nov 5, 2019, 2:56:31 PM11/5/19
to Subsurface Divelog
The "official" way tu install seems to be using the snap. However, that is neither able to print nor to access the USB adapter for dive computer downloads. It doesn't even seem to remember the path to my log across restarts of the application.

As there doesn't seem to be an eoan package in the PPA, yet, Ive tried to rebuild the xenial package from source:
- added "deb-src http://ppa.launchpad.net/subsurface/subsurface/ubuntu xenial main" to sources list
- apt install build-essential
- apt build-dep subsurface
- cd subsurface-4.9.3; fakeroot debian/rues binary

That fails due to a lacking private header:
In file included from .../subsurface-4.9.3/googlemaps/qgeoserviceproviderplugingooglemaps.cpp:5:
.../subsurface-4.9.3/googlemaps/qgeotiledmappingmanagerenginegooglemaps.h:4:10: fatal error: QtLocation/private/qgeotiledmappingmanagerengine_p.h: Datei oder Verzeichnis nicht gefunden
    4 | #include "QtLocation/private/qgeotiledmappingmanagerengine_p.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

However, it seems to produce an almost-working binary in subsurface-build/subsurface

That binary fails to load the missing "googlemaps" plugin (makes sense). Plus it seems to freeze every now and then, rendering the whole gnome session unresponsive.

Any ideas how to get subsurface up and running, again?

I've even considered reinstalling on Debian, but unfortunately, the flaky mobile connection on this dive trip won't allow such big downloads...

Dirk Hohndel

unread,
Nov 6, 2019, 1:42:50 AM11/6/19
to Subsurface Divelog, Michał Sawicz
The Snap is maintained by Michał - but I think what you observe is a result of the sandboxing rules.
The fact that a rebuild from source deb doesn't work is an annoying side effect of the way the private Qt headers are packaged.
The easiest way to build from source would be to build from the official sources GitHub.com/Subsurface-divelog/subsurface
The steps are reasonably well documented in the the INSTALL file (which I note will need some updating again).
I suggest you check out the last release (v4.9.3), install the dependencies as noted in the INSTALL file (the ones for Ubuntu 18.04 should still be correct) and then just run subsurface/scripts/build.sh as explained in the INSTALL file.

If that fails for any reason, please let me know so I can fix the documentation :-)

Thanks

/D 

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/2115ced4-819b-496f-985e-e370bfb26d22%40googlegroups.com.

Miika Turkia

unread,
Nov 6, 2019, 2:31:00 PM11/6/19
to Subsurface Divelog
Subsurface is now available on our Launchpad repository.On Tuesday, November 5, 2019 at 9:56:31 PM UTC+2, Siggi wrote

Michał Sawicz

unread,
Nov 8, 2019, 10:07:04 AM11/8/19
to subsurfac...@googlegroups.com, Siggi
W dniu 05.11.2019 o 20:56, Siggi pisze:
> The "official" way tu install seems to be using the snap. However, that
> is neither able to print

That should be fixable, I just never thought to enable that.

> nor to access the USB adapter for dive computer
> downloads.

Did you enable the USB permission? I'm using a USB computer just fine.

You can do it either in the Software Center (click Permissions on the
Subsurface page) or on the console:

$ snap connect subsurface:raw-usb

It's not enabled by default because it allows arbitrary access to USB
devices.

> It doesn't even seem to remember the path to my log across
> restarts of the application.

I believe that's a setting in the General tab, "Default file" section?

HTH,
--
Michał (Saviq) Sawicz <mic...@sawicz.net>

signature.asc
Reply all
Reply to author
Forward
0 new messages