This workflow will download the current snaps published in the `candidate`
channel for all architectures and check them for packages with published
Ubuntu Security Notices. If it finds one, it will trigger a build of the
snap recipe:
https://code.launchpad.net/~subsurface/+snap/subsurface-stable
This will rebuild the snap with patched packages and publish it to the
`candidate` channel.
Signed-off-by: Michał Sawicz <michal@sawicz.net>
Trying to keep the different build environments consistent I messed up and
dropped wget and curl from the Coverity build. Moving them to the beginning of
the list so they stand out more.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Update to Qt 5.12.10, latest OpenSSL, add QtChart, add other missing packages.
Also switch to gcc-7 as our statistics code requires better C++17 support than
what gcc-6 can offer.
This then creates trusty-qt512:1.1
Signed-off-by: Subsurface CI <dirk@hohndel.org>
This is kind of a random choice - I don't see much value to build this
everywhere, but it's kinda neat to use this to test that the -all option works
correctly and does the right thing with WebKit now. And it will also ensure
that the downloader build isn't broken.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The way I test things locally I build in the directory above the subsurface
directory. Let's match this on GitHub as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
19.10 is no longer receiving updates and causing problems when running
the tests. 20.04 also uses Qt 5.12.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This of course needs to be fixed in the build container itself, but
for now this might be enough to make progress.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In order to apply the patches for Kirigami, git insists on having
a valid user name and email.
Also, don't build the mobile app when preparing the AppImage. That
build already takes way too long and we test this in a few other
actions.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
