Christian

I'm happy with this workaround posted on [StackOverflow](https://stackoverflow.com/a/74782162/9984216): 1. Definition: Use a property of type `string` and a literal with the JSON representation of the list, e.g. `products: '["yellow", "green"]'`...

Since a separate issue exists now: Fixes https://github.com/JelmerT/cc2538-bsl/issues/172

Detected in https://github.com/batocera-linux/batocera.linux/pull/12291

Detected in https://github.com/batocera-linux/batocera.linux/pull/12291

Detected in https://github.com/batocera-linux/batocera.linux/pull/12291

The build of x265 currently fails on distros containing CMake < 3.2 because of the following line in in [x265/Version.cmake](https://github.com/videolan/x265/blob/419182243fb2e2dfbe91dfc45a51778cf704f849/source/cmake/Version.cmake#L155): ```cmake string(SUBSTRING "${git_repositorychangeset}" 0 9 X265_REVISION_ID) ``` Cause: `git_repositorychangeset` is...

A patch is prepared in https://github.com/tvheadend/tvheadend/pull/1822. Is it possible to trigger a CI build?

Seems to help, there are now 2 more problems concerning x265: [armv7l](https://github.com/tvheadend/tvheadend/actions/runs/14954120952/job/42007501275?pr=1797#step:3:3755): ``` /usr/bin/ld: libx265.a(cpu.cpp.o): in function `x265::cpu_detect(bool)': cpu.cpp:(.text+0x4): undefined reference to `x265_cpu_fast_neon_mrc_test' ``` [aarch64](https://github.com/tvheadend/tvheadend/actions/runs/14954120952/job/42007501321?pr=1797#step:3:4161): ``` cc1: error: unknown value...

`armv9-a` was [added in gcc-12](https://gcc.gnu.org/gcc-12/changes.html#arm-targets).

I think disabling x265 should be no big problem on `armv7l`, because the hardware for this platform is probably not able to deal with it either. `aarch64` is a different...