Re: importing smarttrak slg logs

[Willem Ferguson]

On 04/02/2017 01:38, Alessandro Volpi wrote:




 Forwarded Message 
Subject:Re: Fwd: importing smarttrak slg logs
Date:   Fri, 3 Feb 2017 23:15:55 +
From: 	Alessandro Volpi  

To: 	Salvador Cuñat  


CC: 

Dear Salvador,

I have imported my (large) dive_log.slg file, relying on 
smtk2ssrf_test.AppImage. The program did find data formatting errors 
in several dives in the slg file, but, surprisingly, such errors did 
not result in any visible flaw in the imported data for the concerned 
dives. The log of the import operation is attached, in case you are 
curious to have a look at it.


I have opened the imported xml file with the subsurface version 
installed from the Fedora 24 repo.
I was very impressed by the quality of the application you are 
developing and maintaining ... I cannot find good words for qualifying 
it, other than EXCELLENT !


Al details of the dive, including gas switches during sidemount dives, 
were perfectly imported. Before trying subsurface I was planning to 
edit the notes of every single dive in order to insert the data 
concerning fish species spotted during the dive. I was very glad to 
discover that also this information has been automatically added to 
the dive's notes. Therefore the log is perfectly good as it is and no 
manual editing intervention is needed!


Also the management of dive sites and their coordinates is better than 
my more optimistic forecasts.


I am very grateful to you for your prompt answer to my messages 
concerning my difficulties in building subsurface and smtk2ssrf on 
Fedora 24.


I do not need to do that once again, since I have a working instance 
of both programs. MoreoverI think I will never have in the future any 
reason for importing the dive_log. slg file: I am not going to keep on 
using SmartTrack on my Windows XP virtual machine. Unfortunately I 
cannot ditch it right now, since I occasionally need to modify my dive 
computer settings and it is easier to do that by means of SmartTrak, 
instead of fiddling with the Galileo button driven menu.


Since am am a curious man, I have anyway tried to build the objects 
and the executables, after having created a suitable symbolic link  : 
ln -s /usr/lib64 /usr/lib/x86_64-linux-gnu .
After having done so, I was guessing the the required library should 
have been made available to build.sh .The available libmdb shared 
objects were thus:


ls -l /usr/lib/x86_64-linux-gnu/libmdb*
lrwxrwxrwx. 1 root root15 2016-02-04_09:38:43 
/usr/lib/x86_64-linux-gnu/libmdb.so.2 -> libmdb.so.2.0.1
-rwxr-xr-x. 1 root root 87280 2016-02-04_09:38:49 
/usr/lib/x86_64-linux-gnu/libmdb.so.2.0.1
lrwxrwxrwx. 1 root root18 2016-02-04_09:38:44 
/usr/lib/x86_64-linux-gnu/libmdbsql.so.2 -> libmdbsql.so.2.0.0
-rwxr-xr-x. 1 root root 40096 2016-02-04_09:38:49 
/usr/lib/x86_64-linux-gnu/libmdbsql.so.2.0.0


I created  a ~/src/ folder in my home folder, since you say that it is 
a bad idea to build subsurface as root.


I then went through the build operation, but the procedure failed once 
again, the script being unable to find a suitable libmdb shared object.

See the attached file build.log .

In any case, as far as I am concerned, everything is now OK with 
subsurface. The only problem is now that I am not able to get a 
working the irda interface in Fedora 23.
The module mcs7780.ko.xz is present on my system and is loaded with 
modprobe. Nevertheless the irda interface is not working on my system. 
I guess that one possible explanation for that is the absence of any 
irda configuration file in the system.


It is obvious that my troubles with the irda interface have nothing to 
do with your excellent software and that I am not therefore asking for 
your help about that.


In case I do not succeed in setting up the irda interface in my 
desktop PC with Fedora 24 I am going to try to do that in my Dell XPS 
13 Developer Edition with Ubuntu trusty.


Thank you once again for your help and your development activity.

Best regards.

Alessandro


Dear Allessandro,

The IrDA upload has been working flawlessly on by Ubuntu box since I 
started using Subsurface. I cannot see that this can be a fundamental 
stumbling block, even on Fedora. But I have never done this on Fedora 
myself. The basic procedure I followed is the one I documented in the 
Subsurface user manual: download (from Linux-IrDA project) and install 
the driver, then execute an irattach instruction AS ROOT (i.e. using 
sudo) before starting Subsurface. Only snag with the Galileo is it 
downloads the full memory of the dive computer every time, even if only 
the last dive is needed. Fortunately Subsurface knows which dives have 
been downloaded previously and only shows the new dives for download.


Salvador is working hard on the AppImage for smtk2ssrf that can execute 
on a wider range of Linux 

Re: Building on macOS error

[Benjamin]

On 4 February 2017 at 00:42, Dirk Hohndel  wrote:

>
> ...
> Webkit is no longer included by default. You can build it from source, or
> you can use -DUSE_WEBENGINE=ON on the cmake command line. That disables
> printing as that hasn't been ported to WebEngine, yet
>
> /D
>
> Is printing the only thing which is disabled?
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface deco calculations

[Rick Walsh]

On 4 February 2017 at 15:53, Miika Turkia  wrote:

