build-export is actually a low-level tool used by flatpak-builder. When
using it directly, debug and locale extensions were not extracted as
separate extensions (unless tweaking complicated command lines), ending
up with a huge GIMP flatpak with the current procedure.
Since flatpak 0.9.5, the option --export-only has been added to
`flatpak-builder` so that the build and the export can be made in 2
separate steps while using the high level procedure.
See: https://github.com/flatpak/flatpak/issues/824
In particular, I didn't have the correct metadata because I was missing
appstream-compose. This should be a dependency of flatpak. But for the
time being, let's just have a note in our howto.
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 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.
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.
Jehan