arm64 builds on Travis are not yet fully mature and this
causes a high failure rate that is not caused by our code.
Continue building and deploying arm64 to the edge channel,
but don't consider the result for the success of the whole
build job.
Alleviates #587
Snapcraft's remote-build does not fit the requirements of CI,
so replace it with builds running directly on Travis:
1. Builds on Travis can run independently, whereas remote-build
competes for the same resource (Launchpad) and will potentially
block if multiple commits require building in succession.
2. Snapcrafts CLI for remote-build is not designed to be easily
scriptable.
3. Travis recently introduced building on arm64, so builds for
arm64 are now very fast and don't require emulation.
We do not build for armhf and i386 any more because they are
of little relevance on the desktop.
dpl-snap only supports pushing one snap at a time.
Instead of many repetitive deploy statements,
we use our own script to loop over the snaps to be released.
We invoke builds on Launchpad in stage "deploy" and release it into
the edge channel of the Snap Store.
The deploy stage is blocked on fails of the test stage, so we don't
release snaps with failing tests.
- Fix invalid osx_image xcode8.2
- Drop depreceated sudo keyword
- Run debian build on bionic image & re-enable building with ui
- Split build into separate jobs & stages for better separation of concerns
These are now handled through GitHub status changes, and so the one
notifico instance works just as well, and needs less configuration
in the repository.
We are going to use freetype instead of the old custom TTF parser,
since the old parser has many annoying bugs when handling non-Latin
fonts and fixing it is not really worth the time.
On Windows, Freetype is built from a submodule.
On Linux and OS X, Freetype is provided together with the desktop,
though development files have to be installed separately.
After this change, SolveSpace does not contain nonfree assets.
Additionally, Perl is not required for the build.
Note that in the US, case law suggests that copyright does
not apply to bitmap fonts:
http://www.renpy.org/wiki/renpy/misc/Bitmap_Fonts_and_Copyright
Nevertheless, it was prudent to replace the asset with something
that is unambiguously free.
Maximilian Federle
whitequark