> Hello,
>
> I cannot currently log into my gmail account due to 2-factor
> authentication challenges (cannot receive SMS at the moment), so using
> my private email, with hopefully correct addresses see-and-pasted from
> my phone :D
>
> Anyway, the attached log calculates quite different tissue saturations
> for different DCs, the worst being with OSTC Sport with shallowest
> depths by the sensor.
>

I hope you had a nice dive with the threshers.  If you can have a beer at
the Craic House (Evolution) and tell Dannie I say hi.

I can see why the OSTC Sport is giving greater tissue saturation and deco,
and it has nothing to do with how the deco calculations are performed.  The
problem is that the xml references a cylinder with index 1, but you only
have one cylinder defined (index 0), so it looks (without checking the
code) like Subsurface is assuming any undefined cylinder contains air.

The xml entry for the Suunto Vyper Air specifies a change to cylinder 0
(which is EAN32) at the start of the dive on lines 22 and 23:
  
  

The xml entry for the OSTC specifies a change to cylinder 1 on lines 158
and 159
  
  

The Suunto Stinger log does not specify a gas change at all, so the default
is the only defined cylinder, which contains EAN32.

Could I guess you had at least two gasses defined in the OSTC that were
downloaded, the second (index 1) of which was EAN32?  You could have then
merged the dives and deleted the unused gas/ses, but the OSTC profile was
still referencing cylinder 1.

Maybe the default assumed value for an unknown cylinder would be cylinder
0, and if no cylinders are defined, THEN default to air.


> I have set GF 30/75, if that matters.
>
> Any idea if this should somehow be expected or bug somewhere?
>
> miika
>

Cheers,

Rick
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: doing a 4.6.1 release

[Miika Turkia]

I noticed 2 things when testing:
- Automerge is not triggered when importing additional dc from a Subsurface xml 
file (I fixed date and time manually for one dc on a separate xml that I then 
imported to my main log)
- I have quite different deco calculations for different DCs on same dive. 
Subsurface calculates that I was still in deco when surfacing (ostc sport) 
while everything is ok for 2 different models of Suunto. Even while the ostc 
gives avg depth of 21.4 while Suuntos 21.7 and 22.1 meters. Of course this is 
visible on multiple other dives as well. I'll send a sample log to Dirk, Robert 
and Rick.

miika

> On 3 Feb 2017, at 8.30, Salvador Cuñat  wrote:
> 
> Good night.
> 
> 2017-02-02 7:12 GMT+01:00 Willem Ferguson :
> 
>> 
>> 
>> b) Let's see if its possible to build an AppImage of the Scubapro SmartTrak 
>> import tool? I think Salva offered to look at that.
> 
> I'am almost done with it.  I've put a link with a test appimage in 
> Alessandro's thread you can try.  It fails with a Xcb Qt plugins related 
> error on most systems I've tried, not all of them.  Ideas about this would be 
> appreciated, as gooogled solutions are failing for me once and again.
> BTW I've solved the localized time crash Dirk reported some days ago. Will 
> send the patches tomorrow.
> 
> Regards.
> 
> Salva.
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Dirk Hohndel]

Because clearly I like pain, I went through this whole thing again. And
tried to make it even more self contained, even more automatic. And
because clearly I was bored, I tested the whole thing on a freshly
installed Ubuntu 16.10.

Here are the complete steps it took me to get a working
subsurface-mobile-build-arm/bin/QtApp-debug.apk

$ sudo apt install git
$ git clone git://github.com/Subsurface-divelog/subsurface
$ bash subsurface/packaging/android/android-build-wrapper.sh

(if you are missing packages, it will tell you. Install them)

$ bash subsurface/packaging/android/android-build-wrapper.sh

Yes, the 700MB (or so) Qt download takes a while, even with a fast
internet connection.

When the Qt installer opens, the terminal will tell you which path to
enter as destination (default is ~/Qt5.7.1 but we want ~/src/Qt5.7.1 or
what ever you used as starting point -- really, it will tell you, use that
one). NO OTHER CHANGES, NONE, REALLY. I MEAN IT. DON'T.

At the end, don't start Qt Creator, just keep going.

More downloads. At one point you need to accept an EULA.

Everything else should run through without any user input. In one test the
whole thing suddenly stopped. I still don't know why. Gremlins. Just
delete whatever was the last directory it was working on and restart the
script.

In the end it will print out the full path to the APKs.

If any of this doesn't work. Send me the log file.

/D


PS: Anton - yes, I ran this through shellcheck
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Building on macOS error

[Dirk Hohndel]

> On Feb 3, 2017, at 2:34 PM, Federico Masias  wrote:
> 
> Hi all,
> 
> I'm having some issues trying to build on mac, while following the 
> instructions on the Building part of the website. The following error gets 
> spit out:
> 
> CMake Error at /Users/fede/Qt/5.6/clang_64/lib/cmake/Qt5/Qt5Config.cmake:26 
> (find_package):
> 
>   Could not find a package configuration file provided by "Qt5WebKitWidgets"
> 
>   with any of the following names:
> 
> 
> 
> Qt5WebKitWidgetsConfig.cmake
> 
> qt5webkitwidgets-config.cmake
> 
> 
> 
>   Add the installation prefix of "Qt5WebKitWidgets" to CMAKE_PREFIX_PATH or
> 
>   set "Qt5WebKitWidgets_DIR" to a directory containing one of the above
> 
>   files.  If "Qt5WebKitWidgets" provides a separate development package or
> 
>   SDK, be sure it has been installed.
> 
> Call Stack (most recent call first):
> 
>   CMakeLists.txt:202 (find_package)
> 
> 
> -- Configuring incomplete, errors occurred!
> 
> 
> I've tried with Qt5.7 and 5.6 (both installed from installer, not built from 
> source), but neither seem to include a webkit module -- is this something I'm 
> supposed to get from somewhere else? 

