feat: add gnome-desktop variant

[gagath]

This reuses the existing work for the XFCE variant, the difference is that task-gnome-desktop was not manually pruned down as I cannot think of specific packages to remove from it yet. GNOME is not known for being small on disk in the first place.

Due to this, the image size and the debos --scratchsize need to be bumped to 7GiB. The resulting root partition in disk-sdcard.img has 529MiB free space left out of 5.4 GiB.

The generated image was successfully boot-tested on qemu and a Thinkpad T14s. GDM asks for a password change and then the GNOME desktop can be used as expected.

[ndechesne]

how about we start from gnome-core instead of the full desktop?

[gagath]

Makes sense.

I see that task-gnome-desktop depends on gnome-core and only recommends gnome. The package even says that it is to allow it to fit on a CD-ROM. So I will retry by replacing this section with gnome-core instead of the full task-gnome-desktop.

[lool]

Both variants can be selected though :-)

[gagath]

Yes I know… I did not have the courage to consider the case when both are selected by a funny user. The image creation may fail in the first place due to a lack of space for installing both the GNOME and XFCE desktops though. I will see what can be done in the templating language, we should probably bail out if both are selected.

[obbardc]

you can do something like:

{{ if eq $architecture "amd64" }}
      - linux-image-amd64/trixie-backports
{{ else if eq $architecture "arm64" }}
      - linux-image-arm64/trixie-backports
  {{ fail "architecture not supported" }}
{{ else }}
  {{ fail "architecture not supported" }}
{{ end }}

[lool]

kind of unfortunate, let's see if gnome-core helps with that

[lool]

@gagath I'd suggest adding a gnome build in the github workflows; perhaps in this PR, make it only build gnome rather than gnome and xfce, so that you can iterate more comfortably; might make sense to make the PR a draft as it's likely going to take a few iterations

[gagath]

@gagath I'd suggest adding a gnome build in the github workflows; perhaps in this PR, make it only build gnome rather than gnome and xfce, so that you can iterate more comfortably

Thanks for the tip. I will add a temporary commit to this effect to reduce CI time, so I can iterate on the CI integration in this PR faster.

might make sense to make the PR a draft as it's likely going to take a few iterations

Good idea, done.

[lool]

@gagath Two side goals beyond having a GNOME UX:

• we need a Wayland UX, GNOME can deliver that, I think we should tie the two, and eventually move Xfce to Wayland later; Xorg session is going away in forky anyway, Xfce shoudl be Wayland ready by end of 2026
• we're trying to stay within the guardrails of Qcom compliance as to have public redistributable images (even they are not yet publicly downloadable); this typically means avoiding problematic packages like codecs with patent implications, e.g. gst-plugins-bad, but there might be others; in practice, this means lets keep the image as small and conservative as possible to demonstrate our reference architecture, and iterate over the SBOM in internal reviews

[gagath]

Switching from gnome to gnome-core results in a smaller, still usable image (tested in QEMU). The size difference is documented below:

Package	Free space on / (7GiB image)
gnome	529 MiB
gnome-core	1.5 GiB

If we want to stay close to the free space available in the original XFCE image (665 MiB), we can shrink the image to a theorical minimum of 6 GiB. As expected, this is bigger than the current XFCE image (4.5 GiB), but I think acceptable.

Maybe we should introduce different image sizes per variant? This would need to land prior to this PR, and would reflect the small size of the console image vs. the XFCE image. And the image resizing at first boot would still take care of the reduced free space in the initial image.

[lool]

Switching from gnome to gnome-core results in a smaller, still usable image (tested in QEMU). The size difference is documented below:

Package Free space on / (7GiB image)
gnome 529 MiB
gnome-core 1.5 GiB

Nice, still feels a bit much, but perhaps it's what GNOME implies; if you don't mind pushing your WIP changes here, we could see the syft-generated SBOM and look at package list?

Maybe we should introduce different image sizes per variant? This would need to land prior to this PR, and would reflect the small size of the console image vs. the XFCE image. And the image resizing at first boot would still take care of the reduced free space in the initial image.

If we can avoid branching, the better; from our supported platforms, one of the most constrained one is UNO Q, but its 16G of storage should still be plenty. The other constraint is when building without passing scratch-size to debos, which tries to build in memory: this fails when I do that in a memory-constrained VM, which means it's raising the developer requirements. I don't believe it's an issue with scratch size though.

The rootfs will be grown on first boot, and a disk image full of zero will compress nicely, so I'm not worried about a larger default image size; the only downside is that I suspect flashing a rootfs image full of zeroes does take a bit longer, to we might want to keep the imagesize close to our needs.

[gagath]

Pushed the gnome-core WIP changes for the CI to have a go at it, image size is now 5.5 GiB.