Why:
1) users can install .scm scripts to plug-ins dir
2) Crashing scripts do not crash extension-script-fu
Scripts (.scm files) have a shebang and are executable
and in a same-named subdir of plugin dir.
Interpreter/scripts create PDB procs of type PLUGIN unlike extension-script-fu
which creates PDB procs of type TEMPORARY, owned by extension-script-fu.
Unlike other interpreters, the interpreter is-a plugin outright,
not by virtue of the script subclassing GimpPlugin and using GI.
More details in /plug-ins/script-fu/interpreter/README
(1) On recent meson versions, it fixes this error:
> extensions/goat-exercises/meson.build:108:0: ERROR: i18n.merge_file keyword argument 'output' was of type array[str] but should have been str
As docs explains, 'output' only accepts one item in i18n.merge_file().
This bug also happens on older meson (but there the reported error is a
lot less useful as it doesn't mention local meson build code).
(2) `setup.isl.xml` is a temporary intermediary file used to create the
Windows installer. It must not be installed.
(3) `gimp30-windows-installer.mo` itself is only used to create
`setup.isl.xml`. It must not be installed as well.
(4) gimp-tips.(its|loc) files (same for gimp-tags ones) should not be
installed. They are only temporary data.
(5) Fix environment variable: s/GETTEXT_DATA_DIRS/GETTEXTDATADIRS/
Fixes:
> /usr/bin/msgfmt: cannot locate ITS rules for ../../../data/tips/gimp-tips.xml.in
(6) Fix various bugs in the *.setup.isl files creation in autotools
build (typo, wrong files used, order of options in `xsltproc`
apparently meaningful, and so on. I guess the autotools build was
not as well tested as the meson one :P).
(7) Fixing the unit test verifying language lists consistency.
(8) `setup.isl.xml.in` must be added to the distribution.
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
This will allow to use the official Windows installer directly in the
Windows Store, as per the new proposed workflow by Microsoft.
Nevertheless our GIMP for Windows has a built-in update check which
would check if a new version exist and warn people (advising them to go
on the website and download the new installer to update). We obviously
don't want this on the Windows Store which has its own update channel.
It would be confusing.
Therefore I added a feature to disable the built-in update check (not
even showing in Preferences) by tweaking a single package variable. The
installer now comes with new option /DISABLECHECKUPDATE=true which will
add said variable.
JSON does not support comments and their support in Flatpak is possible
through use of json-glib[0]. This is problematic in fully utilizing
flatpak-external-data-checker because its JSON writer does not respect
existing comments. To solve this, make use of Fltpak's specific
behaviour where a "//" key is explicitely ignored while parsing[1].
[0] flatpak/flatpak-builder#363 (comment)
[1] 0e98b7ae19/src/builder-utils.c (L1250)
OpenEXR and mypaint-brushes offer next major versions. GIMP is probably
not ready for the changes in OpenEXR and mypaint-brushes are not yet
finalized. Put their versions under constraints so that automatic PR
creation for dependency bumps can be enabled.
It looks like the gi-docgen build is broken on Windows (though the CI
does show neither stdout nor stderr output, just a failure without
message). This should be fixed, but it's not necessary for the installer
at least.
Note: on autotools, the gi-docgen step works fine on Windows.
We didn't need to do this on the autotools build, simply because the
configure step is much more elaborated there, and was checking for the
header file as well as well as a working mng_create() API. But since
libmng was broken, the test failed, so we didn't need to disable it.
By the way, we should check when the `.pc` file was added, because if it
was after the required version, then the meson test is very wrong. It
should not have been different from the autotools file.
The meson build still has a bunch of issues and build bugs compared to
the autotools build, nevertheless the last blocker issue was dealt with
a few days ago (PDB source generation).
Moreover since the meson build on Windows especially makes such dramatic
difference, in terms of build speed, this is a big improvement for
Windows contributor's comfort, and as such is one less barrier of entry.
Anyway I believe that most Windows developers build GIMP with meson now
so sticking on autotools on this platform is just counter-productive.
This is why it was decided to now make meson the recommended build
system on Windows, as a further step toward a move to meson. It is still
not the recommended build system on the other platforms yet.
The --debug option so far would only output debug info. I want both the
run to actually occur and the debug to be printed, at least in some
cases. So I make this a choice option with 3 variants (no debug, debug
only and run + debug).
Similar to the change I pushed to gimp-help repository:
intltool-extract does not consider the `;` isl-syntax comments because
we tell it it is in the ini format. So let's have our source in actual
ini format (POTFILES does not like to look for translated strings in
constructed files, only from source files), then create the .isl files
from it in 3 steps (first, transform the comments in isl format; then
merge all language in a single .isl file; last generate one .isl per
language).
There were already a bunch of comments in the setup.isl.in file (though
not showing in the po files until now). I checked if they seemed
relevant, fixed some, completed others, duplicated the ones which match
several strings, etc.
(This improvement to allow comments for translators in the installer po
files was requested by Piotr Drąg on the gnome-i18n mailing list)
Some tools have been moved. `aclocal` (and likely other tools, but this
was the first one making an error in the deps-win*-native CI jobs) is
now in `automake-wrapper` package, which itself is a dependency of
`autotools`.
Cf. https://github.com/msys2/MINGW-packages/issues/11114
Instead of replacing various needed macros with random hardcoded values,
just make them mandatory and exit with explicit error when a needed
macro is missing.
Since 2afa019c70,
the Meson configure step will fail when building from tarball (missing `.git` and `gitversion.h` is present)
because `gitversion_h` variable will contain a `list[file]` but `custom_target` does not like that in its `depends` kwarg.
We were already avoiding re-processing a same DLL within the same run
(this can happen when 2 dependencies have themselves a common
dependency). But the dll_link.py script was stateless regarding previous
runs so we might be checking again the same DLLs multiple times (even
though we were not copying them again).
Let's make the script stateful with a new parameter to give a file where
all the previously processed DLL names are stored. I am hoping it would
improve the efficiency of the packaging-win32-native which is suddenly
extra slow (it always times out, even after raising the max job time;
now we time out after 2h30! The 64-bit packaging job just takes 1h,
which is too much already, but still much more reasonable).
This includes:
- "copy-icon" set
- Permission and cleanup rules updated
- Exiv2 bumped to 0.27.5
- Adding an x-checker-data for OpenEXR
- Poppler bumped to 22.01.00
- OpenBlas bumped to 0.3.19
- graphviz bumped to 2.50.0
Also improving a bit the download script by specifying the .isl or .islu
file extension. It's nicer than trying to download randomly, and also it
allows to better compare the list of downloaded files with the list in
gimp3264.iss script.
My previous command was also adding a linefeed just after the BOM. While
I'm not sure it would really break anything for processing these, it's
anyway much more correct to only add the 3 BOM bytes. So here is the
improved command.
Also some language files are supposed to be UTF-8 yet they are missing
the BOM markup (only method to recognize them for InnoSetup). This is
the case for Chinese Traditional. See issue #7676.
Make sure that this lang file has a BOM.
One is a patch for a GExiv2 version below the one we now require, the
second is a patch for GIMP which is now committed and pushed.
Cf. commit 7ed68556c7.
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
Also when working on out-of-tree builds, it would not find the file
anyway and we get this output:
> chmod: cannot access 'test-installer-langs.sh': No such file or directory
Though this was not breaking the tests, it has clearly been useless
until we see this one today.
The patch we needed to test needs completion, so it's of no use to
continue building it until this happens.
Also for some reason, the x86_64 build of GTK3 takes forever and times
out (the same build for 32-bit x86 is done quickly as expected) on
repeated occasions. Since this is unneeded right now, rather than
wasting time on this, I just delete this dep build to use the pre-built
MSYS2 package.
Rewriting commit f8cdec1883 by Jernej Simončič for the development
code (which has a slightly different list of languages).
Also adding the meson version of this change.
Since now InnoSetup fully supports UTF-8 isl (as long as they have a
BOM), let's stop converting translations. Then we also avoid all
conversion errors and get a simpler/more robust build process.
I noticed in our build logs such output:
> Saving to: ‘Basque.isl.53’
Wget does not override same-named files and would append a number. The
thing is that we are not supposed to have other .isl files over there,
but I think current Windows runners on Gitlab are not properly wiped
out. That must be why we get remnant of old files.
Anyway this will make sure we override, hence use the last version of
translations (otherwise we are stuck to old versions as long as they are
not wiped out, since the downloaded file is not properly named).
This tool seems like a mess with various implementations (maybe
distributions patch it?). I'm trying to tweak the script so that it
works at least on the Debian testing/bookworm CI and on my Fedora 33
desktop (and hopefully on more, if not all distribs).
Note that I first thought to use the full option name (`--auto-display`)
but I just got the same error again. It seems xvfb-run from Debian
bookworm just doesn't have this option, and only the older option
--auto-servernum (which is said to be deprecated in favor of
--auto-display in Fedora's xvfb-run for instance, but apparently not on
Debian). At least this works on all distributions (or so it would seem).
Fixes:
> xvfb-run: invalid option -- 'd'
The [[ ]] is not POSIX, hence less portable.
I see our `ninja test` calls in Gitlab CI output a:
> /builds/GNOME/gimp/build/meson/run_test_env.sh: 7: [[: not found
(though it doesn't break the tests)
I forgot to do this so GIMP 2.99.8 official release is marked as
"unknown" instead of our official build. It's alright for this one
(especially for a dev release), just setting this straight for further
builds.
Anyway we disabled use of ccache in an earlier commit 2da70b3fb7 because
of a bug in MSYS2's CPython. So there is no need to call these commands
either. Also it seems to be breaking the 32-bit native Windows build
(from CI log, I am unsure this is because of ccache, but the break
happens just after running `ccache --zero-stats`).
This is untested on my side, because the bug only happens on native
builds with meson (our CI has cross-builds with meson and native builds
with autotools and I only do cross-builds locally) but I think/hope it
will work.
Basically we were using .full_path() because these rc files were also
used as input of some configure_file() calls which doesn't like custom
target objects as input (it wants strings or file objects). Yet a bug
in meson didn't like the colon used in native Windows full paths ('C:'
and such) when used in windows.compile_resources(). This has been fixed
by Luca Bacci in: https://github.com/mesonbuild/meson/pull/9368
Yet we just cannot depend on very early meson (or worse dev meson code).
On the other hand, if the input is a custom_tgt object, it uses the
object ID which we give as first parameter of custom_target() so we know
it's appropriately named without colons (such as 'gimp_plugins_rc').
Thus we should not bump into this issue again.
For the few usage in configure_file(), I just add a .full_path() only
when needed at call time.
Last but not least, I replace the bogus `meson --version` call by a
`python3 -c 'exit()'` as advised by Eli Schwartz:
2afa019c70 (note_1284951)
The reason is that it is apparently possible (or will be when some
reimplementation of meson will be done) that the `meson` executable
itself does not exist. On the other hand, `python3` should always be
there, as a mandatory dependency of the build tool.
In order to use an appropriate `python3`, I made the
pythonmod.find_installation() check required in our build (which should
not be a problem since it's a meson requirement as well), even when the
-Dpython option is false (this one depends on other requirements too
anyway, such as version and pygobject). This way I can call this meson
variable of discovered python in my bogus call, instead of calling a
(potentially different) python from PATH environment.
All the os.EX_* constants are Unix-only (and possibly not even not on
all Unix/Linux-like platforms, according to docs) so we should not use
them, especially for a script which we may use on Windows (we also run
it when cross-compiling from Linux, but natively on Windows as well).
Fixes this exception (which would only happen when there is another
critical issue anyway, so it's not making a bigger problem; yet it's
better to cleanly exit with an error code rather than by an exception):
> File "C:\_r\_builds\k3_3muaB\0\GNOME\gimp\build\windows\gitlab-ci\dll_link.py", line 124, in copy_dlls
sys.exit(os.EX_DATAERR)
> AttributeError: module 'os' has no attribute 'EX_DATAERR'
Also use it to fix packaging of GIMP for the Windows installer (native
CI job). The CI was indeed failing to package libbrotlienc.dll,
dependency of libjxl.dll, for the simple reason that they were on
different prefixes. By calling dll_link.py on one prefix, then the
other, we were failing to grab the deeper dependency. Now with this new
ability to set several sources, the script is able to search everywhere
(with first prefix given on the CLI call as priority).
I always have to search again the InnoSetup repository for the language
file. Add the link in the failed test output so that we don't waste time
searching the next time.
Also when the new lang is "Unofficial", the installer script has to be
updated as well, because these lang files must be downloaded. Add a help
text saying this as well.
Translation files were added in commit cec3c3a159 but not to the
installer and build files, which is why "gimp-distcheck-debian" job was
failing in the CI.
After some recent patch added to Python on MSYS2, in the same time as
they bumped from Python 3.9.6 to 3.9.7, our native Windows build started
breaking.
This patch modified `cygwinccompiler.py` to use CC environment variable
as being necessarily a single executable whereas if it were made of 2
commands (such as "ccache gcc"), the call was failing because the code
now tries to find a single command with this name (as though the space
belongs to the file name).
Therefore the line:
> File "C:/msys64/mingw64/lib/python3.9/distutils/cygwinccompiler.py", line 451, in is_cygwincc
> out_string = check_output([cc, '-dumpmachine'])
Resulted in the error:
> FileNotFoundError: [WinError 2] The system cannot find the file specified
For now, let's just not set ccache this way, even though this method is
normally meant to work and is one of the 2 officially proposed methods
(the other being to use symlinks named as compilers in priority in
PATH).
Also I'm not even sure ccache is useful at all right now (is cache
finally stored/reused between CI runs? I remember we tried to make it
happen, but I can't remember if we really had this properly in the end).
See: https://github.com/msys2/MINGW-packages/issues/9677
From Flatpak's NEWS:
> A new fallback-x11 permission grants X11 access, but only if the user
> is running in a X11 session. For applications that support both
> Wayland and X11, this can be used to ensure that the app doesn't have
> unnecessary X11 access while in Wayland, but still works in an X11
> session.
by adding special filler custom_target() build rules.
Basically, these build rules do nothing (a mere meson --version call),
but they ensure that `git-version.h` is built first, before the dependant
rc files are used in respective resource compiler build targets.
This still a nasty trick (not a proper solution), but it do the job.
See #6257 for additional information.
This is based from changes in wip/release/2-99-8 branch or the Flathub
flatpak (so not necessarily released yet):
- libheif bumped to 1.12.0
- Cairo with new patch to fix#235.
For the installer, we must also manually pull all used official
language, so I am adding a test checking that the list of pulled file
matches the list from the installer script.
libwmf was still relying on a script called freetype-config instead of
using standard pkg-config. It seems it got wiped out in recent freetype2
(or at the very least, this script is not present anymore in freetype2
version 24.0.18 from master runtime of GNOME SDK).
This patch uses pkg-config in libwmf configuration instead.
As I also had some autoheader "missing template" warnings (which were
failing the recreation of config scripts), I add placeholder
descriptions to AC_DEFINE() macros, as this is apparently now mandatory.
We were building it to add the patch glib!2020, but it has now been
backported in MSYS2 package:
https://github.com/msys2/MINGW-packages/issues/9154
This was about the most infamous bug #913 for very slow file dialogs on
Windows when some drives are disconnected, or with slow/non-accessible
network drives or even fake floppy drives created in the Bios.
Similarly we also wanted glib!2205 and glib!2210 for bug #6780 about
GIMP crashing unexpectedly when images are opened in other (apparently
unrelated applications). I had not updated our build scripts yet, but
anyway, it got backport to the MSYS2 package first, then even to GLib
2.68.4 which has been recently released (and bumped in MSYS2 as well).
See: https://github.com/msys2/MINGW-packages/issues/9283
So let's rely again on MSYS2 package!
I completely forgot that since the installer is built on a Windows
runner, I cannot expect a standard Linux shell syntax.
As a consequence, commit de9a171a19 broke the "win-installer-nightly"
job with the following error:
> The token '&&' is not a valid statement separator in this version.
Rather than trying to find the equivalent command to run on powershell
or whatever, let's just compute the checksum at the end of our installer
creation script.
Synced from the beta flatpak. The previous manifest rules were building
fine on Flathub build servers, but not on GNOME CI ones. It resulted in
a bunch of "ISO C++17" errors when building ilmbase.
Maybe just restricting to C++14 through build fine would have been fine,
but anyway let's also update the dependencies in the same time as we
were outdated.
As per state in the wip/release/2-99-8 branch of the beta flatpak.
In particular, we update some dependencies (poppler, ghostscript and
SuiteSparse).
It should also fix the master flatpak build which seemed to fail on
downloading SuiteSparse sources. Since their upstream moved their
tarballs to be downloaded from Github, it should take care of this issue
by side effect.
The MSYS2 package got recently bumped from 3.8 to 3.9.6.
At first I wanted to update our packaging and installer scripts to be
more generic using glob patterns (so that they should work now and
should continue to work even if bumping to a higher minor version in the
future). Unfortunately this would work for `package-gimp-msys2.sh` but
in `files.isi`, it would only work for `libpython3.*.dll`, not for the
python3.9/ folder. InnoSetup apparently doesn't support using a folder
as source (or maybe just a folder with glob like `python3.*`) as it
resulted in a "No files found matching" error.
So leave everything with the accurate version (because anyway it's much
better to get an early failure than only at the very last step).
Same as MSYS2, add a patch to fix keyboard input when using IMEs (which
should hopefully fix#1603). Note that this patch should be in the next
release.
Also remove the Windows Pointer Input Stack support as it is in 3.24.30.
Finally apply the patch from gtk!3661 for testing (instead of the patch
from gtk!3275), as it is supposed to fix#5475. This is the reason why
we still build our own GTK3.
We don't know when the next GTK3 release will be and this is cool enough
that we want to test it soonish, even more with MR !458 coming soon with
a Preferences option.
The dll_link script would overwrite the same dependencies over and over,
for instance when needed for several binaries, but worse when available
in several source directories. In our case, we look up 2 source
directories: our install prefix first, then the prefix for MSYS2
pre-built packages. So it turns out we would be overriding any
custom-built package also installed through MSYS2 (such as our patched
GLib, see my previous commits).
As a side effect, it should also make the packaging step faster as we
don't re-copy unecessarily the same DLLs over and over again. The first
one to go in stays in.
Since gio searches its modules based on the paths as advertized by the
pkg-config, let's just move the pre-compiled modules (by MSYS2
packages). We build the same version of glib2 with the same options, and
only one additional patch. So this should not be a problem to use the
pre-built modules rather than rebuilding glib-networking too.
The MSYS2 package for glib2 does not include the patch to reduce delays
of disconnected volumes (glib!2020).
Let's make our own build in our CI for our installer (hence also
experimenting overriding MSYS2 packages when necessary).
Except for this patch, this is the same build as MSYS2 and same option,
as described in:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-glib2
We were only comparing the po list with the language list in the
gimp3264.iss. Nevertheless since we also generate the <code>.setup.isl
files, we should also verify generated files corresponds exactly to the
same list of languages.
This commit does it for meson and autotools build.
This is also how I fixed the meson list (cf. previous commit).
… conversion when some characters are not convertible.
Currently failed conversion ended up in incomplete .isl files (autotools
build) or would break the build (meson build). Ideally we should use a
target encoding which contains all source characters, but we use the
encoding as set upstream in the LanguageCodePage for the given language
file.
I'm not sure if maybe we can mix the encoding by adding our own
LanguageCodePage at the top of our generated <code>.setup.isl, then we
could just use UTF-8 for any language. It will have to be tested.
For now let's just discard non-convertible characters, assuming there
shouldn't be too many of these. It's the lesser evil in this situation.
- dri access needed (cf. commit de8be943 on our Flathub repo).
- GNOME runtime still only provides lcms 2.10 (even in its master build)
and we need version 2.12 to avoid some crashes (cf. commit ae60863e
from our flathub repo).
Trying to keep the differences to a minimum. There are still some, like
the extension point is absent from the nightly manifest, but I'm not
sure if it makes sense to have it there.
Also top "cleanup" list is different but we should probably take a
closer look at this. Maybe it's outdated on both sides anyway.
This reverts commit 61389adfa0.
I was initially hoping to debug why the GEGL `master` HEAD was
presumably failing to build (according to the reverted commit) but it
actually doesn't (as tested in a feature branch's CI) even though I
don't see any recent change looking like a build fix. So let's just do a
simple reverse. :-)
- Poppler 20.10.0 to 21.04.0
- poppler-data from 0.4.9 to 0.4.10
- OpenBLAS from 0.3.9 to 0.3.15
- libde265 from 1.0.7 to 1.0.8
- gexiv 0.12.1 to 0.12.2
Add patches and dependencies needed to build the development
version of GIMP. Also switches the in-tree manifest to using
the nightly branch of the GNOME SDK and meson
as the buildsystem.
Since we moved most of them to bin/, share/lua*/ and lib/lua/ files are
not necessary anymore (according to my tests so far at least). Let's not
include them.
Also exclude the lua DLL from the generic libraries. It is only for when
the lua option is set.
No need to have GIMP trying to run the Javascript goat-exercise at
startup. All it does is make annoying error message on console output.
We know it won't run because no interpreter is available. No need for
trying.
It looks like the DLL ends up searched into bin/lgi/ and other lua files
from bin/lua/. There might be better solutions for the issue, but for
the time being, it seems to work ok.
Note that ender used instead to rebuild lua with the following changes
(cf. IRC):
> src/luaconf.h:
> #define LUA_PATH_DEFAULT \
> "!\\..\\share\\lua\\5.1\\?.lua;" "!\\..\\share\\lua\\5.1\\?\\init.lua;" LUA_LDIR"?.lua;" LUA_LDIR"?\\init.lua;"
> #define LUA_CPATH_DEFAULT \
> LUA_CDIR"..\\lib\\lua\\5.1\\?.dll;" LUA_CDIR"?.dll;" LUA_CDIR"loadall.dll"
But moving files around in the installed tree is much simpler than
rebuilding the whole lua just for this.
Note that I must not install both lua51 with luajit because these are
conflicting. Let's go with luajit from feedback we had on the best
choice (though this topic itself seems a bit heated actually).
Also clean-out the unexpected file removal because now I had the
opposite case, i.e. a CI problem because of this. And from my latest
tests, it seems to work ok for the time being without, which is much
cleaner anyway. So let's go like this for the time being.
- libwmf patch for issue #4061 is applied upstream (libwmf). Even though
no new libwmf release happened, the MSYS2 package applied the patch to
libwmf 0.2.12. So it's in our installer. Thanks to lillolollo for
staying on top of things, as usual.
Cf. https://github.com/msys2/MINGW-packages/pull/6977
- glib permission issue (#4594 about GIMP preventing the third-party
software Spotify from starting) is included since glib 2.67.6/2.68.0.
Since MSYS2 uses glib 2.68.2, it's all good.
- patch for deprecated GTK+2.24 was kept in `master` repo mostly as a
reminder of having to deal with issue #1082 (former bug 780979) about
transparent windows from other software interfering with GIMP. This
was fixed as gtk!2767 which is available since GTK 3.24.27. MSYS2 uses
GTK 3.24.29 to this day.
Note that this patch is still relevant in the GIMP 2.10 series (hence
in gimp-2-10 branch), not in the current GIMP 2.99 series.
By enabling this option on Linux, not only will the installer language
file be generated, but the `make check` will also now validate that the
lang list is consistent with existing gettext files (see commit
8a42c6ccc2). So it's useful information to know this for instance as
soon as some translators add a new localization.
Also oppositely remove the option on the MSYS2 native Windows 32-bit
build. For Windows, we only need this option once, as we use the
language files generated by the 64-bit build.
Add GObject Introspection libs, python libs and various binaries. Not
sure why we need 3 python binaries. This would need to be investigated
and possibly cleaned up a bit. Similarly maybe it would be better to be
a bit more selective about what we take from lib/python3.8/ folder
(looking what's in there, I wondered if some of the stuff were not
pulled by some dependencies and/or should maybe be filtered out).
But for now, let's make the InnoSetup scripts happy.
In any case, the resulting installer was tested and now Python plug-ins
work successfully. Wouhou!
Otherwise the extension files from the 32-bit build override the ones
from the 64-build. This is wrong first because we get 32-bit executables
uselessly (even though Windows 64-bit can run them, we should install
the right ones) and also because we don't build Vala plug-ins on 32-bit
(doesn't work for some reason) and as we override the extension
manifest, the Vala goat exercise is not made available even though it's
installed.
This way, we will avoid in the future any discrepancies between
languages set in the Windows installer and available translations (po
files in po-windows-installer/) because `make check`/`ninja test` will
fail.
I left the version I was using while testing, but this is obviously
wrong as we would always forget to update it (actually even now it was
wrong as it was producing an installer versionned 2.99.6 whereas it
should have been 2.99.7!). Instead let's grep the major/minor/micro from
the build system.
- Adding a patch sent to me by Sylvie Alexandre meant to help aalib
build on MSYS2 for Windows 32 and 64-bit.
- Additionally, add an additional patch from myself because it was still
not building properly.
- Also update the config.guess|sub files because the original ones (from
2001!) were just too old and not properly recognizing the host mingw
system (especially the 64-bit one apparently) in the MSYS2 CI jobs of
GIMP.
- Finally regenerate the whole aclocal/libtoolize/autoconf/automake
build system because these old files just don't play nice with recent
autotools though the source files still regenerate fine (despite with
some warnings, but nothing blocking).
- Add crt-git dependency because libws2_32 is in there.
Run InnoSetup in the Windows CI to build the installer from both the 32
and 64-bit builds.
Current limitations:
- No installer signature yet.
- Dependencies will have to be checked more thoroughly.
- Apart from babl and GEGL, we may want to make custom builds of any
package which has a patch in build/windows/patches/ (Windows-specific
patches) and build/patches/ (all platform patches).
- Plug-in interpreters (Python, Lua…) don't work. This will need to be
looked at in detail.
Globally this first automated installer build works fine though, as I
could install it in a Windows 10 VM and GIMP ran fine! So it's a first
step towards fully automated releases for Windows.
With compression level "ultra64" for LZMA, default value is 65536, which
is far enough (the installer file was only 100kib bigger, it doesn't
make that big of a difference in the end).
With the original value, the CI build would fail with "Out of memory"
error.
See also: https://jrsoftware.org/ishelp/index.php?topic=setup_lzmadictionarysize
Do not try to follow up on the installed ghostscript (otherwise we'll
always have to fix as MSYS2 packages get updated). Instead, just install
whatever is in the /share/ghostscript/ path (assuming there is data for
a single version, which should be the case, especially on a resetted CI
build) and excluding the /doc/ folder.
These files I'm adding are currently being requested by the installer
script, even though I'm not sure at all how much needed they are,
especially for some of them (because I could successfully create an
installer by just commenting these out in the installer script).
Note: Vala API doesn't build well on the 32-bit build. Not sure why (the
meson logs for GObject Introspection build are just as empty as ever),
but it won't generate the VAPI. So I disabled the option on 32-bit.
Based on available files in po-windows-installer/, here is the exact
corresponding list. Many <code>.setup.isl were not generated, even
though translations existed, and oppositely there was one (hr) which has
no translation file.
This new job resulted in a package which allows to run GIMP on Windows
(as tested in a VM; at least it starts, I can create a new canvas and
paint). Of course I think this will need to be tweaked a little bit
more, as I'm sure we miss things here and there.
At the very least, even though I add the Python and Luajit binaries,
GIMP on Windows didn't find them. This will need to be investigated.
Also it looks like opening from a remote location may not work. Not sure
if this about a missing GIO module or maybe something which works
differently on Windows (I was not even able to drag'n drop from the
browser!). Anyway this needs to be looked at as well.
Note that gdk-pixbuf-query-loaders is apparently unneeded when GIMP is
built this way (unlike with our crossroad build).
All this to say that this is still an early attempt to full CI build for
Windows.
It doesn't invalidate the crossroad build, because cross-compilation
builds from Linux will always stay very important for Linux developers
to be able to easily fix Windows bugs too; yet the crossroad build has 2
major issues:
1. We haven't figured out yet how to run GObject Introspection tools for
cross-builds, so the crossroad builds are not full-featured (and this
is quite a major feature we are missing!).
2. Also I will want to run the installer in the CI at some point and the
one we use can only run on Windows itself AFAIK. We could try to run
it through Wine, but still anyway the point 1. is already quite a
blocker, let's do the simple thing.
Note that we will likely want to move to meson for this build, because
autotools is very slow on Windows. But as long as the few blocker meson
bugs are not fixed, let's stick to the slow yet good build.
Without this, the native Windows GIMP build fails in CI with:
> make[2]: *** No rule to make target '_install\include\gegl-0.4\gegl.h', needed by '../libgimpcolor/gimpadaptivesupersample.lo'. Stop.
Even though `gegl.h` is present (as checked through artifacts). It's
just so weird.
The build rules were highly inspired by other projects on GNOME's
Gitlab. All of them used to build with ccache. It worked fine for the
main build, but completely broke GObject Introspection build on both
babl and GEGL. And the worse thing is that meson was absolutely not
displaying the error, just saying it failed (even in verbose mode). A
lot of time wasted trying to debug.
Therefore let's get rid of ccache, but only for babl and GEGL. Keep it
for GIMP itself as it works fine there.
Other minor changes:
* Build from the build dir, rather than source. The other way around
works too, but I actually find commands simpler this way.
* Adding artifacts.
Ok so this is horrible, but this is the only way I found to get past
some errors. The build would break randomly (sometimes it would,
sometimes not, with the same gitlab-ci rules) because of existing files.
The errors would be the following when trying to install dependency
packages with pacman:
> mingw-w64-x86_64-glib2: /mingw64/bin/libglib-2.0-0.dll exists in filesystem
At first I thought it was a bug in Pacman or MSYS2, but on some runners,
I had such warnings at the very start of the runner (note: on some
runners, the warnings would not be displayed even though the final
conflicting files error would still happen at the end of the logs):
> warning: failed to remove mingw64/bin/libglib-2.0-0.dll: Invalid argument
It looks like it might be related to this Gitlab bug where a runner
would fail to clean its environment:
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1839
In any case, the only way I found so far is to manually remove the
conflicting files before installing the packages supposed to install
these. This is completely horrible (and I sure hope it won't come up
again with different files each time) but really the only workaround I
found so far (I think a real solution will have to come from Gitlab code
or from the GNOME admins, not sure what is the exact source of the
problem).
Just an initial test to get a hang of the thing, mostly inspired from
GTK gitlab-ci rules adapted to our build.
All in one job (deps, babl, GEGL, GIMP itself) for now, for simplicity
of debugging. We'll see later to break this into CI sub-jobs.
… to GIMP not text layer rendering in image
Patch was merged n Cairo today, wouhou!
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114
If not mistaken, the fix should then appear in Cairo 1.17.6 or 1.18.0
(whatever comes next). As we are obviously not going to bump the Cairo
dependency so early, let's just add the patch, at the very least to be
used for our official builds. Also this way, we won't forget about this
issue in the future when we need to bump Cairo.
This is a patch for issue #913, the infamous "non-existent floppy drive"
or other unreachable network or unmounted drives. Well at least it
*should* fix the issue, but GLib developers are hoping we could test. So
let's add this in there for our next Windows package.
Nowadays .rs is the extension for the Rust programming language files,
and it's confusing that GIMP is trying to associate with them.
A simple rename of existing .rs images to .ras will allow them to be
opened again.
Note by reviewer: ideally file association should not rely on filename
extension, and should be detected properly (i.e. file "magic"). This way
even extension clash would not be a problem (format would be detected
whatever the extension used). Unfortunately it's apparently not the case
on Windows.
Anyway since nowadays chances to see a Rust code file are likely much
higher than seeing a Sun Raster image file, let's just accept this patch
and drop association of `.rs` on Windows.
Adding 2 temporary patches for our builds:
- gexiv2-mr20.patch: to be applied over GExiv2 0.12.1. This patch is
already contributed upstream so it won't be necessary once GExiv2
0.12.2 is released.
- 0001-Issue-5863-do-not-raise-WARNINGs-on-Exiv2-unsupporte.patch: to be
applied over GIMP master branch itself. It depends on GExiv2 0.12.2 so
I cannot push it to master until we bump GExiv2 minimum requirement
(which can only happen when v0.12.2 is out then available in Debian
testing, as per our dependency rules).
For the time being, while waiting for upstream releases, all we can do
is wait and apply these patches on our own dev builds (because this bug
is annoying and was reported to us quite a few times already).
This should give a nice name to distribution archives so that they are
not all called `artifacts.zip`. Names will better describe their
contents (target OS or source and short commit hash, because for CI
builds, it's important to know which commit is being tested).
Also replace CI_COMMIT_REF_NAME in other artifact names by
CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in
branch names), only the part after the last slash is used for archive
naming.
Finally immediately exits from dependency build with error code (!= 0)
if `crossroad install` command failed.
… the CI.
There are 2 finale steps before finale binary distribution on Windows.
We must compile the GSettings XML schema files and register GdkPixbuf
loaders (for file format support in the GUI).
I used to provide a wrapper to be run inside Windows before first GIMP
run. Never did I realize that I can compile the distributed GSettings
schemas with the native `glib-compile-schemas` (works fine in my tests).
As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do
require the target `gdk-pixbuf-query-loaders` which is unfortunately a
Windows executable. Yet it seems to work fine with Wine, so let's be
done with it in the CI instead of requiring manual steps from testers of
the CI builds. Then a few `sed` calls are enough to make the path in the
produced text file relative instead of absolute (which works fine, again
in my tests at least).
This means that I don't have to distribute the 2 binaries and the DLLs
they depend on anymore. Moreover let's remove the wrapper (but still
generate one which just calls GIMP so that we call it from the tree
root, where it's much less messy).
Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner.
After following all instructions, I encountered weird errors. So
instead, I just make the win32-nightly job depend on win64-nightly and
copy `loaders.cache` from one to another, as it is a
platform-independent text file (as long as we provide the same GdkPixbuf
loaders on both of course, which we do).
The main purpose of these jobs is to only package the strict necessary
for a working GIMP under Windows, i.e. getting rid of all unnecessary
executables, and inspecting binary dependencies recursively to only
package used DLLs.
The dll_link.py script is taken from Siril codebase (see commit a86e82a8
on Siril repository, by FlorianBen). This was a very nice idea, and
makes for much smaller test archive (Siril is also GPLv3 so licensing is
ok for the reuse, also anyway it's just a small independent build
script).
Moreover having it as a separate job allows to have artifacts with only
the finale distribution (artifacts on the build job also have the build
directory and the whole prefix, which we want to keep in order to debug
when needed).
Hopefully I am not missing anything. Siril seems to package more, like
various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if
these are actually necessary. I could run GIMP fine without these in
quick tests, but I guess I'll have to investigate a bit more to figure
this out. That's what nightly builds are for, after all, so hopefully
people will report if we miss some runtime dependencies.
This commit makes sure we can properly run the tests in a headless
environment, i.e. they don't mess with the user's X display or their
session bus. The latter is also needed for parallel tests as they fail
to simultaneously own the same name on the session bus.
Replaced the "xvfb-run" meson option with the "headless" option, which
is more intuitive (and also more correct, since we now also require
`dbus-run-session` to run the tests, not only `xvfb-run`).
Finally, note that we need a version of `xvfb-run` that supports the
`-d` (`--auto-display`) option. The problem with `--auto-servernum`
which is also regularly used, is that it doesn't shut down cleanly,
returning a non-zero exit code, wich makes the test fail.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/5078
libopenexr was installed, but pkg-config was failing because of missing
dependency:
```
$ x86_64-w64-mingw32-pkg-config --modversion OpenEXR
Package IlmBase was not found in the pkg-config search path.
Perhaps you should add the directory containing `IlmBase.pc'
to the PKG_CONFIG_PATH environment variable
Package 'IlmBase', required by 'OpenEXR', not found
```
Looks like there may be a dependency bug in the openexr package in
Msys2. Anyway let's just add ilmbase and get this to be detected
correctly.
Our installer use Msys2 packages when possible. And Msys2 repository
provides version 0.3.9, released on March 2, which contains our patches.
No need for them here anymore, no need to make custom builds.
This is a new feature I implemented in the crossroad cross-compilation
tool. Msys2 repository has more packages and they are more up-to-date
compared to Fedora and Suse cross-built packages (the 2 other available
sources for pre-built Windows packages).
This allows to simplify a lot the dependency preparation for the Windows
CI, and speed things up.
json-c has 2 build systems (autotools and CMake) and it seems their
autotools broke with recent changes. I will report upstream. For the
time being, we may as well switch to CMake build.
Previous OpenBlas patch fixed the crash with Sophos (see reports #3633
and #4246) but created a huge slowdown of startup because of a timeout
change and most likely OpenBLAS being loaded at startup during the
various verifications.
A new patch has been merged upstream to lower this timeout to something
more reasonable. Reporters confirmed GIMP now runs fine (neither crashes
nor very long startups).
See: https://github.com/xianyi/OpenBLAS/pull/2339
Actual patch contributor wants confidentiality to avoid leaking
proprietary information or whatever (I am not sure either what to be
scared of as it's all good and harmless to me, but let's respect the
request). See also #4246 for more details.
A few commands need to be performed the first time for glib to work
properly, and gdk-pixbuf loaders to be found. I add them in a wrapper
script so that it's easy to ask people to test the dev builds (even
though it's not necessary to run these commands each time, but who
cares!).
Let's make sure they are not pulled in as dependency of other packages.
This fixes the Win32 CI build now that we fixed the Pango minimum
requirement in meson files.
Rather than having the whole Win32 cross-build into the 'gimp' stage,
break the dependencies and GIMP-only builds in 2 stages.
Since apparently we need to keep the same structure for the native and
cross build (otherwise we don't get parallel builds; in other words, I
didn't find the possibility to set separate pipelines up), I move babl
and GEGL into the same 'dependencies' stage.
Finally I remove the -base rules extended into actual jobs, except for
`.gimp-base` (this is the only which makes sense as it is actually
common to the meson and autotools build).
It looks like Arch does not have mingw64 cross-compilers in core package
repository. It does have some package in the user repository (AUR), but
I assume that such a repository cannot be deemed as safe.
Anyway I still tried, but apparently these AUR packages have to be built
and when I tried, I got this error:
> ERROR: Running makepkg as root is not allowed as it can cause
> permanent, catastrophic damage to your system.
Anyway it's all a big mess. Then I tried to move the cross-CI to Debian
testing, which is anyway our base compatibility system. Unfortunately I
encountered like what looked like some glibc++ macro problem on some
packages (most likely because the pre-built packages I use are Fedora
ones which likely uses a cross-compiler differently built from the
Debian one).
So in the end, for simplicity, I use a Fedora image, then I am sure to
get a good match between the system cross-compiler and the pre-built
dependencies.
I did not commit on purpose because this is actually to be found in the
official flathub repository for GIMP (the concept being to keep the
stable and nightly manifests as sync-ed as possible) and I thought there
is no need to duplicate data. But since this is apparently confusing
people (cf. !91), let's just push it.
Note that even though this patch is taken from the org.octave.Octave
flatpak package, it is actually slightly different (I tweaked it because
we needed to build even less options from SuiteSpace than they do
apparently).
Several of our own translations of the Windows installer are unused
because Inno Setup corresponding translations are marked "unofficial".
This mostly means that the language files for these are probably old and
unmaintained, hence outdated. And these files are not bundled together
with Inno Setup release (though still hosted in their repo).
Nevertheless it doesn't make sense that we would just waste the work of
our translators here. Maybe Inno Setup localization is not complete, so
what? At best it could even encourage translators to contribute upstream
to Inno Setup. Let's just enable all our current localizations of the
installer and see how it goes!
Anyway Python deps does not work yet on the master build. That's
unneeded to build nightlies with Python support. Let's drop it for now
and add it back later when we will make it work.
This breaks the flatpak tests at the end when we prepared a future
<release> appdata tag. For released version, we must not do this, but
for nightlies, it doesn't matter.
Anders Jonsson