Rebase on freedesktop platform

[ryonakano]

Fixes #219

• Rebase on freedesktop platform 25.08 instead of GNOME platform 49
• Install missing modules in freedesktop platform
  • vala (and its dependency graphviz)
  • libgee
  • gtk4
  • libadwaita
• Install sassc and libsass before libadwaita that also requires them
• Install pygobject and its dependency, pycairo
  • Because it's probably included in GNOME Flatpak Platform

How to Test

$ meson setup build --prefix=/usr
$ flatpak-builder --user --force-clean --install-deps-from=flathub --ccache --repo=elementary builddir ./build/io.elementary.Sdk.json
$ flatpak build-bundle --runtime elementary platform.flatpak runtime/io.elementary.Platform/aarch64/daily
$ flatpak build-bundle --runtime elementary sdk.flatpak runtime/io.elementary.Sdk/aarch64/daily
$ flatpak install --user platform.flatpak
$ flatpak install --user sdk.flatpak

[ryonakano]

OK, it seems working as expected.

An app built on Daily runtime of latest main:

2026-03-14.20.50.04.mov

and this branch:

2026-03-14.20.53.32.mov

[ryonakano]

@danirabbit Hi, I'd like to hear your opinion here.

This PR does fix the big cursor issue on OS 8 at least with Reco as seen in the above screencasts. However, I have the following concern. Which route do you think we should go?

My concern: Some apps might require newer GTK versions that reproduces the issue

As far as I tested it's GTK 4.18.6 that is the last version that does not reproduce the big cursor issue on OS 8. And it's libadwaita 1.7.x that is the last version that can build with GTK 4.18.6.

However, some of GNOME apps that we package requires newer versions:

• Papers 50.1 requires GTK >= 4.17.1 (met) and libadwaita >= 1.8.alpha (unmet) ¹
• Web 50.4 requires GTK >= 4.21.0 (unmet) and libadwaita >= 1.8.alpha (unmet) ²

So, I have a concern that we need to stack on older version of these apps until we drop support for OS 8 completely, which could be a long time. Alternatively we can build and install newer GTK and libadwaita that these apps require in each manifest file, but that means the big cursor issue still occurs with these apps on OS 8 even if these manifests are based on this PR, which makes me feel this PR a bit useless.

Possible routes

• A. Discard this PR and tolerate the big cursor issue on OS 8. Our platform is still based on the GNOME one
• B. Keep this PR. Rebase on fd.o platform with older GTK and libadwaita versions
• C. Rebase on fd.o platform but with latest GTK and libadwaita versions
  • This is a completely different motivation. I thought there is another motivation, which we still might want to consider, is that migrating to fd.o platform introduces its longer support term than the GNOME one for us (2 years v.s. 1 year)

Footnotes

1. https://github.com/GNOME/papers/blob/50.1/meson.build#L133-L134 ↩

2. https://github.com/GNOME/epiphany/blob/50.4/meson.build#L74-L75 ↩

[danirabbit]

@ryonakano Maybe we can hold onto the older GTK just until we release OS 9, so that way we can at least give people a way to update and avoid the bug?

On the other hand, all the GNOME apps from Flathub now have this bug and there's nothing we can do to fix it, so maybe we just have to accept it for now? :/

I'm not sure there's a clear winning answer here.

I do think there can be a point to basing on the free desktop platform because like you said we don't have to be tied to the short support window of the GNOME platform and currently I don't think we're doing a good job keeping up with minor releases so we probably can do platform releases more often if the dependency checker bot is alerting about new versions

[ryonakano]

@danirabbit Thank you for your reply. I agree with your comment quoted below.

On the other hand, all the GNOME apps from Flathub now have this bug and there's nothing we can do to fix it, so maybe we just have to accept it for now? :/

The issue is just the cursor looks bigger and nothing else like crash, so I think we can accept it as a known issue for now and wait for being resolved in OS 9.

I do think there can be a point to basing on the free desktop platform because like you said we don't have to be tied to the short support window of the GNOME platform and currently I don't think we're doing a good job keeping up with minor releases so we probably can do platform releases more often if the dependency checker bot is alerting about new versions

Yes, I agree that we may want to rebase on fd.o platform for longer support term, but probably in flatpak-platform 9? I think we may want to keep basing on GNOME platform for now, in flatpak-platform 8.3, so that things won't break too much for developers when bumping from 8.2.