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`.
Only the libwmf patches are still different. Apparently we may have fixed the
same bugs in different way on both branches. We should look later in details to
see if some patches are better than the other.
It's probably unneeded as the 2.99 installers are transient and anything
installed by GIMP 2.99 won't be in stable 3.0 anymore. Still, it's nice not to
have any weird warnings even in dev releases.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
… Windows installer localization.
There are kind of 2 separate bugs here:
- Direct i18n.gettext() to the proper data directory where to find the
ITS file. Otherwise `meson compile gimp30-windows-installer-pot` and
`meson compile gimp30-windows-installer-update-po` complained about
not knowing XML and falling back to C, which is obviously a problem:
> /usr/bin/xgettext: warning: file 'build/windows/installer/lang/setup.isl.xml.in' extension 'xml' is unknown; will try C
- Set gt:escapeRule to "no" in the ITS file, otherwise the XML entity is
kept as-is in the po file (i.e. "&" stays "&" inside the po
files), but it's considered as raw text when merged back to XML, i.e.
that the '&' is properly converted to a XML entity, so we end up with
a double escape "&".
Now the po file will have a '&' which will still be converted to XML
entity at merge time. This is actually most likely better than asking
translators to handle XML entities themselves (with the possibility to
make typos and break the XML entity).
See https://savannah.gnu.org/bugs/?58643
The Hungarian language file for the Windows installer was recently moved
from unofficial to the officially supported languages. However, a new
release including Hungarian by default is not available yet. This causes
our CI to fail because it can't find Hungarian in unofficial.
We change our ci script to download Hungarian from the correct location
for official languages, and adapt gimp3264.iss to reflect the correct
location.
The language files provided by the InnoSetup project (either the main
ones or the "Unofficial" ones, i.e. less maintained ones) at least
provides the name of the language, possibly in English, ideally
self-localized in its own language.
Unfortunately Kabyle didn't have any language file so we were using the
Default one, which ended up showing the lang as a duplicate (and very
wrong) "English".
With this commit, I add code to provide our own very basic base language
file, which would at least contain the language name. There is also a
concept of language ID to be verified in Windows-provided list.
Unfortunately it doesn't have any (actually it was id-ed 0x1000 like
many other languages, which looked therefore to be the code for an
unsupported lang). InnoSetup docs tells us to leave 0 then. We can add
the ability to set a specific code later in the template if we add other
un-provided languages and if they have their own lang id.
With this base infrastructure, we should be able to better support more
languages.
Unfortunately the weird encoding of a string to bytes to get the UTF-8
BOM worked on my local machine, but not on the Windows CI. I'm not going
to fight it and fallback to a shell script.
I am guessing it should work fine on all platform since we use basically
the same sed call in build/windows/gitlab-ci/installer-gimp-msys2.sh
already.
Inno-Setup absolutely requires it to recognize UTF-8 translation files.
This should hopefully be the final fix to #8338.
Note that this fix is full of workaround for meson bugs or limitations.
While it was a one-liner in autotools, added to the existing rule, here
I have to add an additional (non-relevant) target rule, then uglily work
around 2 bugs:
https://github.com/mesonbuild/meson/issues/1564https://github.com/mesonbuild/meson/issues/7696
I can't say I'm so happy about the resulting change, even though it
seems to work. If anyone can propose a nicer build rule, it would be
welcome.
Whenever we have an element without translation, we try to use the value
without a `xml:lang` attribute. That selector was wrong though, which
leads to https://gitlab.gnome.org/GNOME/gimp/-/issues/8338, which should
now be fixed.