Webkit is no longer included by default. You can build it from source, or you 
can use -DUSE_WEBENGINE=ON on the cmake command line. That disables printing as 
that hasn't been ported to WebEngine, yet

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Building on macOS error

[Federico Masias]

Hi all,

I'm having some issues trying to build on mac, while following the
instructions on the Building part of the website. The following error gets
spit out:

CMake Error at /Users/fede/Qt/5.6/clang_64/lib/cmake/Qt5/Qt5Config.cmake:26
> (find_package):
>
>   Could not find a package configuration file provided by
> "Qt5WebKitWidgets"
>
>   with any of the following names:
>
>
> Qt5WebKitWidgetsConfig.cmake
>
> qt5webkitwidgets-config.cmake
>
>
>   Add the installation prefix of "Qt5WebKitWidgets" to CMAKE_PREFIX_PATH or
>
>   set "Qt5WebKitWidgets_DIR" to a directory containing one of the above
>
>   files.  If "Qt5WebKitWidgets" provides a separate development package or
>
>   SDK, be sure it has been installed.
>
> Call Stack (most recent call first):
>
>   CMakeLists.txt:202 (find_package)
>
> -- Configuring incomplete, errors occurred!
>

I've tried with Qt5.7 and 5.6 (both installed from installer, not built
from source), but neither seem to include a webkit module -- is this
something I'm supposed to get from somewhere else?

Thanks!
Fede
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Diveplan line breaks in UI and printing - vs. - Linux vs. Windows

[Federico Masias]

>
> Fixed it by deleting the printing templates in ~/.subsurface
> Now Linux and Windows result is the same.
>

Looks like an update to the FAQ is in order, then. Dirk, I sent changes via
github for English and Spanish.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH] Re: Crash when saving dive in planner after latest commits

[Robert Helling]

> On 03 Feb 2017, at 21:55, Stefan Fuchs  wrote:
> 
> Hallo Dirk, hi All,
> 
> very short note:
> 
> Latest git (SHA f563f736078ac3dfbb999b6c2e2352defd729f62) crashes when saving 
> a planned dive under linux. Even didn't try windows.
> 
> Did a "git reset --hard" to some older point on a copy of master and applied 
> my patches (surface pressure, SAC) again: works ok
> S.th . from the other commits from last 24h causes this? S.o. 
> else can confirm this?
> 
Argh. Here is a patch. Bummer.

Best
Robert

Will also send this via github.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Diveplan line breaks in UI and printing - vs. - Linux vs. Windows

[Stefan Fuchs]

Hi All,

Am 03.02.2017 um 21:51 schrieb Lubomir I. Ivanov:
> On 3 February 2017 at 22:22, Stefan Fuchs  wrote:
>> Now I found out there is one issue left concerning printing. I attached 4
>> screen shots:
>>
>> - Output in UI in planner looks good
>> - Output in UI in main window in notes section looks good
>> - Printing (template "Onedive") in linux is complete crap because the 
>> are not translated at all. --> Issue (1)
>>   I would expect this is even an old issue?!
>> - Printing (template "Onedive") in win is also not perfect because a few
>> line breaks are missing which are there in the UI.
>>   Line breaks missing are: Before "Runtime...", "Deco model...", "ATM
>> pressure..." and "Gas consumption...". --> Issue (2)
>>
>> What can we do about (1) which is even more serious?
>>
> dirk, already responded to this one.
Fixed it by deleting the printing templates in ~/.subsurface
Now Linux and Windows result is the same.
>> For (2) I guess I forgot to put a few . But why line breaks in UI then
>> work? Can s.o. please explain me the concept of  and  and how
>> this works differently (?!) in UI and planner?
>>
> a  tag may create a new line by itself.so,  if the rich text
> field in the planner has a , plus it has a  tag, you could
> end up with a couple of line breaks in the planner.
> but the printed notes only support  tags (if |safe is enabled that
> is) and also they don't really support rich formatting like colors and
> fonts.
>
> this means that the printed dive notes will look much more simplistic
> and for printing we don't really support the rich formatting that the
> default planner notes introduce.
Thanks, understood.
I will play with adding a few more  and try to make it look as
nicely as possible everywhere...

Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Crash when saving dive in planner after latest commits

[Stefan Fuchs]

Hallo Dirk, hi All,

very short note:

Latest git (SHA f563f736078ac3dfbb999b6c2e2352defd729f62) crashes when
saving a planned dive under linux. Even didn't try windows.

Did a "git reset --hard" to some older point on a copy of master and
applied my patches (surface pressure, SAC) again: works ok
S.th. from the other commits from last 24h causes this? S.o. else can
confirm this?


Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Diveplan line breaks in UI and printing - vs. - Linux vs. Windows

[Lubomir I. Ivanov]

