While in theory the DEVINFO event should give us the correct detected
product, it's also possible that the code that usually detects the
product gave up and returns an unknown model.
Try to have the message reflect that situation more accurately.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should fix the current Travis build failures for Android.
It is odd how we have ANDROID_PLATFORM and ANDROID_PLATFORMS,
buf for now all I care about is that the Travis build completes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When no real name is set in /etc/passwd the username ends
up being ",,,". Git does not like that. Actually, only the
part before the first comma is the name, the rest is office
and phone number. We don't want those.
Before we only testing for the username being a NULL pointer.
Reported-by: Keith Grimes
Signed-off-by: Robert C. Helling <helling@atdotde.de>
After the downloading finished, the mainwindow-display is reset
via a signal. This is probably an artifact of old times, when
downloading was done into the main dive-list. Nowadays, this seems
to make little sense, as the main dive-list is not changed by download.
Remove the signal.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
... and remove install of the default (old) libgit2 from OS. That old
(0.24.0) libgit2 will be replaced by a newer anyway, so useless to
install.
But the real change to get this Travis build running again is using
the well known openssl instead of libressl.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The install was missing curl.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl> Removed upgrade to newer libgit2.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We currently require a minimal version of libgit2 of 0.24.0. From
issue #1926 it seems that this version is too old. So, a simple test on
Linux to see the behaviour with such an old libgit2, I tried that.
Interestingly, with the current version of openssl that old libgit2
version does not even compile from source (known error in libgit2).
So, bump our minimal version of libgit2 to 0.26.0. That is also the
version we currently use on the Travis and official builds, so well
tested.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The starTimestamp is 4 hours apart on 2 different DCs within the sample
log. DiveDate on the dive_logs table seems to be correct, but must be
converted from human readable format.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Seems that Shearwater cloud stores sample rate into the database and
it is not constant within the log.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
This works to some extent to part of a sample log I received. However,
still quite a bit more work is needed.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
I encountered this while implementing Shearwater Cloud import, but it
makes sense to increase the size for dive id for Shearwater Desktop as
well.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
With this we have working arm and arm64 images (except that the arm64
image crashes when using Bluetooth).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
cmake 3.10 (which comes with Ubuntu 18.04) in combination with Qt 5.12
and the current qt-android-cmake causes an odd bug. Paths are set with a
double slash at the start '//' and later in the process this causes
garbled path names for some of the objects which in return causes the
APKs built in the container to fail.
Upgrading the cmake inside the container to 3.13.2 fixes that problem.
All the credit for identifying the problem and figuring out a solution
goes to Jan Mulder.
The resulting container was pushed to Docker hub as version to 5.12.03.
Reported-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Again, this is relevant for developers that do local docker android
builds, and normal android builds. A normal build uses the directory
subsurface-mobile-build-arm(64), and when doing a docker android build
this directory is shared between host and container. That sharing is
good, as it nicely exposes the build tree to the host (for easy compare,
inspection, etc.). But reusing the same tree as the local one is
inconvenient (and possibly dangerous due to all kinds of caching
issues).
So, give the docker build its own output tree for the shared
subsurface-mobile-build-arm(64) build output.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Users that use docker locally for Windows style build and Android style
builds will (probably) not like that we use the same name for both
docker containers. So, give the android builder its own name.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This fix makes no difference from usage of this script in Travis
context, as every build starts from a clean VM, but the very few
developers that build for Android locally, and that want to use the new
style docker container builds as well, things are broken.
libdivecomputer has build artifacts in its source tree (and that source
tree is shared between local and docker run). So it happens that
libdivecomputer is configured locally, and afterwards fails to build
in docker build as its already configured, but not for the docker
image its now running in.
The fix is simple. Always reconfigure libdivecomputer when using this
script.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
So we don't need the pre-built binaries anymore, and we don't need the
travis_wait hack anymore for potentially slow downloads as that is all
installed in the container already.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As explained in commit 449d4ee33d ("Android build: add explanation for
huge hack").
It seems reasonable to add this to our Travis image as that is custom
made just to build our Android binaries.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This had to be embedded in the build process (or better, solved for
real).
Using Cmake, Clang, NDK 18b, Qt 5.12 beta 4, some Subsurface code does
not compile. At this point in time, its fully unclear to me why we see the
error as it is.
Thing fail deep down in Qt and NDK headers on #include <cmath>. Error like
"::signbit is not in the global namespace". The most logic reason is an
improper order in which include paths are constructed in the build process.
Any attempt to find the real reason failed. Even very similar command lines
from a qmake build that succeed fail with a cmake style build.
The very very dirty hack is commenting out some lines in NDK 18b:
"./android-ndk-r18b/sources/cxx-stl/llvm-libc++/include/cmath
Comment lines 313-325, and all build, links and runs with no errors
related to this known at this point.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
make sure that all lib code is compiled with -fPIC as things will not
link due to error "requires unsupported dynamic reloc R_ARM_REL32" (for
arm build).
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
On very clean builds not using the wrapper script, the compile of libzip
simply fails because it depend on openssl include files. Simply swap them
around.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Mysteriously, openssl does not compile with clang with a
sha256-armv4.S:2638:2: error: invalid instruction, did you mean: adr?
The easiest way out is compiling without no_asm. This obviously lowers
the bandwidth on the SSL link (as the asm code is there for performance
reasons), but it has no visible performance loss in my tests.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
With a preparation done in the 4 commits before, now add the arm64 and
use clang instead of gcc as compiler infrastructure.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Very annoyingly, openssl is re-build and downloaded numerous times
when doing partial builds. Reason for this, is that the original checked
out git repo is moved away, and build in source (as openssl does ...).
So, this simple change leaves the checked out repo in place, and
copies the tree to build in.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
A subtle one. When compiling for arm64, libzip is the only package we
use in mobile that installs its product in lib64. There is no reason for
this given the way our build process is. So, simply force the library to
reside in lib, independent if we are building arm or arm64
architectures.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Simple cleanup. Do not hard code armv7 as we have QT_ARCH. This
allows, in the future, for arm64 builds as well.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Hard coding desired ANDROID_PLATFORM on multiple places is simply bad.
Fix this. Further, set the variables to a much newer state.
CAVEAT: this will likely break android build, so be careful on
bisecting. All fixed in next, related commits.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Commit 68961a169e made it impossible
to edit a dive site on mobile if a dive-site was already set: If
divesite was non-null, no actions were taken. Remove the conditional.
Reported-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
wcslen() returns the number of characters in a wchar_t string.
In the case of WideCharToMultiByte() an estimate for the size of
the utf8 buffer is needed. Using wcslen() is incorrect for such a buffer,
because for any non-ASCII character the estimate will be off by 1 byte.
Call the following instead to obtain the proper UTF8 buffer size
for the conversation:
WideCharToMultiByte(CP_UTF8, 0, utf16, -1, NULL, 0, NULL, NULL);
Also fix some missing "\n" in fprintf() calls.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
After upgrading to Qt 5.12.0, download over BT from a DC did not work
any more. On the console the message "Connecting to port is not
supported (Uuid required)". Linus noticed earlier that we do rather
strange processing in this part of the code related to selecting port 1
or port 5. This all seems not needed (any more), but broader testing is
advised. This being stripped from the code, the mentioned error from Qt
persisted. That is strange in itself, as we did not reference port
numbers any more.
Step 2 in this commit is actually using an uuid to the call to
connectToService. Choosing an uuid seems relatively straightforward as
we can use the same one we already use for Android. That is the default
BT RFCOMM Serial Port Profile uuid. Interestingly, when changing to this
uuid we run immediately in a Qt runtime error telling us "QDBusPendingReply:
type ManagedObjectList is not registered with QtDBus.". For these 2
unexpected Qt messages, QTBUG-72742 was made. Studying the Qt source
code at this point reveals a possible workaround. Simply create a local
QBluetoothLocalDevice object, which, behind the scenes registers the Qt
internal ManagedObjectList with QtDBus.
In the meantime, Qt agrees that QTBUG-72742 is valid, and that a fix is
to be expected in a future version. At that point in time, the
declaration of the QBluetoothLocalDevice can be deleted again.
In the end, interfacing over BT works again.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This is an attempt to fix issue #1896. While this seems a Qt issue in
combination with very specific Android devices, this might be a fix. Do
not check for a very specific state of the local BT controller, but just
check if it is powered on.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
