Arch Linux User Repository

Fails to compile on my rpi4

/usr/include/c++/12.1.0/bits/char_traits.h:431:56: error: ‘void* __builtin_memcpy(void*, const void*, unsigned int)’ accessing 2147483650 or more bytes at offsets [-1073741822, 3221225470] and [-1073741823, 1073741824] overlaps 2147483653 bytes at offset -3 [-Werror=restrict]
  431 |         return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n));
      |                                  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~

I only managed to compile by disabling flatbuffer and protobuf configuring cmake inside build() in PKGBUILD like this

  cmake -DCMAKE_BUILD_TYPE=Release \
        -DPROTOBUF_PROTOC_EXECUTABLE=/usr/bin/protoc \
        -DUSE_SYSTEM_PROTO_LIBS=OFF \
        -DUSE_SYSTEM_MBEDTLS_LIBS=ON \
        -D ENABLE_FLATBUF_CONNECT=OFF \
        -D ENABLE_FORWARDER=OFF \
        -D ENABLE_FLATBUF_SERVER=OFF \
        -D ENABLE_PROTOBUF_SERVER=OFF \
        ..

I just tried upgrading again an now I'm on ..r4.. version and RPI SPI section is back again. I have no idea how I ended up with ..r8.. or ..r20.. version previously, but everything is working now.

Few days ago I ugpraded to latest version (see previous comment) and reported hyperion working but that was on my test PC using the web configuration LED visualization window. Today I upgraded my living room PC which has the actual LED strip attached but the LED's don't work (visualization window is ok).

I use apa102 but I noticed I cannot select this anymore with the ..r20.. version! I could choose apa102 on previous ..r8..version under controller type "RPI SPI" but that option is gone now. How do I get apa102 to work?

I use package-query -Au to check for changed AUR packages. I was using ..r8.. version, I just downloaded and build and now I have ..r20.. version which is working. I notice on this webpage it says ..r4.. version, maybe that's why package-query -Au did not pick it up. Anyway, thanks for your time.

@Rob_H: That is interesting, it automatically picks qt5 for me and builds still fine -- Found Qt Version: 5.15.2. If I install qt6-base without serialport it builds with qt5 anyway. Only if I remove qt5-base I can reproduce this, but this should not be possible with the current qt5 dependency. Will do more experiments in a chroot. Maybe you have an idea? Do you have both qt 5 and 6 installed?

Edit, it should indeed prefer qt6, from here:

find_package(QT NAMES Qt6 Qt5 COMPONENTS Core Gui Network Sql Widgets REQUIRED)

https://doc-snapshots.qt.io/qt6-dev/cmake-qt5-and-qt6-compatibility.html So the behavior you see is normal.

@unformatted: Can't reproduce, build detects it correctly: -- Found Python3: /usr/bin/python3.10 (found suitable version "3.10.2", minimum required is "3.5") found components: Interpreter Development Development.Module Development.Embed

and output is fine:

ldd /bin/hyperion-remote 
        linux-vdso.so.1 (0x00007ffc92f3d000)
        libpython3.10.so.1.0 => /bin/../lib/libpython3.10.so.1.0 (0x00007fca66768000)
        ...

Of course after that it also runs normally. Are you sure you properly rebuild? Looks like an old pkg to me.

After upgrading my RPi4 running arch ARM with kodi and hyperion.ng, hyperion does not start anymore. The previous upgrade was on 2021-12-26 and working. I start hyperion manually from kodi script mapped to my remote. This package is supposed to be rebuild for python 3.10 but hyperion-remote expects libpython3.9.so.1.0 library. This happens:

[user@PC19 ~]$ systemctl --user start hyperion.service
[user@PC19 ~]$ systemctl --user status hyperion.service
× hyperion.service - Hyperion ambient light systemd service
Loaded: loaded (/home/user/.config/systemd/user/hyperion.service; bad; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2022-02-15 13:21:05 CET; 2s ago
Docs: https://docs.hyperion-project.org
Process: 492 ExecStart=/usr/bin/hyperiond (code=exited, status=127)
Main PID: 492 (code=exited, status=127)
CPU: 4ms

Feb 15 13:21:05 PC19 systemd[378]: hyperion.service: Scheduled restart job, restart counter is at 3.
Feb 15 13:21:05 PC19 systemd[378]: Stopped Hyperion ambient light systemd service.
Feb 15 13:21:05 PC19 systemd[378]: hyperion.service: Start request repeated too quickly.
Feb 15 13:21:05 PC19 systemd[378]: hyperion.service: Failed with result 'exit-code'.
Feb 15 13:21:05 PC19 systemd[378]: Failed to start Hyperion ambient light systemd service.

[user@PC19 ~]$ hyperion-remote -h
hyperion-remote: error while loading shared libraries: libpython3.9.so.1.0: cannot open shared object file: No such file or directory

My system: Linux 5.15.21-3-rpi-ARCH #1 SMP PREEMPT Fri Feb 11 13:59:13 UTC 2022 aarch64 GNU/Linux kodi-rpi 19.3-3 python 3.10.2-1 hyperion.ng-git 2.0.12.r8.c38ec602-1

Hey all. Didn't build for me out of the box:

-- Could NOT find Qt6SerialPort (missing: Qt6SerialPort_DIR)
CMake Error at libsrc/leddevice/CMakeLists.txt:11 (find_package):
  Found package configuration file:

    /usr/lib64/cmake/Qt6/Qt6Config.cmake

  but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be NOT
  FOUND.  Reason given by package:

  Failed to find Qt component "SerialPort".

  Expected Config file at
  "/usr/lib64/cmake/Qt6SerialPort/Qt6SerialPortConfig.cmake" does NOT exist

Looks like dependencies need to be updated to point to qt6-serialport instead of qt5-serialport. If I install that, it works. Not sure about the other Qt dependency (qt5-x11extras). I don't see a Qt 6 version of that, but it builds/runs fine without it.

Thanks for the hint @stiw47. The systemd files indeed needed adjustments, running as root does not make sense anymore. I changed it to the upstream approach now, so it needs an @ username parameter:

sudo systemctl start hyperiond@$USER.service

But I found that this is also not quite right, for example my Qt theme does not get applied to the tray menu. It is better to use systemd-user directly, I included a unit file as well, anyway it needs some manual commands to setup the homedir:

ln -s /usr/share/hyperion/hyperiond-user.service ~/.config/systemd/user/hyperion.service
systemctl --user daemon-reload
systemctl --user start hyperion.service

All service management commands must include the --user flag and don't need root/sudo at all. This is the approach I would recommend.

@Jake: Thanks a lot for your effort to maintain this. Anyway, it seems that with current hyperion.systemd file isn't possible to have other internal capture device except of Framebuffer. I wanted to use Hyperion with internal capture, then found it wasn't possible atm cause only framebuffer was available, then @Lord-Grey from Hyperion forum helped me to change hyperion.systemd file content. This is for "letting you know" purpose, if you are interested to take a look, you can find detailed info here: https://hyperion-project.org/forum/index.php?thread/12471-leds-not-working-on-archlinux-x86-64-with-framebuffer-screen-capture/

Thanks once again for maintaining this.

@Jake thanks for the update ! Works now.