Apparently, this breaks the Flatpak CI yaml assumptions and makes the
"build-bundle" step there break with the following error:
> error: Refspec 'app/org.gnome.Geary.Devel/x86_64/test' not found
Some of our `ComposerWidgetTest` tests are failing with SIGSEGV.
This seemingly happens because they create a new
`Geary.AccountProblemReport`; for example, because a `MockAccount`
doesn't actually implement `get_required_special_folder_async()`.
That in turns will indirectly create a `Geary.ErrorContext` which will
try to use libunwind to create a stack trace. And there, it seems that
`unw_get_proc_name()` is the function that is actually segfaulting.
Looking at libunwind recent history, a similar crash was reported [1]
which has been fixed in libunwind commit b32ce6ee36. Since that hasn't
been backported into a release, let's bundle the latest mainline from
libunwind instead to get the fixes in.
[1]: https://github.com/libunwind/libunwind/issues/827
Our test wasn't using the appropriate callback `.end()` function, which
was failing the test with the latest Vala nightly releases, breaking the
Flatpak build in our CI already too. This should fix that issue.
Apparently it does a explicit version check for automake, but in such a
way that it needs to be patched on new automake versions. Patch this out
while we await the PR upstream to be merged into master.
See: https://github.com/jstedfast/gmime/pull/180
Rather than continuously calling `dnf upgrade` and `dnf install`, let's
make use of pre-built containers that we can auto-generate thanks to the
FDO CI templates.
This should cut down on the CI time considerably.
Note that this commit drops Ubuntu as a distribution for now. With
Fedora, we should be close enough to figure out if non-Flatpak builds
are broken, without doing packaging work for every distro out there.
You can test that this should be the correct order by adding a line for
each on a file and then running
```
$ cat "$TEST_FILE" | LC_ALL=C sort -r
```
Fixes: 43c23270a6 ("migrate locale from en_US.UTF-8 to C.UTF-8")
Setting these rules on `body.plain *` is not needed: they will cascade
quite happily on their own, with easier maintenance and readability for
humans
Also applies to rules whose values are unchanged from those on `body` -
better to keep these DRY
CSS and WebKit expects font size in pixels, but not "actual device pixels".
This fixes incorrect font size when using font-scaling with WebKitGTK >= 2.48.
Under older WebKitGTK versions result will be the same.
Refs https://github.com/WebKit/WebKit/pull/40412#issuecomment-2690897270
