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.
Jan Tojnar