Arch Linux User Repository

@TheDukeofErl thanks for reporting. I bumped the pkrel so that onnxruntime users can have their package fixed. Also added a warning message if onnxruntime is not present because it's an optional dependency.

@gugah rebuilding did the trick and the neuralnet tracker is back. I hadn't thought about the need to do a rebuild like that, nor of that as a potential solution. I will keep that in mind going forward, I'm sure it'll come up with other packages at some point as well. Thank you very much!

@TheDukeofErl thanks for your input. I just re-built opentrack with onnxruntime and installed and it works fine. I can add onnxruntime as a make dependency but that doesn't solve the linking issue if a new version is released... For now please rebuild the package (paru -S --rebuild opentrack or yay -S --rebuild opentrack) and report if your issue is solved. I may have to force a pkrel each time onnxruntime is updated.

It looks like there's a version mismatch that is causing issues with neuralnet right now:

DEBUG [/<path>/opentrack/src/opentrack-opentrack-2023.3.0/api/plugin-support.hpp:106]: library "neuralnet" failed: "Cannot load library /usr/bin/../libexec/opentrack//opentrack-tracker-neuralnet.so: (/usr/lib/libonnxruntime.so.1: version `VERS_1.22.1' not found (required by /usr/bin/../libexec/opentrack//opentrack-tracker-neuralnet.so))"

Checking on onnxruntime, it looks like the repos are now at version 1.22.2-2.

I get the various inputs and filters, but clicking on start (e.g. with Linux Joystick input and Accela selected) give the following error in terminal:

$ opentrack
### Click on the start button after selecting an input and filter
DEBUG [/home/mart/.cache/yay/opentrack/src/opentrack-opentrack-2023.3.0/logic/runtime-libraries.cpp:25]: protocol dylib load failure

Not sure if this is relevant but I dont actually have a tracking device connected. I plan on building a tracker with an arduino and just want to set everything up before I start, so thats why I'm trying this now.

I updated the desktop files so the app show up in the proper category (Utilities) and also added a Wayland launcher (based on https://github.com/opentrack/opentrack/issues/1035) because shortcuts weren't working without the --platform xcb parameter in Wayland.

@jebez : wine is a make dependency. It's one of the output protocols, used for example to interface with X-Plane. It is safe to delete after building the package. You can try editing the PKGBUILD anyways to ignore this protocol:

paru -G opentrack  # or yay -G opentrack
# Edit PKGBUILD
# remove wine from makedepends and -DSDK_WINE=ON
makepkg -si

@jebez wine is required by at least one of the protocols afaik. I could change it as an optional dependency. What do you think about that @Moofed

@pan-mroku

Thanks, that worked. It's a little touchy and there's definitely a right timing to getting the instance in proton opened up, but with a little finagling, it seems pretty stable.

Why wine as dependencie?

yay -S opentrack --ignore wine

not works, is it possible to remove wine as dependencie?

@TheDukeofErl

https://github.com/opentrack/opentrack/issues/1260#issuecomment-881908297

The trick is to run two instances. One outside the container, sending data to UDP. Second one inside the same container as the game, receiving data from UDP and sending into the game