The newer version of libpeas was released a couple of years ago already,
and at this point should probably be consdered the only maintained
version.
The changes are pretty minimal, and most should be pretty obvious from
the libpeas migration guide. The only annoying thing is that we can't
use `Peas.Engine.create_extension()` directly, since it's not exposed to
language bindings (even to Vala, which supports varargs, but alas).
Link: https://gnome.pages.gitlab.gnome.org/libpeas/libpeas-2/migrating-1to2.html
Fixes: https://gitlab.gnome.org/GNOME/geary/-/issues/1690
We started bundling libsecret in commit a085f90831 to workaround an
issue in the 0.20 version where looking up a password could indefinitely
hang.
Since version 0.21.4, this has been resolved, and this version is also
available in the GNOME runtime, so let's stop building it ourselves.
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
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
It looks like gmime moved to github a while ago already [1], which
should hopefully contain some fixes that are preventing our flatpak
builds from, well, actually building.
[1]: https://github.com/jstedfast/gmime/issues/119
duplicate_mailbox() unit test fails since this commit:
4a80ae527d
The commit is ok because it respects RFC 5322: 1 max From/To/Cc/Bcc
header.
We can't fix the unit test without breaking Ubuntu/Fedora builds so just
use same version.
Since WebKitGTK does not currently support printing under Flatpak,
enable RW access to XDG downloads folder, so at least people can print
to a PDF, then print that.
See https://github.com/flathub/org.gnome.Geary/issues/42
Build libstemmer as a shared library. Use current mainline since that
at least supports build system args.
Shared lib patch courtesy of Stefano Rivera <stefanor@debian.org>,
updated to current head.
