We're already requiring a much newer version than we previously reported
anyway, since we were using for example `gnome.post_install()` which is
only available from Meson 0.57 and later.
So let's bump this to a somewhat more modern version which is available
in most distros.
The `license` named argument in Meson's `project` function is supposed
to be a SPDX license identifier. "LGPL2.1+" isn't correct here, so
replace it with the appropriate SPDX identifier.
Most lines in there were from a very long time ago, when we didn't have
separate bulid directories yet, or from people's specific local
configuration (which they should put in their own local git repo).
The last line that was added was for mimicking syntax highlighting
support in the GitLab UI, but since then that has grown support for
Meson build syntax, so let's just use that instead.
This was added as part of the JSON-to-YAML Flatpak manifest handling in
commit f7f72143e0. Since then, we've moved on to just use the JSON
flatpak manifest though in commit adca034818. Since those files got
dropped, we can drop their appropriate COPYING file as well.
`GLib.TestSuite` is a special type of object, as it doesn't actually
have an associated copy function or a reference/unreference function.
In practice, that actually means there's no way to actually have 2
strong references to such an object, or to copy it somehow. Due to the
way GObject properties in Vala work, that means you can't really use
them either.
Ever since vala commit 5f0a146f65, this got reflected properly in the
internally maintained GLib VAPI (as people were experiencing double
frees otherwise), but it was added only conditionally for GLib 2.70 or
later. In practice, that means you only get vala compiler issues if you
(impliclty) set `--target-glib=2.70` (or a later version).
To fix this for vala-unit and our own Geary tests, this commit changes
the `ValaUnit.TestCase` class to only allow "stealing" the strong
reference to the `GLib.TestSuite`, rather than somehowing allowing
people to hold a weak reference, and by also making it a protected field
rather than a property.
Since this changes the API of ValaUnit, we also bump the version. In
general though, I hope people aren't using ValaUnit externally, since
these types of API/ABI breaks can happen with Vala libraries.
Link: 5f0a146f65
Currently, a lot of our build variables that are defined at
configuration time, are spread out across the code base, often declared
as `extern` which can break when moving around sections of the code
across files.
This commit introduces a "Config" namespace which basically maps to the
definitions in `config.h`, but allows us to properly access them too
from the Vala source code.
By doing so, it helps us to more explicitly see where we rely on a
build variable from this file (which should be obvious from the `Config'
namespace).
To make it ourselves a bit easier in Meson too, we can declare an
internal dependency, which helps ensure that we pull in the dependency
where needed.
A lot of the .gitignore build was either outdated (for unused software,
or for the time we didn't have separate build & source directories), or
really should be something people shuld be putting in either their own
global `.gitignore`, or in `.git/info/exclude` for a local set of files
git should ignore.
This also removes the annoying problem that we can't easily add or
update .patch files we need to add for the flatpak build once in a
while.
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
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")
