Conversation
| packages: | ||
| - plymouth-label- # we probably don't need a boot splash | ||
| # from task-gnome-desktop | ||
| - task-gnome-desktop |
There was a problem hiding this comment.
how about we start from gnome-core instead of the full desktop?
There was a problem hiding this comment.
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.
| {{- if eq $xfcedesktop "true" }} | ||
| echo "VARIANT_ID=xfce" >>/etc/buildinfo | ||
| {{- else if eq $gnomedesktop "true" }} | ||
| echo "VARIANT_ID=gnome" >>/etc/buildinfo |
There was a problem hiding this comment.
Both variants can be selected though :-)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 }}
| @@ -1,5 +1,5 @@ | |||
| {{- $dtb := or .dtb "firmware" }} | |||
| {{- $imagesize := or .imagesize "4.5GiB" }} | |||
| {{- $imagesize := or .imagesize "7.0GiB" }} | |||
There was a problem hiding this comment.
kind of unfortunate, let's see if gnome-core helps with that
There was a problem hiding this comment.
I'm proposing a bump here #286, hopefully enough to fit GNOME too
|
@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 |
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.
Good idea, done. |
|
@gagath Two side goals beyond having a GNOME UX:
|
|
Switching from
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. |
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?
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. |
|
Pushed the |
|
Pushed an additional commit to have the CI temporary build with |
Test jobs for commit fe2e378 |
|
Created #296 towards allowing splitting console, XFCE and incoming GNOME images into dedicated debos recipes with an include system allowed by debos. |
|
Created #308 related to introducing a GNOME variant by using separate debos recipes instead of template variables. |
|
Rebased on top of main. Idendified problematic dependencies: # aptitude why gstreamer1.0-plugins-bad
i gnome-core Depends gnome-snapshot (>= 47~)
i A gnome-snapshot Depends gstreamer1.0-plugins-badWhich then brings in x265 stuff. Will continue by manually listing all software from |
Test jobs for commit 2fb150f |
This reuses the existing work for the XFCE variant, this time for GNOME. The full "gnome-core" package cannot be installed because it brings in problematic codecs such as libx265. Manually list the gnome-core dependencies and prune the problematic packages out of it. 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. Signed-off-by: Agathe Porte <agathe.porte@oss.qualcomm.com>
This is a temporary commit to have the CI run the full debos workflow against the newly introduced GNOME desktop variant. The CI runs will be used to investigate the generated SBOM. Signed-off-by: Agathe Porte <agathe.porte@oss.qualcomm.com>
Test jobs for commit 8b76aa0 |
|
@gagath from a quick look at the SBOM, we should try to see if we can get rid of:
|
|
After creating a bug against gnome-control-center and proposing a patch, we found that Ubuntu recently tweaked libheif to Suggest libheif-plugin-libde265 instead of Depend. With this, libheif supports av1 and jpeg but not HEVC by default on Ubuntu. I believe we could do the same for Debian proper, I have opened Bug#1130254 - libheif1: depends on libheif-plugin-libde265, should recommend/suggest instead to discuss it. |
|
It seems that from the list the priority is to remove libde265 and libbluray. EDIT: and libvpx as well |
|
What would it take to drop libvpx? |
4 participants
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
--scratchsizeneed 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.