pkg(deb): add Raspbian Trixie and switch base image

[MichaIng]

balenalib/rpi-raspbian has been archived and not been updated since 2 years. The most downloaded Raspbian base container which provides Debian Trixie images and regular updates at time of writing is from tianon, which I hope is trustworthy enough. Now that Raspberry Pi OS Trixie has been released, a related Docker APT repository suite would help to address some of its limitations.

Not sure about the impact, but for completeness, linux/arm/v6 has been added to the compatible architectures of the Raspbian packages, which is the whole point of why Raspbian exists.

[vvoland]

Hi, thanks for the PR!

Our current plan is deprecating the Raspbian packages in favor of the Debian ones.

See: https://docs.docker.com/engine/install/raspberry-pi-os/

[MichaIng]

Oh, that is sad to read, while I sort of understand the step, as Raspbian/ARMv6hf always was additional hassle, with loosing significance. The Debian-maintained docker.io/docker-cli/docker-compose packages (available on Raspbian Trixie as well) are an alternative.

[vvoland]

In this case I meant our Debian packages (not the ones maintained by Debian): https://docs.docker.com/engine/install/debian/

But yeah they only support armhf (arm/v7) not v6 like Raspbian.

[MichaIng]

Understood. What I meant is that Raspbian/RPi OS users with ARMv6-only hardware can still use the Debian-maintained Docker packages instead, that are provided by Raspbian as well. As always, they won't get upstream updates within one Debian release, but same situation as with RISC-V right now.

OOT: Regarding RISC-V/riscv64 there seem to be ony formalities missing, like CI/CD and testing inplementation for e.g. containerd, isn't it? I might commit something in this regards, looking forward instead of backwards (ARMv6).

[vvoland]

With riscv64 the main blocker for us is the lack of runners/hardware so it's hard for us to have any kind of official support for it.

cc @crazy-max

[MichaIng]

That is true. Can be generally done with emulation, but this is slow, and I also needed disabled some tests for our own Docker-based software implementations since the daemon does not start up OOTB in QEMU-emulated containers on GitHub Actions. But I was able to solve the issues in some cases (did not find the time to check back all cases), by skipping some sandboxing, adding some capabilities and editing some AppArmor profiles on the host (GitHub runner). This is with GitHub Actions ubuntu-24.04-arm runner => systemd-nspawn+QEMU booting riscv64 userland => Docker, but should be similar with nested Docker executions. So if workflow duration is not a concern, and those issues were the show-stopper so far, I might be able to help.