Update and complement DietPi images

[MichaIng]

DietPi provides images in xz-compressed format in the meantime, and images based on Debian Bookworm: https://dietpi.com/downloads/images/

[pguyot]

@MichaIng CI doesn't pass and it seems to be related to DietPi. Would you mind having a look?

[MichaIng]

The base image in the workflow here should be probably taken via download_image.sh? So there are no multiple places to update, when URLs change.

The raspi_*_bookworm image URLs need an update as well: https://raspi.debian.net/tested/

... okay, a lot of hardcoded volatile URLs in the workflow files. I just updated them, removing as well the now non-existing RPi image versions, which should be probably replace with version/date-agnostic URLs. Also I suggest to use the download_image.sh script to obtain the available images in test-base_images.yml, and find some version/date-agnostic URLs for test-partitions.yml and test-custom-url.yml, otherwise they will fail every few months again. I however replaced the latter with an Ubuntu LTS point release, which will stay there for several years. Looks like the latest point releases of each LTS are even kept forever: https://cdimage.ubuntu.com/releases/

[MichaIng]

Btw, I became aware of your action while investigating ARMv7-only builds (with NEON enabled) which where intended to work on ARMv6hf (RPi 1/Zero). Your RPi 1 base image is used, with ARMv6 CPU emulation, and I see you do some clever /proc/cpuinfo mount and wrap QEMU to indeed emulate the RPi, instead of armv7l, which is otherwise does by default, despite Raspbian/ARMv6 userland.

However in this case, one of the media libraries unsets all flag exports and checks for supported compiler/CPU features one after another, compiling a short test code, if I understand correctly, and that returns support for NEON, which of course must not be enabled for these builds.

The configure script from this library contains

cc_check() {
    ...
    rm -f conftest.c
    for arg in $1; do
        echo "#include <$arg>" >> conftest.c
    done
    if [ -n "$4" ]; then
        echo "$4" >> conftest.c
    fi
    echo "int main (void) { $3 return 0; }" >> conftest.c
    if [ $compiler_style = MS ]; then
        cc_cmd="$CC conftest.c $(cc_cflags $CFLAGS $CFLAGSCLI $CHECK_CFLAGS $2) -link $(cl_ldflags $2 $LDFLAGSCLI $LDFLAGS)"
    else
        cc_cmd="$CC conftest.c $CFLAGS $CFLAGSCLI $CHECK_CFLAGS $2 $LDFLAGSCLI $LDFLAGS -o conftest"
    fi
    if $cc_cmd >conftest.log 2>&1; then
        res=$?
        log_ok
    else
        ...
    fi
    return $res
}

...

cc_check '' '' '__asm__("vadd.i16 q0, q0, q0");' && define HAVE_NEON

So it seems to write int main (void) { __asm__("vadd.i16 q0, q0, q0"); return 0; }, tries to compile it, and assumes that NEON is supported, if this succeeds. Not sure if something can be done to have such test fail when using the arm1176 CPU emulation? Sorry for hijacking this PR, I just have the console open where I try to investigate this: tvheadend/tvheadend#1665 (comment)