The Win32 build was not taking the new path of git-version.h into
account and was outputting these errors:
> ../build/windows/gimp.rc:2:10: fatal error: git-version.h: No such file or directory
> #include "git-version.h"
> ^~~~~~~~~~~~~~~
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!).
...the installer component
The warning is actually not only about the installer, but also covers
the installed version of GIMP. The warning was resurrected from commit
6f0bb88e43 and slightly reworded.
In configure.ac, add --enable-windows-installer option (off by
default), which should be set to generate the necessary files for
the installer translations during the build. Using this option is
only supported when building from git, since the installer files
are not included in source tarballs.
Rename setup.isl.desktop.in to setup.isl.in, and instruct intltool
to treat it as an .ini file explicitly.
Delete generated message files during make clean.
Remove the installer graphics credits, since we use a different set
of graphics in master, and will probably use yet different set of
graphics for 2.10.
Add strings for the MyPaint brushes component. The setup script in
git doesn't use those yet, but this lets translators start
translating them.
Use intltool for managing the translations for the Windows
installer, instead of manually maintaining the translated message
files.
The message files are generated in the source directory, under
build/windows/installer/lang, as part of the build, and can be
subsequently used to build the installer, as before.
Though the bug was mostly fixed, it seems to still happen on Windows XP,
where apparently no content type had been registered for SVG.
GTK+ developers don't seem too keen to patch GTK+ 2.24 for a platform
which they don't support anymore.
Also if not mistaken, GIMP does not officially support Windows XP
anymore either. A patch though has already been provided by Edward E.
and it really doesn't look like it could break anything since it just
adds a last "else if" when everything else failed (and inside a #ifdef
affecting only WIN32 builds).
So let's just add it in our builds at least. We still don't have support
for it, but I see no reason to just refuse a minor patch which won't
break anything else.
The BaseApp json used for all 3 builds (stable, dev and nightly) is
common so just keep the one made available in the flathub upstream
repository. The patch also applies to the BaseApp only.
... interfere with GIMP UI events
Add a GTK+ patch to ignore top-level transparent windows when
looking for the top-level GDK window at a certain pointer location,
in the Win32 GDK backend.
The BaseApp manifest got a bunch of fixes, mostly to have all the
dependencies successfully build for aarch64. The current manifest should
therefore correctly build GIMP for i386, x86-64, arm and aarch64.
See: https://github.com/flathub/flathub/pull/124
The existing graphics are still from 2.8 (specifically, the have a
"2.8" caption, so we can't use them for 2.9); these are the
graphics used for the 2.9.6 installer.
... makes the list scroll down and select the next item
Adjust the file association list height to be a multiple of the
item height, to avoid this issue.
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).
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).
So I discover today that there is an option --ccache to request
flatpak-builder to compile using ccache, which is obviously a great idea
when rebuilding the same deps too often. Update the howto with the info.
Not sure why, because flatpak-builder used to compile webkitgtk just
fine, but not anymore. I get now a "call of overloaded ‘abs(gdouble)’ is
ambiguous" error. It looks like some header may have been updated in the
flatpak environment and causing multiple abs definitions. Using fabs()
instead works around the issue.
This is a first try at creating a docker-based build environment for GIMP.
The file has grown alongside building babl, GEGL, libmypaint and GIMP on a RHEL host running Docker. The main purpose of this image will be to serve as a base for building packages like Flatpak, AppImage and others, and serving them from download.gimp.org
it is not optimized at all, pulls in some extra packages, misses some optional dependencies, builds as root, ...
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.
Ell