Arch Linux User Repository

now perfect. thx

Simona,

Can you try to update the package again? I've fixed the build to ignore the libgpio 2.x release entirely. As stated Elwood hasn't made a decision on supporting GPIO in the future via libgpio. It seems that will be a difficult thing to fix, so in lieu of a actual upstream patch we'll just disable support. It's not going to work in Arch Linux anyway given how new libgpio is on the distribution.

Please let me know if this now works with linuxcnc and libgpio installed.

Thanks

Simona,

As a follow up, I had a email conversation with elwood (upstream developer of hamclock) and it appears he is going to address the libgpiod issue by adding a compile option.

I assume you do not need raspberry pi GPIO support, the solution elwood recommends is using a USB adapter moving forward as supporting that for GPIO is far easier than depending on a library that has basically broken and as it stands most distros are still using 1.6x and I don't want to fight with archlinux main repository.

Simona, It seems I am forced to deal with this either two ways.

I can try to solve this with building a secondary AUR package that is using a pre libgpiod 2.0 release and force it to conflict with libgpiod 2.x which ships with Archlinux. BTW I suspect that would break linuxcnc.

I can alternatively just disable libgpiod support until upstream decides to support the 2.0 releases of libgpiod from: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/NEWS

I am thinking to make this sane for arch, just patching out the libgpiod support entirely. I personally don't use that functionality. It's possible someone might want it, but it appears to be incompatible at the moment. I might see if I can fix it and submit a patch but I suspect that will require some additional definitions to detect libgpiod 2.x vs libgpiod 1.6

In file included from HamClock.h:119,
from brightness.cpp:37:
ArduinoLib/Adafruit_MCP23X17.h:43:9: error: ‘gpiod_chip’ does not name a type
43 | gpiod_chip *gpiochip;
| ^~

I solved. The problem was "linuxcnc" AUR pkg (require libgpiod). Thx for patience and help.

Thx for all. I uninstalled rkhunter. It change nothing.

Simona,

did that work?

Simona, The code base uses the Arduino Libraries to build for Linux. It's building using Arduino for x86_64, that's expected and initially was ported to keep the code base the same.

I'm not sure where the call for rkhunter is coming from, I maintain this package for both AUR and PACSTALL. And I test it using

git clone https://aur.archlinux.org/hamclock.git

cd hamclock

makepkg

pacman -U hamclock-4.06-1-x86_64.pkg.tar.zst

I do use pikaur to test as well, but I'd assume this is something yay does or maybe there is something in your build system that is different than just running the normal makepkg command.

You could run "makepkg -si" instead to build and install it. The only dependencies this package has is libx11 and libxcb it doesn't require rkhunter, so something feels strange.

If you feel so incline, can you try it the way I described to do it manually without "yay" and if it fails can you produce a error log. You are welcome to email that to me. This is what happens when I run the up-to-date (ran pacman -Syu on September 14, 2024) Arch linux install.

https://gist.github.com/fang64/caa1f83d81a351575daf1d07c864c294

No... I don't want arduino. The question is why yay -S hamclock on my x86_64 arch linux tries to generate the arduino version and of course fails miserably.
Whei it start it writes:
find: ‘/usr/lib/rkhunter’: access denied
cd ArduinoLib && make clean
make[1]: ingresso nella directory «/home/simona/.cache/yay/hamclock/src/hamclock-4.06/ESPHamClock/ArduinoLib»