When building dbus within the appimage, cmake picks up the installation
path of various files dbus uses through the GNUInstallDirs package,
however this doesn't work under the appimage build.
So we replace the variable with the normal location of this file.
Signed-off-by: Paul Buxton <paubuxton.mail@googlemail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For this we need our own hand crafted trusty container with Qt 5.12,
including QtWebKit and an updated cmake and libdbus, as well as already
build googlemaps plugin, grantlee and libgit2.
At the same time stop uploading the Subsurface AppImage in the
traditional trusty build.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With all upgrading, the build apks now show up in a slightly different
location. Correct this in the scripting. Notice that this is debug
building only. Release building is outside the repo.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Trivial. The final touch command was missing the proper quotes, so it
created a bunch of strangely names files from the date command. Just
good for the developers that like to peek into the docker image.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The main reason for upgrading of the Qt version is the hunt for a broken
BT/BLE stack, preventing downloads from BT/BLE enabled DCs, in relation
to arm64 architecture builds. (And the absolute need for an arm64 build
in relation to the publication of the Android app in Googles Play
store).
In addition, Qt 5.12.4 starts supporting OpenSSL 1.1.1c, and trying to
use our current OpenSSL 1.0 series is highly discouraged by Qt (and
OpenSSL itself).
So, upgrade both in unison. But ... be careful bisecting issues on this
commit, as it does break our build. That will be fixed in the next
commit.
This fixes the BT/BLE download for arm64!
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The .app.zip should once again run on any Mac (ignoring the security issue of
unsigned binaries). The Qt binaries in that archive include the jpeg and png
libraries that were missing in the Qt 5.11.1 binaries we used until now.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
0.9 docker image includes static libraries to build mdbtools so there is
no need for an aditional tarball.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add -a parameter to tee to avoid overwriting build.log when building
static libraries for smtk2ssrf
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Passing an argument on the docker build command line avoids the need to
modify the Dockerfile for each image build.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
mdbtools only builds static under mxe.
This should add static build of glib to the container with the mxe
libraries.
[Dirk Hohndel: merged with latest version of Dockerfile]
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of trying to do it all in one step rely on --squash to do its
job. Don't try to be so aggressive in removing things, it saves very
little space and caused builds to fail.
This results in version 0.9 of the MXE build container
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Printing never worked, none of this was ever included in test builds. Also, now
that there are official releases of QtWebKit again, this just doesn't seem worth
carrying along anymore.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Just like Android, Windows binaries are best created in a container.
I still need to push the latest version to docker hub and use it on
Travis, but this way at least the Dockerfile is here.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
... 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 scripts/build.sh script has an option --skip-googlemaps. Introduced
in 2017 at a moment the Travis Mac build failed on this. Interestingly,
when Mac building of the maps plugin was possible again (commit 79e3f69f48)
the --skip-googlemaps stayed. Obviously, this hack was never intended
to be used for anything else then getting it passed Travis on
some point in time for a specific Mac build.
So, remove this option.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
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>
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 should make our mac builds on Travis faster.
This also switches to the latest xcode / VM image which helps speed things up
(less to update for Homebrew). It turned out that that app directories that we
were creating here didn't run for people, anyway, so why even bother with an
old image.
We still create / upload that image (simply in order to be able to peek into it
in case something goes wrong).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Initial implementation/prototype of copy-paste support for
Subsurface-mobile. The UI part is really lacking; right now the copy
button is initially visible and paste is achieved by long press on a
dive and clicking the paste button when it appears. Delete is currently
not possible at all, as I just failed to layout the buttons properly
using QML. It just sounds so simple, to put all the copy-paste-delete
buttons next to each other...
The data to be copied is currently hard-coded. A dialog to choose
inteded fields would be nice, but it'll take quite a bit effort to get
used to QML enough to be able to hack something together.
Anyway, this seems to work, even though the UI is not always reflecting
the paste without switching dives (when testing on laptop).
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
And use that to have our Travis build still work with the existing MXE
build container as well as the even older, pre-compiled MXE binaries
used in the windows build.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Ooops. Forgot to fix this before sent the patches, as this part doesn't
works on my travis builds.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
