graphics/gimp{,-app},graphics/gegl,x11/babl: update to 2.10.38, 0.4.48, 0.1.108

[vvd]

Summary

https://www.gimp.org/news/2024/05/05/gimp-2-10-38-released/
https://gitlab.gnome.org/GNOME/gimp/-/blob/gimp-2-10/NEWS
https://www.gegl.org/release-notes.html
https://www.gegl.org/babl/

Tested build and run in poudriere and live system 13.3-p2 amd64.

This update also fix this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278292

[vvd]

PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278789

[diizzy]

All ports should be converted to DISTVERSION as per Porters Handbook

graphics/gegl
Are patch-operations_external_png-load_c and patch-operations_external_tiff-load_c still required?
The OpenMP hack can likely be ripped out by now

x11/babl likely doesn't require libtool, you can probably drop localbase or or at least use localbase:ldflags
SIMD option is only relevant on i386/amd64 (fix) and we can at least always rely on SSE2 on amd64 (requirement).
It would be nice(r) if we could rely on CPUTYPE from the framework

graphics/gimp-app
SIMD option can be retired, we can assume that people what are running gimp aren't using a potato
https://cgit.freebsd.org/ports/tree/graphics/gimp-app/Makefile#n142 - Remove newline
L35 Remove LIB_DEPENDS and replace with \ on the line above
jpeg200 --> JPEG 2000 (https://jpeg.org/jpeg2000/)

[vvd]

In D45094#1028356, @diizzy wrote:

All ports should be converted to DISTVERSION as per Porters Handbook

Ok.

graphics/gegl
Are patch-operations_external_png-load_c and patch-operations_external_tiff-load_c still required?

I'll test.

The OpenMP hack can likely be ripped out by now

- #include <altivec.h>
I don't know and I don't have ppc* for testing.
Base 13.3 have this file: /usr/lib/clang/17/include/altivec.h

x11/babl likely doesn't require libtool,

I saw it, but thought the maintainer had kept it for some purpose unknown to me.

you can probably drop localbase or or at least use localbase:ldflags

Will test.

SIMD option is only relevant on i386/amd64 (fix) and we can at least always rely on SSE2 on amd64 (requirement).

Ok, I'll sort out this option.
What is our low mark for i386 - Pentium 2? If yes then we can use MMX as default for i386.

It would be nice(r) if we could rely on CPUTYPE from the framework

Change default depends on CPUTYPE? But if somebody want to turn it off - he can't.

graphics/gimp-app
SIMD option can be retired, we can assume that people what are running gimp aren't using a potato

It's already ON by default.

https://cgit.freebsd.org/ports/tree/graphics/gimp-app/Makefile#n142 - Remove newline

Ok.

L35 Remove LIB_DEPENDS and replace with \ on the line above

Ok.

jpeg200 --> JPEG 2000 (https://jpeg.org/jpeg2000/)

Do you mean replacing the substring jpeg2000 in the description with JPEG 2000?

Thanks for tips!
portclippy printed several warnings too.
I wanted to tidy up these ports with separate commits after updating them.

[vvd]

Removed patch-operations_external_png-load_c and patch-operations_external_tiff-load_c - build fine without both.

About Altivec:
https://cgit.freebsd.org/ports/commit/graphics/gegl?id=7615d55b290a801f7bee689349a4dc5b3e760acf
https://cgit.freebsd.org/ports/commit/graphics/gegl?id=9105f6edb2964fd253737a70a63cf7c4a146732e
Almost duplicate, but 1st active with clang only and 2nd always. What is better?
Is it build with GCC 12/13/14 and work?
IMHO, we can sort out this after update.

This update also fix this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278292

[vvd]

Removed graphics/gegl/files/patch-gegl_opencl_cl_platform_h - tested build on powerpc64le (thanks to pkubaj).

[saper_saper.info]

I tried to rebuild the ports updated by this patch and I have trouble supplying enough virtual memory to build babl.

The last step seems to be vapigen invocation that consumes huge amount of memory. Is this normal? How much is enough?

[vvd]

In D45094#1033094, @saper_saper.info wrote:

I tried to rebuild the ports updated by this patch and I have trouble supplying enough virtual memory to build babl.

The last step seems to be vapigen invocation that consumes huge amount of memory. Is this normal? How much is enough?

What is your environment?
Did you test build of old 0.1.106 version in same environment?

I just build 0.1.108 on very weak environments in VirtualBox VMs with FreeBSD 13.3-p2 amd64:

1. 2CPU (Core i7 920@3.1GHz)/2GB RAM/4GB SWAP on host with run nextcloud in apache24 + posgresql;
2. 3CPU (Xeon E5620@2.4GHz)/4GB RAM/4GB SWAP on host with zabbix server + zabbix frontend in apache24 + postgresql.

On both hosts duration of the build was ~1 minute. Memory usage in top during build look same like without build.

[saper_saper.info]

On both hosts duration of the build was ~1 minute. Memory usage in top during build look same like without build.

Thanks for checking this, the problem was ancient vala 0.30 installed on the system without any trace in the package database. So that technically dependency was fulfilled, but it didn't work well.

WIth vala 0.56.16 babl and gegl compiled smoothly. Thank you.

[vvd]

I'll commit it this weekend with maintainer timeout > 2 weeks.