Argh! So it turns out that .publish_nightly template uses already an
only: key so we cannot use rules: (on the other hand I guess using only:
ourselves is alright and concatenate ours and the one in the template).
Fixes:
> jobs:flatpak-nightly config key may not be used with `rules`: only
This clashes with the usage of "rules:" and is even more useless as it
is about checking success of earlier stages (yet this job doesn't need
to wait for any other job).
Fixes CI error:
> jobs:flatpak config key may not be used with `rules`: when
To get a nightly flatpak, GNOME project offers a CI template[0] that can
be extended instead of having to define everything from scratch.
At the core is the "flatpak" job that tries to build the flatpak. If the
build finishes succesfully, the result should be available as a CI
artifact as a flatpak bundle. The app id is the same as on Flathub.
Another part is the "flatpak-nightly" job that publishes the flatpak if
the build succeeded. Without this job, the bundle stays only temporarily.
This job can and should only be run on the "master" branch. This jobs is
started only when the "flatpak" job finishes successfully.
Both jobs can be triggered only thorugh schedules[1]. To finish the
flatpak nightlies setup, a schedule needs to be set.
[0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak
[1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
- 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.
The logs are just too long for gitlab and ends with:
> Job's log exceeded limit of 4194304 bytes.
This doesn't prevent the job from actually finish successfully. Yet the
day when we will have a build issue, we won't have a way to debug if it
happens close to the end of the installer creation. So let's redirect
both stderr and stdout to a log file and include it in the artifacts.
Actually most of the build code was already there but the initial meson
contributor commented the Legacy icon theme out. Not sure why.
I only had to fix a few icon names, which changed into Freedesktop
standard names after commit 1e5cf10585. Other than this, existing meson
build rules seem to work fine AFAICS.
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.
Unlike what I said in my previous commit, it still just takes too long
to build the installer, whether I move some of the substeps around or
whether I increase the max duration. So rather than increasing max
duration a lot more, let's just add an intermediate stage.
The last stage (installer creation) takes just too much time, and it
exceeded the max execution time (80 min) in my last test build. Instead
of increasing this max execution time, let's move the run of
package-gimp-msys2.sh script in the same step as the build one. Maybe
adding an intermediate stage would have been better conceptually, but
every stage also takes some preparation and finalization time (setting
up the runner, loading, cleaning the uploading the cache, etc.) and our
installer pipeline is already long enough.
So let's just go like this for now.
As a side effect, the last job's log limit was exceeded too since I
added the Python option, which should hopefully also be fixed by moving
steps out of the installer job.
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.
In Linux, I never paid attention to it because it was already working as
expected (i.e. Ctrl-n followed by Enter for instance would directly
create the image), but when testing GIMP on Windows for the installer,
these last few days, I realized that hitting Enter when focus was on the
dimension entries was doing nothing. Having to move the pointer to click
a button on Windows was frustrating. So let's make OK the official
"default response" directive for this dialog.
- 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.
Argh! My previous commit logics was right, but should have been applied
to the Windows builds (where the issue happens). That's what happens
when I hack too late at night!
This is not a fix, only a workaround for the CI to at least not fail
randomly, for the time being.
Basically since meson is running parallel jobs, even when the build
fails because git-version.h doesn't exist yet, while a depending file is
being built, it will still be built immediately after, despite the
failure. As a consequence, re-running `ninja` immediately after (i.e.
running `ninja || ninja`) will make the second build work. If it doesn't
then it's another issue which has to be fixed. But at least we work
around this known race condition in the meson build for the time being.
It's very ugly, but better than current situation. :-/
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.
GIF export was not taking into account that there can be
both grayscale layers with and without alpha in an image.
We make sure that the GEGL buffer knows the type of
drawable for the current layer.
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.
To this day, the windows-installer option only creates the language
files for the installer. There is just no reason to forbid building them
(hence testing the option works) on non-Windows platforms. In autotools,
it already works fine on all platforms.
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.
We were loading 16-bit per sample SGI images as 8-bit
integer images even though we have had support for
16-bit integer for a long time now.
Changed to use 16-bit integer encoding now. Saw
this request a while ago on the gimp user mailing list.
Jehan