On 3 February 2017 at 22:22, Stefan Fuchs  wrote:
> Hi All,
>
> you may know me as a complete newbie managed to do my first small change to
> the Subsurface planner: Adding surface pressure and SAC to the planner
> results.
>
> Now I found out there is one issue left concerning printing. I attached 4
> screen shots:
>
> - Output in UI in planner looks good
> - Output in UI in main window in notes section looks good
> - Printing (template "Onedive") in linux is complete crap because the 
> are not translated at all. --> Issue (1)
>   I would expect this is even an old issue?!
> - Printing (template "Onedive") in win is also not perfect because a few
> line breaks are missing which are there in the UI.
>   Line breaks missing are: Before "Runtime...", "Deco model...", "ATM
> pressure..." and "Gas consumption...". --> Issue (2)
>
> What can we do about (1) which is even more serious?
>

dirk, already responded to this one.

> For (2) I guess I forgot to put a few . But why line breaks in UI then
> work? Can s.o. please explain me the concept of  and  and how
> this works differently (?!) in UI and planner?
>

a  tag may create a new line by itself.so,  if the rich text
field in the planner has a , plus it has a  tag, you could
end up with a couple of line breaks in the planner.
but the printed notes only support  tags (if |safe is enabled that
is) and also they don't really support rich formatting like colors and
fonts.

this means that the printed dive notes will look much more simplistic
and for printing we don't really support the rich formatting that the
default planner notes introduce.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Dirk Hohndel]

> On Feb 3, 2017, at 12:41 PM, Willem Ferguson 
>  wrote:
> 
> On 03/02/2017 19:41, Dirk Hohndel wrote:
>> 
>> It should still create a working .apk - did you check that?
>> 
>> /D
> I assume the apk should be in ~src/subsurface-build-arm/ ??
> There is no bin directory in the above one and I see no apk file.
> ~/src/subsurface-build-arm$ ls -l
> total 45752
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 android-mobile
> drwxrwxr-x  3 willem willem 4096 Feb  3 09:47 assets
> -rw-rw-r--  1 willem willem35985 Feb  3 08:36 CMakeCache.txt
> drwxrwxr-x 13 willem willem 4096 Feb  3 11:36 CMakeFiles
> -rw-rw-r--  1 willem willem 1910 Feb  3 08:34 cmake_install.cmake
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 core
> drwxrwxr-x  5 willem willem 4096 Feb  3 11:36 desktop-widgets
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 libs
> -rwxrwxr-x  1 willem willem 43833008 Feb  3 11:36 libsubsurface.so
> -rw-rw-r--  1 willem willem22589 Feb  3 11:36 Makefile
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 profile-widget
> -rw-rw-r--  1 willem willem  2881855 Feb  3 09:56 qrc_subsurface.cpp
> -rw-rw-r--  1 willem willem  804 Feb  3 08:34 qtdeploy.json
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 qt-models
> -rw-rw-r--  1 willem willem  134 Feb  3 11:36 ssrf-version.h
> -rw-rw-r--  1 willem willem   93 Feb  3 09:47 subsurface_automoc.cpp
> -rw-rw-r--  1 willem willem 4384 Feb  3 08:34 subsurface.qrc.depends
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 translations
> -rw-rw-r--  1 willem willem  769 Jan 30 05:55 version.cmake
> -rw-rw-r--  1 willem willem  168 Feb  3 11:36 version.h.in
> 
> Am I looking in the wrong place? This is where the README says to look.

Would you please send me (off list) the full build.log file?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Diveplan line breaks in UI and printing - vs. - Linux vs. Windows

[Dirk Hohndel]

> On Feb 3, 2017, at 12:22 PM, Stefan Fuchs  wrote:
> 
> Hi All,
> 
> you may know me as a complete newbie managed to do my first small change to 
> the Subsurface planner: Adding surface pressure and SAC to the planner 
> results.
> 
> Now I found out there is one issue left concerning printing. I attached 4 
> screen shots:
> 
> - Output in UI in planner looks good
> - Output in UI in main window in notes section looks good
> - Printing (template "Onedive") in linux is complete crap because the  
> are not translated at all. --> Issue (1)
>   I would expect this is even an old issue?!
> 

Yes, this appears to be something that happens to a fair number of our users. 
There's even an FAQ about this (which may have to become non-Mac specific... so 
far only Mac users had reported this)
Can you see if this helps?

This is likely caused by an earlier install of Subsurface on the same computer. 
For some reason Subsurface may have decided to store a personal copy of the 
print template and is using that instead of the one shipped with Subsurface.
If you intentionally made specific changes to the templates, re-edit the 
templates and ensure that dive.notes is referenced as dive.notes|secure).
Or you could just delete the template copies... 
~/.subsurface/printing_templates is where they are most likely stored...

> - Printing (template "Onedive") in win is also not perfect because a few line 
> breaks are missing which are there in the UI.
>   Line breaks missing are: Before "Runtime...", "Deco model...", "ATM 
> pressure..." and "Gas consumption...". --> Issue (2)
> 
> What can we do about (1) which is even more serious?
> 

See above :-)

> For (2) I guess I forgot to put a few . But why line breaks in UI then 
> work? Can s.o. please explain me the concept of  and  and how 
> this works differently (?!) in UI and planner?
> 

I don't know why we are using  for some things but not for others. I 
didn't write that code :-)
It looks like Henrik may have introduced this?

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Willem Ferguson]

On 03/02/2017 19:41, Dirk Hohndel wrote:


It should still create a working .apk - did you check that?

/D

