This is in part a port of commit 6f921b27bb from gimp-2-10 branch, except that I
could not easily cherry-pick because too much had changed already in the master
branch.
There are also a bunch of additional changes in some other glue scripts.
Also some rules which were in the 2.10 branch don't apply to the main one, such
as Python being copied from the x86 binaries, since clang-aarch64 has Python3
(unlike Python2).
See discussion in #9170 and !1091. It looks like this soon won't be a problem
with a recent llvm-windres (which is now patched). But until then, let's patch
upstream GIMP but only for this build.
Note: the additional `rm` call was done for this error:
> + mv _install-arm64 /home/SYSTEM
> mv: cannot move '_install-arm64' to '/home/SYSTEM/_install-arm64': Directory not empty
I guess the home directory is not properly wiped-out between runs, which is not
a huge problem as long as the runner is private to our project. Let's clean
things ourselves.
This localization was added recently but it was not in the installer scripts.
Discovered with unit testing: meson test gimp:build / windows-installer-langs
Organizing sub-dependencies into modules helps. Later if for instance we need to
remove or change OpenEXR, we know that they are related and that Imath can be
removed if we remove OpenEXR.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/9653#note_1780587
Looking at MSYS2 logs, it looks like they very recently "fixed" the search paths
for lua files, which in turn broke our workaround (searching in subdirectories
of bin/ instead of share/ and lib/).
This should work better (though untested) with the workaround removed now.
Commit on luajit package at MSYS2:
703c7bae2f
The creation of the BMP welcome images for the Windows installer (part of
-Dwindows-installer=true build option) fails in the Windows job. After much
debugging, I could run GIMP, yet it was not enough. One of my hypothesis so far
is that the environment variables for DLLs won't work, since all the DLLs must
be in the same directory as the main binary (though with the WSL thing, I am
unsure, maybe it is still supposed to work), which only happens once GIMP is
installed. So GIMP runs successfully but not plug-ins.
Anyway I wasted too much time working on this and without a local Windows, it
just takes too long (mostly testing thanks to the CI) and is frustrating. Let's
just move to building both the localization files and the images on the main
Debian job (gimp-meson-debian), then use these as dependencies of the
win-installer-nightly job, i.e. when building the installer.
The common order logic for list of directories in environment variables is that
left paths have precedence. This is at least the case for LD_LIBRARY_PATH (and
probably GI_TYPELIB_PATH too).
Make sure that our local libraries and introspected binaries (in the build
directory) are used and not any version installed on the system or by previous
`ninja install` calls.
This was a first attempt at fixing this error on the CI:
> Cannot open display:
Though it was not enough (see next commit calling plug-ins as non-interactive
when called without interface), it is still a useful change overall.
… being installed.
There is already most of the main code logic for this, though now plug-ins need
to be in their own subdirectories, which breaks for plug-ins/common/ and
plug-ins/python/, while I needed plug-ins in both these categories to generate
the Windows installer welcome images (file-png, and python-fu-eval in
particular).
Once again, meson was not very helpful, since all its functions still refuse to
output generated files in subdirectories, so I end up duplicating plug-in files
with a custom Python script.
This should fix the CI. It was working on my machine as GIMP was installed, but
such a build rule should work even without GIMP installed.
This will also be useful in the future when we'll want to run unit tests of
plug-ins through the finale GIMP binary itself.
After discussion with Jernej, InnoSetup should now work better with rescaling
a big image properly to the window size, yet the ratio should still matter.
Apparently the welcome image is a hack and this is why it requires specific
ratio images. We don't use the big size yet, but since Jernej told me which
dimensions are expected, I already added the code for it to make it easier
later.
So anyway this code would allow us not to have to commit welcome images each
time, which are basically resized copy in BMP of the splash screen, slowly yet
surely filling up our repository with image duplicates.
After all, we develop a scriptable image editor! We should use it to edit images
and export in expected formats!
I only use this script for the devel installer for now, for testing and see how
it goes.
While some packages may be needed only when building (and others only when
packaging), we should probably have a shared list of packages needed for both
steps so that we avoid discrepancies which lead to missing libraries in our
installer.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/9653#note_1777596
Don't set both a branch and a commit, otherwise flatpak-builder will
compare the HEAD of this branch (which may evolve with the commit).
Fixes:
> Failed to download sources: module qoi: Git commit for branch master is dfc056e813c98d307238d35f7f041a725d699dfc, but expected f6dffaf1e8170cdd79945a4fb60f6403e447e020
Because of this, the script was failing to get the version string, which
in turn was breaking InnoSetup.
This fixes the following InnoSetup bug:
> Error on line 116 in C:\_r\_builds\k3_3muaB\0\GNOME\gimp\build\windows\installer\gimp3264.iss: Value of [Setup] section directive "VersionInfoVersion" is invalid.
… for Windows.
Though it's useless for actually building the GIR files, we still need
this package now, for building script-fu with introspection abilities,
to generate GIMP and GEGL enums.
See the 2 previous commits for more information.
Switch to NASA-maintained cfitsio library for loading/exporting FITS images.
This allows us to import compressed FITS files (GZIP, HCOMP, PLIO, RICE) in
8/16/32 bit and float/double precision. It also simplifies export code using
the built-in cfitsio APIs.
It is actually available in the SDK but was removed from the runtime (relatively
recently, it would seem). As a more general rule, it seems that GNOME is phasing
it out slowly in favor of libappstream. So probably we should do the same
eventually.
Yet for now, to at least have a working nightly flatpak, let's add it to our
package.
I'm actually syncing with a branch which I can't test right now because flathub
seem to have some breakage. For the nightly, let's just directly push as anyway
we can't test in Gitlab MRs either because of the non-master jobs timeout.
See: https://github.com/flathub/org.gimp.GIMP/pull/202
We should always keep the diff between these files to a minimum.
- Fix the markdown styling.
- Add commands on how to build GIMP from the local repository instead of a brand
new clone (otherwise I don't see how one could develop with flatpak). I knew
it were possible, but until today, I never tried to do this so I had to test
first.
- The cron file was from the very early flatpak experiments before Flathub came
into the picture, as well as the GNOME Nightly repository. Back then, we
wanted to set up our own nightlies or release repository through a cron.
- It is still interesting to keep some instructions for local builds of the
flatpak as some people want to use this for development (but all the part
about exporting to a repository, signing, etc. is now unneeded for such use
case). So I'm updating the howto to more current recommendations.
- `flatpak-howto.txt` renamed to `README.md`.
Daniel Novomeský