GitLab

In particular a bunch of dependencies were moved to the BaseApp.
Dev flatpak is actually a bit useless now (since last dev release is
older than stable). But I keep the dev manifest around to make it easier
to update for the future when we'll have a new dev release.

Dev flatpak now builds the 2.10.0 RC1.
Both manifest tested and working.

We now use the GNOME 3.28 runtime and glib 2.56.0 is bundled with it.

Untested. Hopefully should build.
Also bump the GNOME runtime to the latest version.

I completely forgot to rename the appstream file according to the new
ID. While doing so, I also make it a .in.in file, with initial
processing by the autotools. Indeed I need @GIMP_COMMAND@ to be replaced
by AC_CONFIG_FILES().
Finally I fix a badly closed XML tag (which reminds me I should always
test a commit, even when it's a simple non-C 1-liner change!).

Tested and successful flatpak build!

We now need glib 2.54.2 which is not available in org.gnome.Sdk,
neither 3.24 nor 3.26.

Untested, but that should work!

I had an error in the previous commit (2 args in 1). Also adding access
so that the file `bookmarks` is visible from the contained GIMP
(otherwise bookmarked folders are lost in flatpak and that's bad
experience).

No full bus access, as proposed by flatpak upstream.

For some reason, the "cleanup" tag won't delete the files produced by
the BaseApp inside the main GIMP manifest (I still need them for build,
but want to delete them for runtime).
This is a workaround to delete them with a few command lines for now.
See: https://github.com/flatpak/flatpak/issues/1082

Keeping all dependencies inside the main manifest is very annoying
because flatpak-builder will check them every time the package is
rebuilt. Worse, sometimes the cache won't be hit (even though it should
have), resulting into a rebuild of many dependencies. I create a BaseApp
build which is the recommended process (and not creating our own runtime
based on GNOME one's, as I first thought) which won't need to be built
as often as the main manifests. The other advantage is obviously that
this BaseApp can be shared between the dev and nightly (and likely even
the stable later) builds. I will only keep differences inside the main
manifests (for instance lcms2 which requires a higher version on master
than on the GNOME runtime and the last dev release).
I also move webkitgtk as the first dependencies since it takes too long
and flatpak uses a sequential dependency graph (so any change to a
previously listed dependency, even when actually unrelated, was
triggering a rebuild of webkitgtk!).
Only remaining issue is that I don't manage yet to run the cleanup of
the BaseApp at the end of the main manifests (for files needed for
building, but not at runtime).

And rename the current manifest as being a nightly manifest.

With the bump of our runtime dependency, lcms 2.7 is now available from
the runtime environment.

The GNOME sdk runtime used to be built which flags not appreciated by
older CPUs. This has now been fixed. Let's get rid of our workaround.
See https://github.com/flatpak/flatpak/issues/143

See the upstream issue where python2 would crash on some platforms, yet
not others: https://github.com/flatpak/flatpak/issues/143
For this, I disable introspection on GEGL (which is anyway not useful
in the Flatpak build, I believe), and wrap gdbus-codegen in a temporary
build script for GIMP to force it to use Python 3 (I can't force
globally the $PYTHON environment variable like on Webkit because GIMP
needs Python 2 as dependency).

For some reason, Webkit would not build with Python 2 on a different
machine though it did on mine. Let's just force Python 3 usage (for
build only, not as a runtime dependency) by setting the $PYTHON
environment variable during this build. Anyway Python 3 is available
from the base build so it's not a new dependency.

We can actually group modules together to mark their relationship,
and easily deactivate them together if needed.
I grouped all Python modules, Exiv2 under GEXiv2, ilmbase under
openEXR, and finally libpng and lcms2 under a "duplicate-dependencies"
module to indicate that these modules are available in the runtime
(under a lower version, below our requirements) so we should check
whether to remove them, upon runtime update.

The build has been fixed by a patch from Upstream:
https://bugs.webkit.org/show_bug.cgi?id=156510
Note that WebKit takes hours to build, so if you just want to test
Flatpak, you may prefer disable this module again.

We now have a full-feature Flatpak build, except for libgudev, which
means that special input devices probably won't work in the GIMP
Flatpak. It is to be noted that Flatpak developers told me that
libudev won't work inside the sandbox anyway. A portal will have
to be implemented. See:
https://github.com/flatpak/flatpak/issues/12#issuecomment-276016074

The last stable WebkitGTK is 2.14.3 but that apparently corresponds to
WebkitGTK4 (which is already in the GNOME runtime). We need an older
version, and the last available would be 2.4.11.
I disable it though because the build failed in my test but let's save
my work-in-progress.

This is a special case build, since make must be run with "so",
and install is `make soinstall` to get a shared library.
See: https://ghostscript.com/doc/9.20/Make.htm#Unix_build

This is necessary for opening files from the network.
It is actually possible to allow only some named service bus which
would be much more in line with proper sandboxing. But I can't find
exactly what is the service name used for gvfs (which is the virtual
filesystem apparently used internally for remote file access in GIO).
Also I'm pretty sure we must use other buses for various services. We
should make a list of what service bus are necessary for normal usage.
For the time being though, let's just have a flatpak build with as many
features as possible.

I had to figure out a few things about making CMake builds in Flatpak
since jasper moved from autotools in recent versions.

Main missing dependencies now are libgudev, webkit and ghostscript.

Based on Alexander Larsson's original nightly GIMP flatpak. I updated
most dependencies, changed some options, and added some dependencies
whose versions were now too low in the runtime (libpng and lcms2).
I also use the new "--filesystem=xdg-config/GIMP" option, made upon my
request, which means we will want to use a recent flatpak.
Many options are still missing but that's a start with a working
flatpak manifest.