I assume the apk should be in ~src/subsurface-build-arm/ ??
There is no bin directory in the above one and I see no apk file.
~/src/subsurface-build-arm$ ls -l
total 45752
drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 android-mobile
drwxrwxr-x  3 willem willem 4096 Feb  3 09:47 assets
-rw-rw-r--  1 willem willem35985 Feb  3 08:36 CMakeCache.txt
drwxrwxr-x 13 willem willem 4096 Feb  3 11:36 CMakeFiles
-rw-rw-r--  1 willem willem 1910 Feb  3 08:34 cmake_install.cmake
drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 core
drwxrwxr-x  5 willem willem 4096 Feb  3 11:36 desktop-widgets
drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 libs
-rwxrwxr-x  1 willem willem 43833008 Feb  3 11:36 libsubsurface.so
-rw-rw-r--  1 willem willem22589 Feb  3 11:36 Makefile
drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 profile-widget
-rw-rw-r--  1 willem willem  2881855 Feb  3 09:56 qrc_subsurface.cpp
-rw-rw-r--  1 willem willem  804 Feb  3 08:34 qtdeploy.json
drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 qt-models
-rw-rw-r--  1 willem willem  134 Feb  3 11:36 ssrf-version.h
-rw-rw-r--  1 willem willem   93 Feb  3 09:47 subsurface_automoc.cpp
-rw-rw-r--  1 willem willem 4384 Feb  3 08:34 subsurface.qrc.depends
drwxrwxr-x  3 willem willem 4096 Feb  3 11:36 translations
-rw-rw-r--  1 willem willem  769 Jan 30 05:55 version.cmake
-rw-rw-r--  1 willem willem  168 Feb  3 11:36 version.h.in

Am I looking in the wrong place? This is where the README says to look.

Kind regards,
willem
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Dirk Hohndel]

> On Feb 3, 2017, at 9:24 AM, Willem Ferguson  
> wrote:
> 
> When running android-build.sh, I had to install parts of the android SDK. 
> When running the script a second time I get:
> 
> Copying gdbserver into package.
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/gdbserver
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libgdbserver.so
> Copying 2 external libraries to package.
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libssl.so
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libcrypto.so
> Copying Android sources from project.
>  -- Copied /home/willem/src/subsurface-mobile-build-arm/AndroidManifest.xml
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable/splash.xml
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable/subsurface_mobile_splash.9.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-hdpi/subsurface_mobile_icon.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-hdpi/subsurface_mobile_splash.9.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-mdpi/subsurface_mobile_icon.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-mdpi/subsurface_mobile_splash.9.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-nodpi/subsurface_mobile_splash.9.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-xhdpi/subsurface_mobile_icon.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-xhdpi/subsurface_mobile_splash.9.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-xxhdpi/subsurface_mobile_icon.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-xxhdpi/subsurface_mobile_splash.9.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-xxxhdpi/subsurface_mobile_icon.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/drawable-xxxhdpi/subsurface_mobile_splash.9.png
>  -- Copied 
> /home/willem/src/subsurface-mobile-build-arm/res/values/apptheme.xml
>  -- Copied /home/willem/src/subsurface-mobile-build-arm/res/values/strings.xml
> /home/willem/src/subsurface/../android-ndk-r13b/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-strip:
>  unable to copy file 
> '/home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libcrypto.so';
>  reason: Permission denied
> /home/willem/src/subsurface/../android-ndk-r13b/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-strip:
>  unable to copy file 
> '/home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libssl.so'; 
> reason: Permission denied
> 
> After changing the permissions I have:
> 
> ~/src/subsurface-mobile-build-arm/libs$ chmod -R 777 armeabi-v7a

ARGL. Don't do stuff like this. Seriously.

> ~/src/subsurface-mobile-build-arm/libs/armeabi-v7a$ ls -l
> total 32588
>  etc
> -rwxrwxrwx 1 willem willem 2005388 Feb  3 18:14 libQt5Quick.so
> -rwxrwxrwx 1 willem willem  189640 Feb  3 18:14 libQt5Svg.so
> -rwxrwxrwx 1 willem willem 3417492 Feb  3 18:14 libQt5Widgets.so
> -rwxrwxrwx 1 willem willem  388288 Feb  3 18:14 libssl.so
> -rwxrwxrwx 1 willem willem 9933316 Feb  3 18:14 libsubsurface-mobile.so
> 
> and:
> 
> ~/src/android-ndk-r13b/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin$
>  ls -l
> total 29252
>  etc
> -rwxrwxrwx 1 willem willem  441976 Oct 12 15:13 arm-linux-androideabi-readelf
> -rwxrwxrwx 1 willem willem  735256 Oct 12 15:13 arm-linux-androideabi-size
> -rwxrwxrwx 1 willem willem  734584 Oct 12 15:13 arm-linux-androideabi-strings
> -rwxrwxrwx 1 willem willem  920600 Oct 12 15:13 arm-linux-androideabi-strip
> 
> And still the copy gives the same error. I see no signs of disk space 
> problems.
> 
> I need advice from a person more experienced than myself.

It should still create a working .apk - did you check that?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Willem Ferguson]

When running android-build.sh, I had to install parts of the android 
SDK. When running the script a second time I get:


Copying gdbserver into package.
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/gdbserver
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libgdbserver.so

Copying 2 external libraries to package.
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libssl.so
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libcrypto.so

