There is no reason (advantage) to emulate 32-bit GIMP on x64 or arm64 OS and
3.2.0 will be the last version to support it. Let's clean up some things then.
Partially reverts d07aa8f5 and 73040bce
Just some little improvements:
- Removes --keep-build-dirs to ensure we don't pass build files of modules
(we keep using it for babl and gegl to get the meson-log.txt file)
- Changes ORA build file to _build-cached-$RUNNER.tar.zst for more clarity
(and change back to _build-$RUNNER the final dir passed to the next job)
- Move /build check for the deps jobs (gimp job should just extract)
This reverts 1fcdb724 and 8e6da721, which are inoffensive but inconsistent.
They are added while Jehan's final fix did not landed. Back then, we were
experimenting XZ and other things that we don't use in other parts of the .sh.
So, let's go back to just single tar, since logs are not that big after all.
Both the description, other GEGL filters, and other programs
list Hue-Saturation filter settings in Hue/Saturation/Lightness
order, rather than Hue/Lightness/Saturation order.
This patch makes the ordering consistent.
Apparently that is the reason why the Aarch64 jobs are rebuilding
everything, though I'm not sure to understand why (can gimp-flatpak job
grab the deps-flatpak artifacts from the wrong architecture?).
… delete build/ contents.
We were hitting an error on CI:
> ERROR: Uploading artifacts as "archive" to coordinator... 413 Request Entity Too Large […]
Because the .flatpak-builder/ tarball was huge.
After further testing, it turned out that this is a per-file limit,
since simply not compressing the folder and passing it as artifacts
worked, except this time, we were hitting permission issues: artifacts
end up as root on successive jobs, whereas the CI job runs unprivileged
as a "build" user, which doesn't fly with flatpak-builder still needing
to work and touch previous files.
So I'm doing some in-between by compressing sub-folders (the real
advantage is not the compression part, but the archiving in tar, which
preserves ownership and permissions).
Note that while this kinda partly worked, .flatpak-builder/build/ was
still huge, even when compressing .flatpak-builder/build/* contents in
further individual archives. So I just simply drop this data as it's not
needed at all for flatpak-builder caching (cache/ subfolder is).
See also discussions in #2404.
When we fail to read enough bytes when reading uncompressed psp
channels, return with an error.
The error message was copied from the PSD reader so this should not
be affected by the string freeze.
We were not checking whether channel types were valid for grayscale
images. Using a blue color channel caused an invalid computation of
the offset which could cause us to access an invalid memory location.
Now we separate RGB from non-RGB images when checking which channels
are valid, and if not return with an error.
