This style mimics the color scheme used by Win32 applications since Vista (and
still used in Win11). The all grey scheme ended in XP. Let's move on.
But we will keep the actual window size and without being able to resize since
these two Inno features (WizardSizePercent and WizardResizable) are broken.
(The progress bar was changed too to conform with the defaults and uninstaller)
Now, the installer files match the meson config.h naming:
'gimp_version', 'gimp_app_version' and 'gimp_api_version'.
"devel" was replaced by meson 'gimp_unstable' too.
util_version was dropped since it lost its utility.
1) Right now, MS Partner Center doesn't tell us if the .pdb bunbled as .appxsym
are fine and we only have "Unknow" dumps in the Health page from MS Par. Cen.
My theory, according to my tests with 'SymChk', 'PDBCopy' and 'llvm-pdbutil',
is that this is happening because .pdb from clang or gcc are not "perfect", but
I really have no proof to afirm this, since Partner Center tell us nothing
about them, and we don't even know if the .appxsym were uploaded to begin with.
---
2) The compiler can't generate DWARF (.debug*) symbols when generating .pdb,
which breaks debugging in DrMingw and even lldb according to my tests.
(This is not a fault of the .pdb format but a circumstance: our debuggers
only support DWARF, which is the format already used by MSYS2 packages)
---
So, the .pdb will return probably only in the potential vcpkg transition.
Previous changes broken local building courtesy and probably DirectInput too.
Noticed that the universal variables can not work in some contexts, fixed.
Also, done some little cleanups.
This make them easier to understand and to run local, as we do with native ones
(They can't be run local yet, further changes will try to acomplish this a bit)
* Since the appimage is for testing purposes, let's use system 'libc'
* Hardcode python path since the wildcard wasn't expanding misteriously
* Improve system theme recognition making way simpler
Port all plug-ins to retrieve the layers
directly from the image rather than
having them passed in. This resolves some
issues with introspection and sets the
foundation for future API work.
The move to Clang in 85ed2847 didn't take into account caching,
Now, this is fixed or, better saying, reintroduced(?): e545116b
Also, flatpak-builder output was confined to the .log file to make
possible checking the end of the CI output, which was being cut.
The wrapper, like in native artifact, exists just for avoid searching the exe.
But, if the user wanted, wasn't possible to execute gimp-*.exe directly since
the wrapper was needed to generate loaders.cache. Now, loaders.cache are built.
This improves the gimp.cmd wrapper wording a bit to not need the README
anymore. Our dev site was improved some time ago to clarify this:
the Windows builds aren't not incomplete if run correctly (under MSYS2)
Also, add cleanup commands to make the .typelib wizardy less invasive.
Without this, Partner Center refuses the .MSIX by not matching the
entry Identity and DisplayName (which isn't the same as the stable).
Also, rework the naming of the .msix's to be more Microsoft-ish
This commit is mostly a little cleanup:
- Reduce redundancy in Local compatibility layer regarding build commands,
which partily reverts !1171 regarding buggy "ninja && ninja install"
- Reduce redundancy of some variables (MSYS_PREFIX and GIMP_DISTRIB)
- Remove manual QOI install since MSYS2 granted a exception in the win32 drop
This commit also reverts 7cca69cd, a fix from the autotools era that isn't
actually needed according to my tests in CI.
Partially reverts af79bbe0 (regarding .debug "extraction" in cross builds)
Now, we call the split debug script from the main bundling script, which makes
similar to our macOS .app bundling script. This cleans a bit of code in .yml
and make things clearer to the mere mortals in the scripts.
Native arm64 and x64 TWAIN binaries are not built anymore. No need to
discard at dist time what doesn't exist. (32-bit TWAIN not affected)
Also, start to using our own ARM64 runners to do the dist. This is more
reliable since the shared x64 runners can (and indeed) cause long queue.
They were generating a distracting output in CLANG* shells, as noted by
@lillolollo in a comment from MR: Infrastructure/gimp-web-devel!65
In the process, make AppImage and Windows (native) scripts use these
variables, without hardcoding the same variables from .yml anymore.
Creating a temporary config directory for the in-build GIMP (run as a tool or
for unit-testing) is not done as a build target anymore, but in the
in-build-gimp.sh script as a unique temp directory, then cleaned out on exit.
This has a few advantages:
- It is properly cleaned out once the build ends (instead of leaving a full
config dir as trash inside the build dir).
- It is not reused from one build to another (with risk of carrying bugs and
issues over).
- Every use of the in-build GIMP will have its own config directory, and in
particular when they are called in parallel.
As a side update, make sure that all `gimp_exe` runs depend on
`gimp_exe_depends`.
This is recommended by Microsoft for "*nix apps" and adding it to the
.exe manifest will avoid disparity between MSIX and other versions
(e.g. CI crossbuilds and CI native builds/installer/local builds).
Bruno note: This commit was repurposed after ad132ad0.
---
For some reason, on the Windows/Aarch64 runners only, submodule updates fails
with:
> + git submodule update --init
> From https://gitlab.gnome.org/GNOME/gimp-data
> * branch d1041a4d97871c85538938872d0ace69d2fc44c2 -> FETCH_HEAD
> error: Your local changes to the following files would be overwritten by checkout:
> images/README.md
> images/logo/meson.build
> images/meson.build
The big question was: why are there edits to begin with? This is supposed to be
a brand new clone!
After a bit of investigation, it turns out that the whole files have incorrect
EOL endings (a `git diff` returns every possible lines in the whole
repositories, but `git diff --ignore-cr-at-eol` returns nothing). It looks like
this breaks the submodule update.
Attribute uap4:ShellNewFileName is meant as a template file to be copied when
someone initiate the Shell "New" command (via the Explorer context menu).
Most of the work in this commit is by @Jehan.
These icons are used only by the .msix (MS Store) distribution of GIMP.
Some legacy icons are used only by Windows 10 and need to have smaller logo
than full image dimensions, so let's not use colorsvg2png. We just pass the
dimensions to use by configuring variants of the same base script.
The new dist job can produce two artifacts: a *.msixupload file
ready for submission and/or a *.msixbundle only for testing.
See the commit about the script for more details.
This makes possible to debug with DIA SDK, if wanted by the developer.
Also, this is needed to create .appxsym files for MS Store debugging.
Ideally meson should be able to install for us, but apparently it doesn't.
See https://github.com/mesonbuild/meson/issues/12977
Adds PowerShell script and proper manifest for making .msixupload
(only for releases) and/or .msixbundle (always, for testing).
As authorized by Jehan, 32-bit willn't be supported. The reasons are:
1. 32-bit is going to die when WIA plug-in is done. This can hurt reviews
2. 32-bit is being restricted in ARM64 version. This causes disparity
3. 32-bit is generating a big footprint. "This is bad for the environment"
To be clear: we are discarding most of 32-bit artifact (see point 1)
and what could not (TWAIN for x64 only, point 2) almost doubles .msix.
There is one small circumstantial reason too:
4. 32-bit wouldn't have .pdb even after GCC 14 because bins have same name
as x64, and MS don't allow multiarch debug symbols in the same .appxsym
As hinted in d09a2a6f
We now use the word 'bundle' to signify "program files in the same prefix"
(e.g. .appimage, .zip, .app). This is in line with our source and dev-docs
(just take a search in the repo). So, appimage and windows scripts changed.
The word 'package' normally means "program files distributed for install in
the same prefix or not" (e.g. .deb, .msi, .dmg). This is in line with CMake
naming of some commands, but meson prefers to call 'dist', which we use more.
So, this partly reverts some things of GNOME/gimp!1171 and reinforce others
for even more "rationality" in the overall build structure of GIMP.
AppImage is pretty fast to make, like the win crossbuild; and portable,
being very appropriate to do quick tests on Linux when pushing to git.
The overall organization of Debian jobs was changed to take advantage
of this and make things less complicated (but less clear at first sight).
I reinforce that this was the most efficent way to make the AppImage.
This stage was introduced in 076e4d68 and it fulfilled well its purpose. But
the side effects were: more (sometimes slow) uploading and downloading of
packages and artifacts. Even if we have caching, this is far from ideal.
Now, the so-called "packaging" jobs were moved inside in the "build" jobs.
The advantages are: just one pacman install (ideally cached from deps job);
direct packaging without waiting for upload/download; and less confusion,
since "packaging" naming was implying that the .zips are somewhat official,
which isn't totally true, and sometimes overlaps the dist/deploy concept.
---
Also, the flatpak job now uses config.h instead of triggering a GIMP build.
In other words, I'm reverting part of my work in some old commits.
This isn't directly related with #10922 and does NOT affect 32-bit support.
After talk with @Jehan, author of 'crossroad' and main dev of crossbuilds,
we decided that the x86 crossroad builds can be dropped by these reasons:
1) 32-bit crossbuilds weren't being built. They are used since c8ec0ae7 but
after the native 32-bit builds they ended in a state that they are the only
pipeline that isn't automatically triggered in any way, a complete limbo.
2) 32-bit crossbuilds weren't being autonomous. They are not working fine
with wine32 so the win-x64-cross artifact is a 'need' and now debian-x64,
so we were spending way more time fixing than using the 32-bit cross jobs
(sometimes the 32-bit cross jobs are just broken and we even noticed).
We have other jobs not autonomous but they don't have additional bugs
like not being able to build with .mng and .wmf (32-bit cross only bugs).
---
The x64 crossbuilds will continue to be supported. They are very useful to
develop on Linux, and test MRs on Windows. I'm an assiduous user of them :)
This commit uses definitions and references to reduce repetition of CI code.
Some people (like the GitLab devs?) prefer (almost imposes) this to be done in
multiple .yml's using 'worfklow:' but this makes the CI way more complicated
and very slow to read. So, let's just keep simple in one human readable file.
---
Other changes are:
- The custom native arch pipelines now they always generate a .zip package.
This helps to ensure that everything is in place and facilitate testing;
- The pacman update (-Syyuu) was removed since it is auto done by runners;
- The ccache config was moved to .yml. This does NOT affect local builds
since meson saves ccache by default for user in '%LocalAppData%/ccache'.
These commits introduced sensible drawbacks in our CI file organization.
Some of them I already commented in the MR but was "ignored" back then
probably due to the complexity of the MR. So, the let's revert:
- Unecessary repetition of libomp installation (4 times, now 1)
- Unecessary repetition of submodule initialization (6 times, now 4)
- Creation of new variables in the hope of more clarity. But,
they aren't consistent with the gimp-web-devel instructions
nor with other systems variables. This is terrible to undestand.
Please, let's not reinvent the wheel since this is a bad example to
packagers, since they tends to isolation and overly-engineering.
Also, made some little adjustments that I should have done in previous MR.
---
This MR was splitted. Even more simplification will be done in the future.
- With last commit, the Windows installer pipeline doesn't depend on
"gimp-debian-x64" job anymore since a native Windows build is now able to run
GIMP (or gimp-console) as a build-time tool as well. It makes the Windows
installer pipeline (and full custom native builds) self-sufficient.
- On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require
"gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in
order to generate some image data (such as the splash image, and probably soon
logo or icons, etc.). See gimp-data@5a03c71.
- Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of
"image-debian-x64" for all Debian as well as the cross-compilation jobs. They
are all based on the same Debian image (it was debian:bookworm for native
Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork
for all) and it's just a few more packages (cross-compilation C and C++
toolchains) for the cross-builds. Moreover now the cross-builds also need the
native GIMP binary around, therefore native dependencies are needed as well.
It makes sense to factorize all 3 images into 1.
- Make sure we don't build bindings when cross-compiling since these won't work
in this case.
- Splash images will now be stored from gimp-data.
- The installer BMP image scripts also move in the same time.
- We don't need devel and non-devel variants of the BMP images in InnoSetup
scripts since the images are generated from the actual splash.
Meson subprojects just have too many problems and limitations and I can foresee
the maintenance headache and the future incoming false-positive bug reports if
we start using meson subprojects.
Comparing to the simplicity of git submodule which also has much better
notifications to help people understand when the submodule is not in sync and
how to remedy to it.
See commit gimp-data@c364adb explaining the main reasons in detail.
In our efforts to use Clang, now the nightly (in fact weekly) flatpak
is built with Clang too, not only GIMP but also the dependencies.
* However, not aalib. We welcome fixes regarding this cursed lib.
Additionally, updated some build options from some deps.
This commit unites two scripts (.sh + .bat) in one .ps1. PS was choosed, since:
1) We don't need MSYS2 to distribute with Inno at first. Now, who wants to
just distribute GIMP can do it easier natively without a separate environ.
2) PS is actually pretty solid and have a good number of cmdlets, unlike the
ancient CMD, which barely supported more than 9 parameters in .bat files.
Consequently, some redundant variable checks have been removed from the .ISS.
Also, changes the name of the job and script for better consistency with the
upcoming MS Store job.
The 'Docker' draft of GIMP was introduced in 09/04/2017 and then died ONE day
after, mostly because of "bad" timing (few years later we moved to GitLab CI).
Similar (in fact, even worse) than 'jhbuild' folder, update it to keep the
current development status is so hard that it is equal to do it from scratch.
So it is reasonable to delete it anyway.
These files are not deleted when the Unstable (GIMP 2.99) or Stable (GIMP 3)
version are installed because the root is different. So, they can be removed.
It was only used for the gimp-win-a64 job and was coming from MSYS2 repository
which already dropped it:
a98352b2ba
The first patch is still needed as the upstream fix is meant to appear in clang
18 according to bug report, yet our CI still uses clang 17.0.6. See:
https://github.com/llvm/llvm-project/issues/51286
Since !1171 we can use the CI scripts locally, but the initial implementation,
after some commits, revealed to be troublesome. So, now reworked to be simple.
As noted by Jehan, the way of defining the (many) GIMP versions can change.
So, let's take the GIMP version directly from the generated config.h file.
Also, changes the declaration of some variables to conform with "best pratices".
This list is referenced in the gimp-web-devel site, and my initial
implementation, in terms of ease to use, was a throwback.
Also, make the CI code more simple without changing the list file.
The rest of the time, we want to use HEAD of their main branches.
The last ctx update seem to have broken the CI build on Windows. While we'll
have to fix this, let's do this after we release GIMP.
Anyway we obviously don't want to use unstable code for actual point releases,
so it's a good thing that this made me think of adding such rules.
Here, the instructions was hard to find in the middle of maintainer stuff.
Also, be able to build GIMP without dev-oriented distros is something very
desirable, and the gimp-web-devel is the suited place fot it.
Aaaargh! I think this was the main issue which would explain why the problem was
mostly happening on the packaging job. In this job, we were still consistently
calling `pacman --noconfirm -Suy` (i.e.g "Synchronizing package databases")
which we had stopped to do for the CI builds as that was highly increasing
chances of locking pacman's process.
Fixing a case where the script continued after a failed `ninja`. After further
testing on how `set -e` works, it looks like a toplevel `false && true` command
will fail the script (which is what we want), but it won't when inside an `if`
block!
Breaking it down into 2 separate calls fail the script correctly though. So
let's do this.
MSYS2 pacman gets randomly stuck on Windows/Aarch64. The actual issue is still
being investigated by upstream projects, though anyway it's bad for us right
now, to the point that there are discussions to remove Aarch64 support from the
Windows installer (whereas it just got added recently!) in #10729.
This is an attempt to a workaround. Instead of getting stuck forever and waiting
until the whole job times out (per Gitlab CI settings), I time-out (after 3
minutes) the pacman command within our script and try again, up to 2 more times.
Hopefully one of the calls would succeed.
I also send a SIGKILL through the timeout (though I have no idea how signals
translate to Windows processes) and run again taskkill after this, which may
seem overkill. Interestingly I get output for both, which seems to indicate that
the kill succeeds in both cases (because of several processes?).
Anyway clearly it's a bit of random code not completely understood, but the
inability to test this all locally clearly doesn't help so it's good enough for
the time being.
See: https://github.com/msys2/MSYS2-packages/issues/4340
While this is the job of `set -e`, putting parts of the script in shell
functions hid error returns in the build-deps-msys2 script.
Cf. #10729.
For the build-gimp-crossroad script, let's just add `set -e`.
Cf. #10725.
The list contains, in addition to the GIMP deps, all babl and GEGL deps.
So, let's use it.
Also, nothing new under the sun. We already use a unique list on the
Windows build instruction page (for stable branch) and do the same to
Debian image job.
As suggested by Jehan, the manifest will be configured by meson.
Of course, for CI compliance, this pushes the job to a further stage:
'packaging', which is what Flatpak is about, after all.
The distribution job name has also been changed, because when Store job
is merged, this will be the new nomenclature of the distribution jobs,
which was not changed since !1171 by lack of time.
There is no point in keeping .patches in our source since we aren't applying
them and there are "backup" MRs in GTK: GNOME/gtk!3275 and GNOME/gtk!4432.
Now, the script reads the major.minor version automatically from the main
meson.build file, reducing maintenance work, which is already especially
high regarding flatpak because of the natural hashes updates etc.
Also, a small organization made to make the code more humanly readable.
As consensus on Windows contributors, it is more useful for most users
the generation of the desktop shortcut by default.
Now, users who don't want it should uncheck the option in custom install
or manually delete the shortcut after a full install.
The 'jhbuild' build of GIMP (Windows only) was added in 2013 and then maintained
by only one contributor (it even offered unnoficial nightly builds) until 2017,
when it never received a new jhbuild-specific commit again.
After so long, update it to keep up with current development status is quite hard,
so it is reasonable to remove this already dead version of GIMP.
* Fixes an ARM .patch that stop to working after !1171, causing job fail
* Changes the logic of system upgrade (pacman -Syyuu) to be less redundant
This also improves consistency with the Debian jobs
- Fix "no icons" errors generating loaders.cache with .cmd (CI-Cross).
! This is a sub-optimal fix, but it's better than a useless build.
- Fix "no interpreter" errors generating .interp with Meson (CI-Native)
and generating .interp and copying .typelib with .cmd (Local-Native).
! This is a sub-optimal fix to Local-Native, but plug-ins will work.
- Fix "no iso" error copying iso_639.xml with Meson (Local-Native).
The Inno installer scripts contents (only 3 files: files, gimp3264 and
32on64) and filenames have been organized, making them much easier to
read, and slightly less hardcoded so less prone to being misunderstood
and pervasively receiving packaging stuff.
Just to be clear, one more time: the Inno installer (or future MSIX)
scripts never should be the center of attention. This "installcentrism"
caused a domino effect of partially "abandoning" the packaging, build.sh
and the meson scripts, which explains the existence of this MR...
(Some things still hardcoded since wildcards in Inno are very limited.
Also, the rational ordering principles of this MR were not applied since
these scripts are heavily based on the x86 .zip package and changing the
order of things here, according to my tests, breaks things quite easily)
The CI crossbuild job now use the same main script (and the same
sub-scripts of linking and debug generation) of the native CI for
packaging. These unified scripts greatly facilitates maintenance.
The crossbuild deps script is now more consistent in relation to the
native one. As this is polished, the cross one is now polished too.
A crossroad gimp build script was created with a more clear code.
Also, finally make the script for packaging only, removing build step
stuff that shoudn't be here (glib-schemas generation) since this causes
disparity with the Local native build; and adding some packaging
decisions that shoudn't be in the installer scripts (eg. specific
folders of ghostscript, glib; no share/themes), which also facillitates
INNO (and future MSIX) maintenance.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
Also, remove some redundacy on the code for better maintenance.
Now, we have only ONE list applicable for build-deps-crossroad.sh,
build-gimp-msys2.sh and package-gimp-msys2.sh, instead of hardcoding
3 times. This unified list greatly facilitates maintenance.
Debian changes:
- Since autotools has gone, we don't need to specify 'meson' in the
debian job and others.
- The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and
the meson sintax of Debian jobs was also updated.
Windows changes:
- Then, clarify that the win64-nightly and win32-nightly jobs are, in
fact, in the 'packaging' step, since we don't really "distribute" GIMP
in .zip and the commands are almost the same of the packaging .SH
script, without scripted optimizations for Inno Installer (or future
.MSIX), crucial for distribution.
- We don't need to specify "native" sufix in any build since they are
the rule and cross builds are the exception.
General changes:
- The job names was changed to be more consistent and in accordance
with the folders present in the artifacts.
- The 'nightly' sufix was removed from the Inno Windows Installer job
and others, since this doesn't reflect the real build frequency.
- The scripts filenames are altered to stay "in order". This is not
essential but ultra convenient since it is easy to view and search.
(The -uni suffix is explained in a further commit)
- All artifacts names now have the commit to avoid apparently duplicate
files when downloading same step artifacts from different projects.
- Finally, rearrange the order of jobs rationally: first the OSes and
archs (from the most free and modern to the most closed and legacy),
then the stages (from 'prepare' to 'analysis'), ending with the
frequency of jobs (from the most frequent, called at each push, to
the least/weekly).
Overall, this changes, although difficult to review at the first
sight, will avoid in the future quite "dumb" issues like:
GNOME/gimp#10195
This is in part a port of commit 6f921b27bb from gimp-2-10 branch, except that I
could not easily cherry-pick because too much had changed already in the master
branch.
There are also a bunch of additional changes in some other glue scripts.
Also some rules which were in the 2.10 branch don't apply to the main one, such
as Python being copied from the x86 binaries, since clang-aarch64 has Python3
(unlike Python2).
See discussion in #9170 and !1091. It looks like this soon won't be a problem
with a recent llvm-windres (which is now patched). But until then, let's patch
upstream GIMP but only for this build.
Note: the additional `rm` call was done for this error:
> + mv _install-arm64 /home/SYSTEM
> mv: cannot move '_install-arm64' to '/home/SYSTEM/_install-arm64': Directory not empty
I guess the home directory is not properly wiped-out between runs, which is not
a huge problem as long as the runner is private to our project. Let's clean
things ourselves.
This localization was added recently but it was not in the installer scripts.
Discovered with unit testing: meson test gimp:build / windows-installer-langs
Organizing sub-dependencies into modules helps. Later if for instance we need to
remove or change OpenEXR, we know that they are related and that Imath can be
removed if we remove OpenEXR.
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.