Package Details: roccat-tools-common 5.9.0-2

Git Clone URL: (read-only, click to copy)
Package Base: roccat-tools
Description: ROCCAT tools common files
Upstream URL:
Keywords: gui hardware keyboard mouse settings
Licenses: GPL2
Submitter: russo79
Maintainer: aaronfischer
Last Packager: aaronfischer
Votes: 56
Popularity: 0.018099
First Submitted: 2012-03-05 16:53
Last Updated: 2020-09-23 21:17

Pinned Comments

aaronfischer commented on 2019-03-28 20:13

@Gonzo2028: See here:

Stunts commented on 2017-01-05 13:13

There are 2 alternative ways:
1. @aaronfischer splits the package into 25 different ones and whenever there is an update he will have to update 25 individual packages; good for the useres, not so good for the maintainer.
2. @aaronfischer "merges" all the files from the split packages into a single package. This will result in installing binaries, udev rules and .desktop files for 25 devices for every user. Less work for the maintainer, not practical for the users.

As is it, the maintainer maintains one single "split-package" and users that use an AUR helper such as yaourt, can uninstall the packages they don't need. This way users get to keep only the files they need to support their own device and the maintainer does not have to modify and commit 25 packages every time there is an update.

Hope this helps clear it.

aaronfischer commented on 2015-11-22 13:21

@edward_81: Please read the previous comments here. I've talked to Stefan about this. Every version of roccat-tools need a specific version of libgaminggear to work correctly. There are two options here: Consistent/reliable package and a little bit of hasle on upgrades -- or easy upgrade process and the chance of a broken package with weird bugs everywhere. I've choosen the first option.

edward_81 commented on 2015-10-03 15:31

Is possible to change the dependency line for libgaminggear from:
Because every time i try to upgrade the system with yaourt/aur, it complain that roccat-tool-common need that exactly version of libgaminggear.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

spawn commented on 2021-02-14 03:32

Just updated roccat-tools-tyon to 5.9.0-2, now I'm getting this error msg whenever I start the configurator via command-line:

roccattyonconfig: symbol lookup error: roccattyonconfig: undefined symbol: roccat_config_window_pages_set_active_page_blocked

The program doesn't start anymore.

EDIT: I got 0 results on Google for this specific error msg, but I was lucky enough to fix it, by simply upgrading roccat-tools-common to the latest version :)

Nalum commented on 2020-10-04 09:08

I'm trying to install this via @TheCynicalTeam but I'm getting errors about the signature being invalid. Any help available?

error: libgaminggear: signature from "TheCynicalLiger <>" is invalid
:: File /var/cache/pacman/pkg/libgaminggear-0.15.1-9-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] 
error: roccat-tools-common: signature from "TheCynicalLiger <>" is invalid
:: File /var/cache/pacman/pkg/roccat-tools-common-5.9.0-3-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] 
error: roccat-tools-nyth: signature from "TheCynicalLiger <>" is invalid
:: File /var/cache/pacman/pkg/roccat-tools-nyth-5.9.0-3-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] 
error: failed to commit transaction (invalid or corrupted package (PGP signature))

I've also just now tried installing from this AUR. Doing so with lua53 package installed ends with the following error, not sure if there is more detail recorded elsewhere:

[ 52%] Linking C shared library
[ 52%] Linking C shared library
[ 52%] Built target libroccatwidget
[ 52%] Built target libkova2016eventhandler
make: *** [Makefile:160: all] Error 2
==> ERROR: A failure occurred in build().
error making: roccat-tools (roccat-tools-common roccat-tools-nyth)

aaronfischer commented on 2020-09-23 21:18

Thanks @Martchus for your work! I've tested and integrated it.

Martchus commented on 2020-09-02 15:15

@TheCynicalTeam And the PKGBUILD from my previous comment doesn't work for you? I was able to build with the latest and greatest of everything available at the time (including Lua 5.4). (I also mentioned my binary repo there. The BUILDINFO file within my packages contains an exact list of dependencies/versions.)

TheRepoClub commented on 2020-09-02 14:49

lua gcc and gcc-libs all need to downgrade to build or i have uploaded them to

Martchus commented on 2020-07-06 13:35

Here's a version I've created in preparation for Lua 5.4:

When adjusting the CMake argument it builds fine against Lua 5.4. I also added the version constraint 'lua<5.5' because it is likely going to need rebuild on every minor Lua release. I also added the patch mentioned by @StefanT to fix the build error.

By the way, this package is provided by my binary repository:

I'd also like to note that adding 25 individual packages is not that bad for the maintainer. I'm maintaining over mingw-w64-qt5-* packages in the AUR and I'm using a simple script to update them simultaneously. But it is of course additional effort, e.g. at some point I've even introduced a templating system to avoid repeating common parts of the PKGBUILDs.

The only real disadvantage I see due to this massive split packaging is that makepkg --printsrcinfo and other makepkg commands take significantly longer to execute than usual. (I thought the build was stuck in the first place.)

Martchus commented on 2020-07-06 09:15

This package needs to be rebuilt against lua 5.4 or use lua53, see

Considering the build error I've got this package likely goes into the lua53 category:

-- Checking for module 'lua'
--   Found lua, version 5.4.0
Version mismatch lua 504 != 503
CMake Error at cmake_modules/FindLUA.cmake:123 (MESSAGE):
  Could not find Lua

However, maybe we can also workaround it (e.g. it might just work fine when making the check less strict).

StefanT commented on 2020-06-30 14:42

Fix for compile problem:

--- ./ryosmk/libroccatryosmk/ryos_device.h.orig 2020-06-30 16:41:33.348116743 +0200
+++ ./ryosmk/libroccatryosmk/ryos_device.h  2020-06-30 16:40:18.701450210 +0200
@@ -23,5 +23,5 @@

-enum {
+typedef enum {
 } RyosWriteCheckWait;

jhey commented on 2020-06-13 22:47

I don't know much about the project's code, but the issue is with one of the ryos device trees. Since I do not use one of those devices, I excluded those packages with the following two patches and the remaining device packages get built properly:

<          'roccat-tools-ryosmk'
<          'roccat-tools-ryosmkfx'
<          'roccat-tools-ryostkl'
> #        'roccat-tools-ryosmk'
> #        'roccat-tools-ryosmkfx'
> #        'roccat-tools-ryostkl'
<         'uhid.conf')
>         'uhid.conf'
>         'CMakeLists.patch')
<             '0d328038322f62ff1f3319666df5f8f58c0a028415a917ad247b0446c1ff90f5')
>             '0d328038322f62ff1f3319666df5f8f58c0a028415a917ad247b0446c1ff90f5'
>             '6acf262d845153a0e414e9c17cb85c1c3e5c1d14324ba4fb9ed469d64376b88c')
>   patch ./CMakeLists.txt "$srcdir/CMakeLists.patch"

$ cat CMakeLists.patch 
<   ryosmk ryosmkfx ryostkl

Endershadow commented on 2020-05-19 19:29

@aaronfischer Sorry, I'm not sure what the patch to fix it would be, I was just mentioning it so that if someone tries to install it in the future, they know that downgrading gcc and gcc-libs to 9.3.0 will allow them to successfully build it.