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.
This will set the default color profile directory under its path inside
the sandbox and therefore fix issue #15 of our flathub repo.
While I am at it, I do some cleaning and remove --enable-vector-icons
since this is now the default.
This is in particular necessary because permission in manifest
--filesystem=/usr/share/color/icc does not work as expected to mount the
system repository inside the sandbox at the same path.
See commit 8f3bf7b175d44118f9146e31191fcb7558614b31 from flathub
repository for org.gimp.GIMP.
Let's go with a simpler manifest since soon it will be built on a better
machine (our CI server) and to make scripts simpler.
Note that I also removed the old webkitgtk dependency, but actually I
realize the GNOME runtime does not have the new dependency as well,
since the runtime actually has a webkit2gtk-4.0 instead. We'll have to
look into this.
Jehan