Copying Android sources from project.
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/AndroidManifest.xml
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable/splash.xml
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable/subsurface_mobile_splash.9.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-hdpi/subsurface_mobile_icon.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-hdpi/subsurface_mobile_splash.9.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-mdpi/subsurface_mobile_icon.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-mdpi/subsurface_mobile_splash.9.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-nodpi/subsurface_mobile_splash.9.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-xhdpi/subsurface_mobile_icon.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-xhdpi/subsurface_mobile_splash.9.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-xxhdpi/subsurface_mobile_icon.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-xxhdpi/subsurface_mobile_splash.9.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-xxxhdpi/subsurface_mobile_icon.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/drawable-xxxhdpi/subsurface_mobile_splash.9.png
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/values/apptheme.xml
  -- Copied 
/home/willem/src/subsurface-mobile-build-arm/res/values/strings.xml
/home/willem/src/subsurface/../android-ndk-r13b/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-strip: 
unable to copy file 
'/home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libcrypto.so'; 
reason: Permission denied
/home/willem/src/subsurface/../android-ndk-r13b/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-strip: 
unable to copy file 
'/home/willem/src/subsurface-mobile-build-arm//libs/armeabi-v7a/libssl.so'; 
reason: Permission denied


After changing the permissions I have:

~/src/subsurface-mobile-build-arm/libs$ chmod -R 777 armeabi-v7a

~/src/subsurface-mobile-build-arm/libs/armeabi-v7a$ ls -l
total 32588
 etc
-rwxrwxrwx 1 willem willem 2005388 Feb  3 18:14 libQt5Quick.so
-rwxrwxrwx 1 willem willem  189640 Feb  3 18:14 libQt5Svg.so
-rwxrwxrwx 1 willem willem 3417492 Feb  3 18:14 libQt5Widgets.so
-rwxrwxrwx 1 willem willem  388288 Feb  3 18:14 libssl.so
-rwxrwxrwx 1 willem willem 9933316 Feb  3 18:14 libsubsurface-mobile.so

and:

~/src/android-ndk-r13b/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin$ 
ls -l

total 29252
 etc
-rwxrwxrwx 1 willem willem  441976 Oct 12 15:13 
arm-linux-androideabi-readelf

-rwxrwxrwx 1 willem willem  735256 Oct 12 15:13 arm-linux-androideabi-size
-rwxrwxrwx 1 willem willem  734584 Oct 12 15:13 
arm-linux-androideabi-strings

-rwxrwxrwx 1 willem willem  920600 Oct 12 15:13 arm-linux-androideabi-strip

And still the copy gives the same error. I see no signs of disk space 
problems.


I need advice from a person more experienced than myself.

Kind regards,

willem


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Anton Lundin]

On 03 February, 2017 - Joakim Bygdell wrote:

> On 3 February 2017 at 10:49, Willem Ferguson <
> willemfergu...@zoology.up.ac.za> wrote:
> 
> > On 03/02/2017 08:25, Joakim Bygdell wrote:
> >
> > Remove the quotations on line 383 and try again, that fixed it for me.
> > --
> > Jocke
> >
> >
> >
> > I think your suggestions were extremely helpful. Thank you very much. The
> > problem below is due to a totally different reason. It almost completes the
> > build now, then I get:
> >
> > $ bash subsurface/packaging/android/build.sh
> > ~/src/subsurface ~/src
> > ~/src
> > ~/src/qt-android-cmake ~/src
> > Already up-to-date.
> > ~/src
> > -- building without marble widget support
> > -- building without printing support
> > -- building without usermanual
> > -- building with libftdi support
> > -- system name Android
> > -- Found Qt for Android: /home/willem/src/Qt/5.7/android_armv7
> > -- Found Android SDK: /home/willem/src/subsurface/../android-sdk-linux
> > <===
> > -- Found Android NDK: /home/willem/src/subsurface/../android-ndk-r13b
> > -- Found ANT: /usr/bin/ant
> > -- Configuring done
> >
> > . etc
> >
> > Scanning dependencies of target subsurface.apk
> > [ 89%] Generating run_android_deploy_qt
> > Directory /home/willem/src/android-sdk-linux/platforms does not exist
> > make[2]: *** [run_android_deploy_qt] Error 2
> > make[1]: *** [CMakeFiles/subsurface.apk.dir/all] Error 2
> > make: *** [all] Error 2
> > $
> >
> > There are two problems here.
> >
> > 1) The location of the android sdk. On my machine it resides at
> > ~/Android/Sdk/tools. It is not in ~/src. For this reason I am not sure
> > how to interpret the message marked with <===, above because it differs
> > both in the name of the directory as well as its location. In theory I
> > could generate a symlink just as I did for Qt and libdivecomputer.
> >
> Yes symlinking makes this easier for you.
> The script expects to find android-sdk-linux and android-ndk-r13b in the
> root of your working directory together with Qt, libdivecomputer and
> subsurface.

Or rather just set the env-vars ANDROID_SDK_ROOT and ANDROID_NDK_ROOT,
pointing to the ones you would like to use.

//Anton

-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Dirk Hohndel]

