[gtk] Update to 4.22.0

[SunBlack]

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

Patch is from a diff with gtkmm-4.21.1, so can maybe removed with #48980 later

Some notes collected during testing it locally:

• DirectX-Headers is required since GTK 4.19.2, but doesn't work in combination with introspection. Therefore disallow this combination.

  ERROR: can't resolve libraries to shared libraries: dxguid, DirectX-Headers, DirectX-Guids
  

• 19.2 added usage of rsvg_handle_set_stylesheet (librsvg 2.48), but they missed this code in the librsvg 2.40 compatibility code. This was still present in GTK 4.21.4. In GTK 4.21.5 they dropped librsvg.
• atk is already not anymore required since GTK 4.0

[SunBlack]

Requires

Dependency librsvg-2.0 found: NO. Found 2.40.20 but need: '>= 2.48'
Run-time dependency librsvg-2.0 found: NO (tried pkgconfig, framework and cmake)
Dependency librsvg-2.0 found: NO. Found 2.40.20 but need: '>= 2.40.23' ; matched: '< 2.41'
Run-time dependency librsvg-2.0 found: NO (tried pkgconfig, framework and cmake)
Looking for a fallback subproject for the dependency librsvg-2.0
ERROR: Subproject librsvg is buildable: NO

[dg0yt]

This is a known blocker.
Updating librsvg is blocked by its use of rust. #48344 would help.

[SunBlack]

Got a working build locally (just gtk[core]) now with 4.21.5 - but can't edit the PR title due to an GitHub issue 😅

Still draft as I need to review the dependencies due to the big version jump.

[dg0yt]

Please explain.

[SunBlack]

just read the initial post. same for the other comment.

[BillyONeal]

@dg0yt I think @SunBlack is referring to

• DirectX-Headers is required since GTK 4.19.2, but doesn't work in combination with introspection. Therefore disallow this combination.

  ERROR: can't resolve libraries to shared libraries: dxguid, DirectX-Headers, DirectX-Guids
  

[dg0yt]

Yeah, that's what I figured. I did read that in december, and I just didn't recheck yesterday during a cursory look.

What I can say is that gobject-introspection tries to find the actuall DLL names from the actual import libs.
https://github.com/GNOME/gobject-introspection/blob/43ae0b53c23b39b0a700b66a9640c1180b10de00/giscanner/ccompiler.py#L397-L488
I don't know why it fails for these libs: Either the step doesn't find the import libs, or it fails to determine the DLL names. (Does DirectX-Headers come with libs?)

I don't know if this implies a permanent "unsupported by upstream", but at least it seems untested.

[SunBlack]

Only DirectX-Headers.lib & DirectX-Guids.lib. There exists a dxguids.h, but nothing only called dxguid (even not in the build directory of directx-headers). I think he search for it due to this.

I don't know if this implies a permanent "unsupported by upstream", but at least it seems untested.

I think this too. And this is just an optional feature I think it is okay to disable it for windows, as long no one request it explicitly and want spent time in it.

[dg0yt]

Does the include logically replace the using?
If yes, couldn't the patch reflect that, literally.

[dg0yt]

I don't think my question was really answered by the initial post.
What I see now is that this file is a generated source which exists in the gtkmm tarball but not in git. Instead of the original nitpick, my question is now if gtkmm should be update together with gtk here.

[SunBlack]

They changed it here. And yep, gtkmm will get an update after via #48980.

[BillyONeal]

I would like to see dg0yt's feedback responded to.

[SunBlack]

Just a small think: 4.21.5 is no stable version, but 4.20.3 would require to patch the librsvg issue. Therefore wait for 4.22?

[BillyONeal]

Just a small think: 4.21.5 is no stable version, but 4.20.3 would require to patch the librsvg issue. Therefore wait for 4.22?

I think that's up to you since you did the work :)

[BillyONeal]

Just a small think: 4.21.5 is no stable version, but 4.20.3 would require to patch the librsvg issue. Therefore wait for 4.22?

Since I'm not sure if this means you actually want me to merge this or not I'm drafting it but I think this is mergable.

[SunBlack]

Just a small think: 4.21.5 is no stable version, but 4.20.3 would require to patch the librsvg issue. Therefore wait for 4.22?

Since I'm not sure if this means you actually want me to merge this or not I'm drafting it but I think this is mergable.

Sorry, I didn't had time yesterday to check whether patching is easily possible or not. Since the method signature has changed (see 4.19.1 vs 4.19.2 and I don't know whether reverting to the old method will change the behavior, and since the version 4.21.5 looks completely different (the method doesn't even exist there), I would say that the 4.20 release series is out of the question for us. Therefore, I currently see only three options:

• Revert to 4.18.6 (this would allow us to update gtkmm and other gtk dependencies, but not to the latest stable version)
• Use this version (all dependencies can be updated – I just hope that the stables are not based on something that was available in 4.20 but no longer in 4.21).
• Wait for 4.22 (since they don't have a fixed release cycle, I don't know how long we'll have to wait)

I would leave the decision to the maintainers here as to whether you want to have a devel version in there (which is the case for some ports, but as far as I know is not the preferred version) and if not, whether other ports should be updated to the non-latest version so that we have the appropriate version for GTK4, even if it is not the latest version.

[BillyONeal]

Thanks for the update!