Multi suite, multi distro

[lool]

This is still exploratory and in the short-term meant to help compare
SBOMs across distros and suites

• feat(rootfs): Add suite and distro variables
• feat(rootfs): Generate APT sources dynamically
• feat(rootfs): Generate Debian backports APT config
• feat(rootfs): Generate qsc-deb-releases APT config
• feat(rootfs): Add hostname and username parameters
• feat(rootfs): Per distro mirrors and components
• feat(Makefile): Pass suite and distro to debos
• ci(debos): Add suite and distro inputs, matrix build on PR
• WIP: Add matrix build to build-on-push too

[lool]

A few thoughts on current implementation:

• this lacks updates to docs, especially to remind ourselves and users of the overarching goals and what can reasonably be expected from qcom-deb-images; also general guidance on CI approach (build distro = target distro for instance)
• it's painful when lists of packages are not in sync across target suites; I expect this will wash out over time
• differences between Ubuntu and Debian are not as small as I wish, but not as large as I feared :)
• will need to do something about the debian names in debos-recipes/qualcomm-linux-debian-*.yaml
• debos as a deb is in various shapes: doesn't start in resolute (some issue with kernel modules), not installable in noble (no arm64 build); perhaps a different strategy is warranted, could be to use our own debos builds, or perhaps use a devel distro to build stable, not sure
• I had snapshots and UX flavors in mind too, but didn't want to do these in the same PR

[lool]

Resolute image from CI running under QEMU

Current known issues:

• build-url GH artifact has an unique name, so second upload-artifact call fails; we could prefix it, or we could upload it later, or we could just not use it at all – perhaps needs some bigger picture thinking with LAVA integration
• qemu tests are failing, hostname is hardcoded to debian
• need to update run-qemu script for new image names
• Xfce desktop has no background

[lool]

The noble image doesn't boot; it seems systemd-boot doesn't like the format of the linux kernel

[basak-qcom]

AIUI, the kernel has stubble embedded into it now. Maybe an interaction with that?

[gagath]

Note that change is already pending in #277

[gagath]

As a global feedback I think that there is too much logic in the workflows and not enough outside of it. Github actions are well known for being hard to debug. I would like to have most of the logic inside of the Makefile instead, so users can reuse it, but it conflicts with the "one rootfs.tar, one image" policy a bit.

We could have .PHONY targets that generate Debian or Ubuntu images, but this is very hacky and I would like to have proper targets like rootfs-debian-unstable.tar instead. I think that @basak-qcom agrees, and that @lool disagrees. :)

[basak-qcom]

I would like to have most of the logic inside of the Makefile instead...

Strongly agree to moving logic out of the GitHub Actions as much as possible :)

...I would like to have proper targets like rootfs-debian-unstable.tar instead...

I'd be OK with that, but would prefer not to end up with a proliferation of filenames. Maybe we could use dedicated build output directories instead?

Another approach would be to consider these things "build config" like the kernel does. Provide a config, expect exactly one build result, and arrange dependencies correctly so that if the config changes then the right things are rebuilt. That might be more complex that it's worth though, so a cut down version of that would be to use config parameters to make, and require a clean between builds.

Some combination of that might be possible. Define "build flavours" that set various parameters in config/flavour/* (checked in), then arrange build output in build/flavour/*. Initially make FLAVOUR=foo ... could then work easily enough. Developers could customise config parameters by duplicating config/flavour/foo/ into config/flavour/bar/ locally, then asking for that build.

[gagath]

Another though: we have Debian overlays for unstable and trixie, but nothing regarding Ubuntu. By adding Ubuntu support, are we also taking the responsibility to create such overlays (PPAs? QArtifactory?) and backport our preview changes (alsa-ucm-conf…) on noble and questing as well?

This would create additional work for DDs so we need to make sure we agree on what needs to be done, and how.