On Fri, Feb 03, 2017 at 12:51:21PM +0200, Willem Ferguson wrote:
> 
> 
> On 03/02/2017 12:27, Dirk Hohndel wrote:
> > So did you run the scripts/android-build.sh that I wrote pretty much
> > specifically for you to help you through all these things?
> > 
> > I should have realized yesterday that you didn't because THAT one
> > downloads and installs libdivecomputer and does the autoreconf.
> > And it installs the platforms and everything.
> > 
> > I ran this script on a freshly installed Ubuntu VM and it gets all the
> > paths right, gets all the components you need and results in a working apk
> > 
> > /D
> > 
> Dirk,
> 
> I was not paying attention. I did not find the script in
> packaging/android and assumed I should use the "normal" build.sh. Now
> that you mentioned it, I did a specific search and found it in the
> subsurface/scripts folder. I copied the script over to packaging/android
> and ran it. At the moment Internet-speed at the university is
> prohibitively slow to execute the script: cannot connect to servers,
> especially that in Brazil. Will try later today from home.

I thought you retired? Anyway...

Please don't move the script. Why would you? It's tested to run where it
is.

Go to ~/src
make sure that ~/src/subsurface has the latest version of subsurface
bash -x ./subsurface/scripts/android-build.sh

If you do that it should hopefully notice that you have Qt downloaded
already (assuming that's where you put things). The whole point of the
script was to create something to make sure this is all reproducable.

Of course, since you didn't use the script to install the Android SDK, I
would ask you to please REMOVE the Android SDK that you may have under
~/src/... so that the script downloads the right one and then installs the
platforms (that was how I realized that you hadn't used the script).

I'll try to go back to sleep (darn insomnia) - will check in on your
progress in about 4-5 hours (if I'm lucky).

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Willem Ferguson]

On 03/02/2017 12:27, Dirk Hohndel wrote:

So did you run the scripts/android-build.sh that I wrote pretty much
specifically for you to help you through all these things?

I should have realized yesterday that you didn't because THAT one
downloads and installs libdivecomputer and does the autoreconf.
And it installs the platforms and everything.

I ran this script on a freshly installed Ubuntu VM and it gets all the
paths right, gets all the components you need and results in a working apk

/D


Dirk,

I was not paying attention. I did not find the script in
packaging/android and assumed I should use the "normal" build.sh. Now
that you mentioned it, I did a specific search and found it in the
subsurface/scripts folder. I copied the script over to packaging/android
and ran it. At the moment Internet-speed at the university is
prohibitively slow to execute the script: cannot connect to servers,
especially that in Brazil. Will try later today from home.

Thanks so much for this. I appreciate this very much.

Kind regards,

willem



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Willem Ferguson]

On 03/02/2017 12:27, Dirk Hohndel wrote:
So did you run the scripts/android-build.sh that I wrote pretty much 
specifically for you to help you through all these things?


I should have realized yesterday that you didn't because THAT one 
downloads and installs libdivecomputer and does the autoreconf.

And it installs the platforms and everything.

I ran this script on a freshly installed Ubuntu VM and it gets all the 
paths right, gets all the components you need and results in a working apk


/D


Dirk,

I was not paying attention. I did not find the script in 
packaging/android and assumed I should use the "normal" build.sh. Now 
that you mentioned it, I did a specific search and found it in the 
subsurface/scripts folder. I copied the script over to packaging/android 
and ran it. At the moment Internet-speed at the university is 
prohibitively slow to execute the script: cannot connect to servers, 
especially that in Brazil. Will try later today from home.


Thanks so much for this. I appreciate this very much.

Kind regards,

willem



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Dirk Hohndel]

> On Feb 3, 2017, at 1:49 AM, Willem Ferguson  
> wrote:
> Scanning dependencies of target subsurface.apk
> [ 89%] Generating run_android_deploy_qt
> Directory /home/willem/src/android-sdk-linux/platforms does not exist
> make[2]: *** [run_android_deploy_qt] Error 2
> make[1]: *** [CMakeFiles/subsurface.apk.dir/all] Error 2
> make: *** [all] Error 2
> $ 
> There are two problems here.
> 
> 1) The location of the android sdk. On my machine it resides at 
> ~/Android/Sdk/tools. It is not in ~/src. For this reason I am not sure how to 
> interpret the message marked with <===, above because it differs both in the 
> name of the directory as well as its location. In theory I could generate a 
> symlink just as I did for Qt and libdivecomputer.
> 
> The current organisation on my machine is:
> ~/Android/Sdk$ ls -l
> total 28
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:33 build-tools
> drwxrwxr-x  4 willem willem 4096 Feb  3 11:33 extras
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:32 patcher
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:31 platforms
> drwxrwxr-x  5 willem willem 4096 Feb  3 11:33 platform-tools
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:32 sources
> drwxrwxr-x 12 willem willem 4096 Feb  3 11:34 tools
> And here, indeed is probably the missing platforms directory which, in turn, 
> contains the Android-25 directory
> I think the script just does not know where to find all the bits and pieces.
> 
> Obviously I have something simple not done right. Any suggestions?
> 
> I am much closer now to building the .apk
So did you run the scripts/android-build.sh that I wrote pretty much 
specifically for you to help you through all these things?

I should have realized yesterday that you didn't because THAT one downloads and 
installs libdivecomputer and does the autoreconf.
And it installs the platforms and everything.

I ran this script on a freshly installed Ubuntu VM and it gets all the paths 
right, gets all the components you need and results in a working apk

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Joakim Bygdell]

