Stonking Stingray base availability?

[AlgoCompSynth]

Will an Ubuntu minimal Armbian image based on 26.10 "Stonking Stingray" be available? For my project, an every-six-month release is a better fit than every two years or grabbing packages from "sid".

[Werner]

Probably yes, but for development purposes only. We will provide neither "stable" images with non-lts userpsaces nor any support for those whatsoever.

[AlgoCompSynth]

OK ... this is really only critical on the Raspberry Pi Zero 2 W and the PocketBeagle 2 - I don't think they have enough RAM for container hosting of images with newer packages. Is there a way I can get Armbian build to cross-compile packages from source and add them to an image?

Edited August 11 by AlgoCompSynth
added a question

[eselarm]

25 minutes ago, AlgoCompSynth said:

cross-compile packages from source and add them to an image

Why don't you take a closer look at apt sources and repositories and just tune those exactly to your needs?

 

I am not an Ubuntu user anymore, but I remember they have a command/script/tool to get from 1 major release to the next. Should not be magic to do something manual to sources.list* so you have a .10 halfyear versioning.

In addition, you can use apt pinning, so further fine tuning. 

 

Note that Armbian does not provide (vanilla) upstream Linux kernel for RPi boards, same for Ubuntu and various other distros I am aware of. Some do, via U-Boot-EFI loader layer. Also the RPi downstream is different from Armbian and also again Ubuntu's (-raspi suffix) is different. So my experience is that that is a major issue, but really depends on what the board should do. My recent check/test for just a camera streaming use-case failed, so only RPi kernel works (and bootcode.bin,start.elf,fixup.dat or EEPROM contents that come with that certain version).

 

On the other hand, for a file-server or so, you can use whatever kernel, so for sure Debian's generic arm64 (trixie) work but also sid's one. You need changes in config.txt, especially for RPi 3-series also other DTB names are used and you might not want to use the latest bootcode.bin,start.elf,fixup.dat. See explicitly the version and contents of package: raspi-firmware (is different for the various distro's although same name)

 

TI SoC/boards I have no clue, but if U-Boot, so also that is open-source, it should be a lot more flexible to have a certain repo as half-year base. At least forget about 'images' principle. Those 4-core C-A53 boards can easily use Btrfs for rootfs, so with subvolumes/snapshots, they can be easily upgraded while keeping them running and also old versions still there for rollback. I even do that on RPi0/1. As bonus is that Btrfs with its send|receive and parent-child differential subvols/snapshots, allows updating the whole rootfs (a certain subvolume snapshot) on another fast computer like Linux on Apple M1 or some RK3588 SBC with NVME as container and when done, send the diff back, change default subvolume, then reboot and done.

[AlgoCompSynth]

This would be mostly audio applications - the kernel / daemons / compilers / python / lua, etc., would be stock Ubuntu resolute (slightly newer than Debian trixie). I'm thinking of packages like chuck and faust, which update fairly frequently relative to the OS.I can cross-compile them from source; it's just a question if I can do that during the image build or install them after the image has been flashed to the board.

 

[eselarm]

1 minute ago, AlgoCompSynth said:

This would be mostly audio applications - the kernel / daemons / compilers / python / lua, etc., would be stock

That seems to me the same as 'file-server' I mentioned; I do that on a RPI3 vanilla Debian Trixie (since Bullseye already), that all works fine. Only issue maybe is Broadcom firmware for the WiFi of the 02W, but if non-networked, then no issue.

Also if non-networked, you cannot easily apply Btrfs method I mentioned via network, but still works if you take out SD-card and apply diff on another computer. Or via USB stick with the diff (a compressed Btrfs v2 stream as 1 file). 

I have done it like that as well more than a decade ago to sync large HDD's between 2 countries 1000km distance and old 1Mbps DSL internet so driving bay car is faster than transfer via internet.