It's frustrating that I can't get the translation.qrc support the translation
files to be created in the build directory. Having them as part of the sources
just feels wrong.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It is completely incomprehensible why these fail. And why randomly restarting
sometimes fixes them, and often doesn't. At this point there is no incremental
value in having this test. If it were to ever catch a real bug, we wouldn't
realize it because we are too well trained to ignore the problem.
Very disappointing, but IMHO the right thing to do.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It appears that Xcode 12 applies some rather self defeating logic when picking
build architectures in release builds for the simulator. It adds aarch64 by
default and I can't find a way to turn that off from the command line. At the
same time, you can't link against the simulator if you have build with aarch64
as the aarch64 simulator doesn't exist, yet.
Since I couldn't get any of the claimed workarounds to work, I'm forcing Xcode
11 to be used in the Action.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We previously tried to build the MXE Docker container on GitHub using
an Action, but that really didn't work well and was a lot more trouble
than it was worth.
So this goes back to an offline build mechanism where I simply create
an updated Docker image when needed and push that to Docker Hub.
But this nearly hides the most interesting change here - we are finally
switching to using 64bit binaries on Windows. It's 2020 and fewer than
1% of our users use 32bit Windows machines. We'll need to expand this
to be able to have both a 32bit and a 64bit version of Subsurface for
Windows. But for now, this solves the problem for 99% of our users.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This uses latest master (as that's the only one that has the explicit
Descent Mk2i support in it).
Right now, unfortunately the MXE build fails.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Without a distro update, Leap 15.2 appears to only give us Qt 5.12.
Since the upgrade takes forever and causes problems as it requests a senseless
'reboot' of the container, let's try using Tumbleweed instead.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way we should see the output and hopefully be able to figure
out why that silly test keeps randomly failing.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I had missed this one in commit d73e0a0fb4
("build-system/packaging: add bluez dependency for Linux builds").
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- use hidapi grantlee and mdbtools from MXE
- update MXE version to use QT 5.15, and pull in libzstd and CMake 3.17.3
- fix linking of winmm on windows build with new mxe
- add some instructions on building the container
- add some new dependancies from QT 5.15 to the packaging
- add a patch to MXE to Build qtconnectivity with native-win32-bluetooth
[Dirk Hohndel: small refactor]
Signed-off-by: Paul Buxton <paulbuxton.mail@googlemail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Net net this has caused more problems than it solved. Too often binaries
were missing or broken. Instead 'release equivalent' binaries are now
consistently posted to downloads/test via a Webhook.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There's no point in doing that since the app directory this creates is broken
on older macOS versions, anyway (and we create a working DMG through a
webhook).
Additionally, lately this has started to fail on GitHub, so let's just rip this
out.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is no longer created using GitHub actions (but all the necessary
information is still included in this repo). We need to be able to
shrink this container so our GitHub Action runs don't run out of disk
space.
Adjust the path where the resulting binaries are found with this build.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Our builds fail because we are missing pkg-config.
I'm not quite sure if this is triggered by a new dependency or if pkg-config
used to be there and now isn't. Either way, this should hopefully fix things.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since the official Qt binaries can no longer be installed without disclosing
credentials (well, sure, that could be done through secrets), I decided that
we should go back to packaging just the part of the iOS Qt SDK that we need.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Something is seriously wrong with the default Ubuntu 18.04 environment
on GitHub Actions. C++ builds fail with very confusing messages about
C++11 support.
Switching to building in a Ubuntu 18.04 based container - that seems
redundant, but it fixes the problem.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We never noticed this before, but during the build of the Trusty Qt5.12
container itself we create libdivecomputer include files and we ship them with
the container. And as the recent build failures after an incompatible API
change in libdivecomputer show, those include files are apparently used in this
build, not the ones that are newly created during the build.
Obviously the build container needs to be fixed, but as a quick workaround,
this should do.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As much as I hate having passwords exposed through the source code,
since GitHub wisely prevents reading secrets in pull requests, there
isn't really a sane way to have this use confidential credentials.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a bit more convoluted to do inside of the Ubuntu 19.10 container, but
at least for Ubuntu 14.04 and for Mac this will be an improvement.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This appears to prevent Bluetooth from working.
Fixes: #2370
Suggested-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Also deal more gracefully with other potential bugs so that
we don't add an spurious '-' at the end if the branch is empty
for some reason (as that makes the image name invalid).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Really, this is just here to re-trigger that container build now
that things are merged and stage 2 will actually work...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
These are of course arbitrary. The Android container image for some
reason based its version number on the Qt version. Which may or may
not be a good idea. The other two had 0.x version numbers, so let's
move them to 1.0 for the first release that gets pushed to the
subsurface account on docker hub.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When triggered by a push event, the checkout action checks out the correct branch.
But without this change, the stage 2 action would always run on master.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Based on ideas from Anton - both the basic building of containers in the first
place as well as the workaround for the 6h build limit.
Because GitHub Actions are limited to 6 hours we split the creation of the MXE
container into two steps and push the intermediary container after stage 1 to
docker hub. Right now each of the steps takes about 3.5 hours, so hopefully
even with changes in the future this will continue to work.
This commit also introduces use of docker hub instead of GitHub's own registry
(since strangely right now GitHub actions cannot run containers from GitHub's
private registry).
In order for this to work, we need to have the docker credentials in secrets in
GitHub. As a result, only people who can create branches in our repository can
easily test changes to the container images. Others can modify the code to use
a different docker hub account and provide those secrets in their own GitHub
account. Not ideal, but of course we cannot allow every pull request to
potentially overwrite docker images in our "official" docker hub account.
Suggested-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
