This reverts commit fd2997c2db.
Core tests are no longer online, so no longer are flaky nor tie up many
minutes of test runner time. So re-enable for all jobs.
They're still slightly flaky even with insanely long timeouts, and even when not they waste a huge amount of our runner time sitting and waiting for the DHT to disconnect and reconnect.
Still run on our fedora job to get almost all of the benefit, plus AddressSanitizer is enabled there for better testing synergy.
Installations to Program Files (default) inherit restrictive permissions,
disallowing regular users from writing to files in the install location. If a
user installs to other directories with more lax permissions though, i.e. C:\,
the install directory can be writable by non-admins, causing a privilege
escalation opportunity. An unprivileged user could modify or replace the qTox
binary or a dll, that would then be run by any other user on the system.
Clone Program Files permissions rather than trying to craft sane permissions
manually for simplicity and compatibility.
Windows uses UTF16, so may have caused issues if users installed to paths with
non-ANSI characters. It is also needed for interacting with any OS files.
LangString UninstLogMissing statement was accessing LANG_ENGLISH before it was
defined by the MUI_LANGUAGE macro. It caused a warning, but still defaulted to
English.
Breaks an inter-dependency between "MODERN UI" section needing CreateShortcut
and "PREPARE UNINST LOG" section needing LANG_ENGLISH, allowing "MODERN UI"
section to be done first.
Old windows/cross-compile/build.sh copied OPENAL_PREFIX_DIR/bin/*.dll to be
included, but the current Dockerfile.windows_builder copies libs one by one
and misses OpenAL. qTox fails to start on launch with due to missing
OpenAL32.dll on Windows because of this.
Add a special check for OpenAL, since the generic missing dll check doesn't
cover it.
Motiviation:
* Reproducing issues in CI is currently difficult
* Predicting issues in CI is currently difficult if you are not on
ubuntu 18.04
* Reproducing issues submitted from other distros is currently done by
creating a VM of that distro and building qtox for it locally
* Documentation for how to build on different distros is out of date
* Issues on non-ubuntu distributions are not caught by CI
* Cross compiling for windows locally is not trivial
* Iterating when working with custom build scripts is slow, scripts
don't necessarily support re-running without re-starting the docker
container and re-building qtox again
* Updating dependencies is a pain
Changes:
* docker-compose file has been added to the root of our repo.
After `docker compose run --rm ubuntu` (or other supported distros),
you are ready to compile and run qtox
* Dependencies are owned by dependency install scripts in buildscripts/.
This allows us to use the same exact dependencies in our
OSX/windows/linux scripts
* New docker images have been added for a variety of distributions.
These are now run in CI in a variety of configurations
* Docker images are cached in CI so rebuild time for the majority of
jobs is quite quick
* Build scripts have been trimmed to leverage state of docker
containers.
* Windows build script no longer installs anything, dependencies are
now managed by the windows_builder docker images
* Build scripts should now be easily re-runnable. Usage is now `docker
compose run --rm <image>` and then run the scripts
* All artifacts are now uploaded to github after build, this means we
can take an appimage/flatpak/exe/dmg for any given PR and try it out
without having to build it ourselves
Notes:
* Docker image size is quite important. We have a maximum of 5GB cache
space on github actions. The majority of the linux distro docker
images cache at ~300-400MB, which gives us room to test ~6 distros
after accounting for the sizes of flatpak/windows docker images
* Docker layer ordering is relatively intentional. Approximate order
should be that large dependencies that change infrequently should be
farther up. This lowers the amount of rebuilding we have to do when
dependencies are updated
* download_xxx.sh scripts are the cleanest way I could find to implement
a shared dependency map between osx scripts and docker containers.
Although it would be nice to have a single dependency mapping file,
splitting it into individual scripts allows us to only rebuild some
docker layers when dependencies are updated.
* Github actions are split between docker image building and docker
image use. This allows us to re-use the same docker images for
multiple jobs, but only build it once
* Unfortunately I could not find a way to de-duplicate the stitching
between jobs, so we have a lot of copy pasta in that area
Use posix versions of mingw toolchains, which say:
> This package contains the C++ compiler, supporting cross-compiling to
64-bit MinGW-w64 targets, using the POSIX threading model.
Fix build failure saying that std::mutex was not declared
We are staying on 5.12 instead of 5.15 because 5.12 is supported for
longer. There should be one more release in H2 2021.
Ideally we would switch to 6.2, but qTox doesn't seem to be Qt6-ready
yet.
bsdtar has moved to libarchive-tools package.
Something has changed in the newer gcc or mingw that makes Opus and
Sodium fail to build with:
undefined reference to `__memcpy_chk'
The solution is to use -lssp or -fstack-protector, but while -lssp
worked for Opus, it was breaking Sodium's `make install` as it prevented
the .def file from being generated during the build time for some
reason:
/usr/bin/install: cannot stat './libsodium-24.def': No such file or directory
while -fstack-protector worked just fine, so -fstack-protector was used
for both. This adds a new library dependency on libssp-0.dll.