On 3 February 2017 at 10:49, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> On 03/02/2017 08:25, Joakim Bygdell wrote:
>
> Remove the quotations on line 383 and try again, that fixed it for me.
> --
> Jocke
>
>
>
> I think your suggestions were extremely helpful. Thank you very much. The
> problem below is due to a totally different reason. It almost completes the
> build now, then I get:
>
> $ bash subsurface/packaging/android/build.sh
> ~/src/subsurface ~/src
> ~/src
> ~/src/qt-android-cmake ~/src
> Already up-to-date.
> ~/src
> -- building without marble widget support
> -- building without printing support
> -- building without usermanual
> -- building with libftdi support
> -- system name Android
> -- Found Qt for Android: /home/willem/src/Qt/5.7/android_armv7
> -- Found Android SDK: /home/willem/src/subsurface/../android-sdk-linux
> <===
> -- Found Android NDK: /home/willem/src/subsurface/../android-ndk-r13b
> -- Found ANT: /usr/bin/ant
> -- Configuring done
>
> . etc
>
> Scanning dependencies of target subsurface.apk
> [ 89%] Generating run_android_deploy_qt
> Directory /home/willem/src/android-sdk-linux/platforms does not exist
> make[2]: *** [run_android_deploy_qt] Error 2
> make[1]: *** [CMakeFiles/subsurface.apk.dir/all] Error 2
> make: *** [all] Error 2
> $
>
> There are two problems here.
>
> 1) The location of the android sdk. On my machine it resides at
> ~/Android/Sdk/tools. It is not in ~/src. For this reason I am not sure
> how to interpret the message marked with <===, above because it differs
> both in the name of the directory as well as its location. In theory I
> could generate a symlink just as I did for Qt and libdivecomputer.
>
Yes symlinking makes this easier for you.
The script expects to find android-sdk-linux and android-ndk-r13b in the
root of your working directory together with Qt, libdivecomputer and
subsurface.

> The current organisation on my machine is:
>
> ~/Android/Sdk$ ls -l
> total 28
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:33 build-tools
> drwxrwxr-x  4 willem willem 4096 Feb  3 11:33 extras
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:32 patcher
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:31 platforms
> drwxrwxr-x  5 willem willem 4096 Feb  3 11:33 platform-tools
> drwxrwxr-x  3 willem willem 4096 Feb  3 11:32 sources
> drwxrwxr-x 12 willem willem 4096 Feb  3 11:34 tools
>
> And here, indeed is probably the missing platforms directory which, in
> turn, contains the Android-25 directory
>
> I think the script just does not know where to find all the bits and
> pieces.
>
> Obviously I have something simple not done right. Any suggestions?
>
make sure tour working src directory contains these folders:
android-sdk-linux
android-ndk-r13b
subsurface
libdivecomputer
Qt

symlinks to other places are ok, the important thing are that they have the
same name as listed above.

I am much closer now to building the .apk
>
> Kind regards,
>
> willem
>
>
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>


-- 
Jocke
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Problems building Subsurface for Android

[Willem Ferguson]

   On 03/02/2017 08:25, Joakim Bygdell wrote:

   Remove the quotations on line 383 and try again, that fixed it for me.
   -- 


   Jocke



I think your suggestions were extremely helpful. Thank you very much. 
The problem below is due to a totally different reason. It almost 
completes the build now, then I get:


$ bash subsurface/packaging/android/build.sh
~/src/subsurface ~/src
~/src
~/src/qt-android-cmake ~/src
Already up-to-date.
~/src
-- building without marble widget support
-- building without printing support
-- building without usermanual
-- building with libftdi support
-- system name Android
-- Found Qt for Android: /home/willem/src/Qt/5.7/android_armv7
-- Found Android SDK: 
/home/willem/src/subsurface/../android-sdk-linux   <===

-- Found Android NDK: /home/willem/src/subsurface/../android-ndk-r13b
-- Found ANT: /usr/bin/ant
-- Configuring done

. etc

Scanning dependencies of target subsurface.apk
[ 89%] Generating run_android_deploy_qt
Directory /home/willem/src/android-sdk-linux/platforms does not exist
make[2]: *** [run_android_deploy_qt] Error 2
make[1]: *** [CMakeFiles/subsurface.apk.dir/all] Error 2
make: *** [all] Error 2
$

There are two problems here.

1) The location of the android sdk. On my machine it resides at 
~/Android/Sdk/tools. It is not in ~/src. For this reason I am not sure 
how to interpret the message marked with <===, above because it differs 
both in the name of the directory as well as its location. In theory I 
could generate a symlink just as I did for Qt and libdivecomputer.


The current organisation on my machine is:

~/Android/Sdk$ ls -l
total 28
drwxrwxr-x  3 willem willem 4096 Feb  3 11:33 build-tools
drwxrwxr-x  4 willem willem 4096 Feb  3 11:33 extras
drwxrwxr-x  3 willem willem 4096 Feb  3 11:32 patcher
drwxrwxr-x  3 willem willem 4096 Feb  3 11:31 platforms
drwxrwxr-x  5 willem willem 4096 Feb  3 11:33 platform-tools
drwxrwxr-x  3 willem willem 4096 Feb  3 11:32 sources
drwxrwxr-x 12 willem willem 4096 Feb  3 11:34 tools

And here, indeed is probably the missing platforms directory which, in 
turn, contains the Android-25 directory


I think the script just does not know where to find all the bits and pieces.

Obviously I have something simple not done right. Any suggestions?

I am much closer now to building the .apk

Kind regards,

willem



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface