roccat-tools-3.3.0 & libgaminggear-0.8 out.
up
@Perfect Gentleman: Mate, I appreciate your reminders but I just haven't had any time to look into this. After all, I read the upstream release notes and there aren't any significant changes worth putting effort to upgrade for. According to erazor_de, main addition is German translation - but (may be that's selfish. but) I don't speak German so that's of no importance to me. If I'll get some time I'll get this done some day, but most likely I'll just skip 3.3.0 altogether and ebuild the next one erazor_de releases. That said, if you wanna create ebuilds for this one - you're more than welcome. Gentoo is community effort and that's why I love it!
(In reply to Dmitry Pisklov from comment #2) > @Perfect Gentleman: > Mate, I appreciate your reminders but I just haven't had any time to look > into this. After all, I read the upstream release notes and there aren't any > significant changes worth putting effort to upgrade for. > According to erazor_de, main addition is German translation - but (may be > that's selfish. but) I don't speak German so that's of no importance to me. > If I'll get some time I'll get this done some day, but most likely I'll just > skip 3.3.0 altogether and ebuild the next one erazor_de releases. > That said, if you wanna create ebuilds for this one - you're more than > welcome. Gentoo is community effort and that's why I love it! There is a small changes: 1. No -DWITH_LUA=ON, now -DWITH_LUA=5.1 for Gentoo 2. Kova[+] requires Kone [+] I upload ebuild that works for me
Created attachment 403230 [details] 3.3.0 ebuild workaround
Well I can see why it works but I think it needs a bit more work - in Gentoo, both lua 5.1 and lua 5.2 are available, so likely there will need to be 2 useflags, unless there's already something similar to python - you know, when you kinda can select which versions of python you wanna support: PYTHON_TARGETS="python2_7 python3_3 -pypy -python3_4" So I'll need someone from Gentoo devs to confirm if there's such thing for lua, if not - may be it would make sense to implement... Or we could just have 2 useflags - lua5.1 and lua5.2 for now. But that will mean we have to maintain list of useflags in sync with versions of lua available in Gentoo portage
(In reply to Dmitry Pisklov from comment #5) > Well I can see why it works but I think it needs a bit more work - in > Gentoo, both lua 5.1 and lua 5.2 are available, so likely there will need to > be 2 useflags, unless there's already something similar to python - you > know, when you kinda can select which versions of python you wanna support: > PYTHON_TARGETS="python2_7 python3_3 -pypy -python3_4" > So I'll need someone from Gentoo devs to confirm if there's such thing for > lua, if not - may be it would make sense to implement... Or we could just > have 2 useflags - lua5.1 and lua5.2 for now. But that will mean we have to > maintain list of useflags in sync with versions of lua available in Gentoo > portage But what to do with Kova[+], which requires Kone[+]'s library? I understood that library should be complied and installed, but Kone[+]'s exec.
Sorry man - why do you think Kova[+] requires Kone[+]? I don't see any mention of this on erazor_de's sourceforge page...
(In reply to Dmitry Pisklov from comment #7) > Sorry man - why do you think Kova[+] requires Kone[+]? I don't see any > mention of this on erazor_de's sourceforge page... When I try to compile there is notice about which I opened thread on the forum https://sourceforge.net/p/roccat/discussion/989581/thread/cf470b51/
I probably will need to check with the original developer - not sure this is intentional change.
(In reply to Dmitry Pisklov from comment #9) > I probably will need to check with the original developer - not sure this is > intentional change. the problem is solved. you can check the topic. $ sed -i '/libroccatkoneplus/d' kovaplus/roccatkovapluscontrol/CMakeLists.txt
(In reply to Dmitry Pisklov from comment #5) > Well I can see why it works but I think it needs a bit more work - in > Gentoo, both lua 5.1 and lua 5.2 are available, so likely there will need to > be 2 useflags, unless there's already something similar to python - you > know, when you kinda can select which versions of python you wanna support: > PYTHON_TARGETS="python2_7 python3_3 -pypy -python3_4" Well even as a python dev, this beckons slotting * dev-lang/lua Available versions: (0) 5.1.4-r8 5.1.5 (~)5.1.5-r1 5.1.5-r3 (5.1) [M](~)5.1.5-r2 [M](~)5.1.5-r100 (5.2) [M](~)5.2.3 [M](~)5.2.3-r1 They are all already slotted, however note the masking.
sys-apps/roccat-tools-3.4.0 & dev-libs/libgaminggear-0.9: version bump
Created attachment 404024 [details] New ebuild for dev-libs/libgaminggear-0.9.0
Created attachment 404026 [details] New ebuild for sys-apps/roccat-tools-3.4.0
Created attachment 404028 [details] New metadata.xml for sys-apps/roccat-tools-3.4.0
CMake Error at CMakeLists.txt:84 (FIND_PACKAGE): find_package called with invalid argument "ON" smth wrong with USE for lua.
please, correct >=dev-libs/libgaminggear-0.7 -> >=dev-libs/libgaminggear-0.9
Created attachment 404106 [details] New ebuild for sys-apps/roccat-tools-3.4.0 Apologize - was drunk. Now correct ebuild...
doesn't work ------------- cmake --no-warn-unused-cli -C /tmp/portage/sys-apps/roccat-tools-3.4.0/work/roccat-tools-3.4.0_build/gentoo_common_config.cmake -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr -DDEVICES=kovaplus;ryosmk -DUDEVDIR=/lib/udev/rules.d -DWITH_LUA=ON -DWITH_LUA=OFF ---------------------------- I think "if-else" should be used.
Weird. Build succeeded for me and I assumed it worked fine - apparently it disabled lua somehow... It seems cmake_utils.eclass is not implementing all the features. I actually can't see any way to supply custom value other than ON or OFF to cmake... Seems will have to pass the -DWITH... manually.
Created attachment 404158 [details] New ebuild for sys-apps/roccat-tools-3.4.0 Alright, this one works for sure but I think we need to ask Gentoo devs to update cmake-utils.eclass to allow passing value to cmake-utils_use_with, instead of putting ON or OFF, same way as in use_with: use_with <USE item> [configure name] [configure opt] Useful for creating custom options to pass to a configure script. If USE item is in the USE variable and a configure opt is specified, then the string --with-[configure name]=[configure opt] will be echoed. If configure opt is not specified, then just --with-[configure name] will be echoed. If USE item is not in the USE variable, then the string --without-[configure name] will be echoed. If configure name is not specified, then USE item will be used in its place. Beginning with EAPI 4, an empty configure opt argument is recognized. In EAPI 3 and earlier, an empty configure opt argument is treated as if it weren't provided.
now it works. excellent. thanx.
shall attempt to complete this tomorrow
Sorry to spoil the party but not yet ready. dev-libs/libgaminggear $ USE=doc ebuild libgaminggear-0.9.0.ebuild clean install yields $PORTAGE_TMPDIR/dev-libs/libgaminggear-0.9.0/image/usr/share/gaminggear/html/{html,icons} This makes the install location here rogue. Unless someone can prove otherwise, the traditional and expected location of docs whether html of other styles is in /usr/share/doc/${PF}/ in this case /usr/share/doc/${PF}/html The icons folder I would expect to be a subfolder to html/ I suspect this has been overlooked in prior versions. Please edit the ebuild of libgaminggear-0.9.0.ebuild to install the doc build into /usr/share/doc/${PF}/html
On further checking this location is used, however it's preferable to use /usr/share/doc/${PF}/ If it proves too arduous we'll settle for the location as it is. It's not system cirtical
@Ian To be honest I have no idea how to do that - can we keep it as it is for now, at least it will be consistent with previous versions?
(In reply to Dmitry Pisklov from comment #26) > @Ian > To be honest I have no idea how to do that - can we keep it as it is for > now, at least it will be consistent with previous versions? I am really in 2 minds. According to a recruiter the location /usr/share/doc/${PF}/ is the one and only correct. To commit it installing to the other is to commit an ebuild known to be wrong. It's not that hard. It goes something like if use doc; \ then emake or cmake or whatever and add an option something like --install_dir=${D}usr/share/doc/${PF}/. Just fi peruse the ebuilds in portage and it should not take you long to find some to use as a model. Just realise, "it will be consistent with previous versions?" is to knowingly perpetuate a mistake
Well either it's lack of any knowledge about cmake and its args or there's really no way to configure this... What I tried is using -DDOCDIR="${EPREFIX}"/usr/share/doc/${PF}/html as well as -DDOCHTMLDIR="${EPREFIX}"/usr/share/doc/${PF}/html and -DCMAKE_INSTALL_DOCDIR=/usr/share/doc/${PF} But this doesn't work. (I took first example from x11-misc/tint2/tint2-0.11-r2.ebuild) After a bit more digging, I found this: INSTALL( DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html DESTINATION share/gaminggear ) in ./include/gaminggear/CMakeLists.txt. Which suggests me there's no way to configure this via variable. I dropped a mail to package author. At the moment I don't really feel keen adding a patch to replace this with variable... Can we live with it as it is right now until it's made configurable officially upstream? Alternatively I can simply hard-disable docs
What's important is that you made an effort. That you didn't actually find it is fine since you tried. I shall find out by asking the right gurus
(In reply to Dmitry Pisklov from comment #28) > Well either it's lack of any knowledge about cmake and its args or there's > really no way to configure this > Consider this a treatment to sure your lack of any knowledge with the knowledge. > After a bit more digging, I found this: > INSTALL( > DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html > DESTINATION share/gaminggear > ) > > in ./include/gaminggear/CMakeLists.txt. Which suggests me there's no way to > configure this via variable. > This is you looking right at the answer. The DESTINATION is a var and the share/gaminggear is the value. Try setting the var DESTINATION to /usr/share/doc/${PF}/ You just have to manage the ${PF}. Offhand when run under bash I think it will expand correctly as is but it's your task to runtest. > I dropped a mail to package author. At the moment I don't really feel keen > adding a patch to replace this with variable... Can we live with it as it is > right now until it's made configurable officially upstream? Alternatively I > can simply hard-disable docs This is looking totally resolvable so for now no.
Sorry do you mean setting DESTINATION var in the ./include/gaminggear/CMakeLists.txt ? Because that's where it is set, and I don't think just setting DESTINATION var from portage is going to work - there're lots of DESTINATION vars in different CMakeLists.txt across the file tree, and I don't think it's good idea to replace all of those to be /usr/share/doc... Anyway I tried it in case I'm lucky but as I expected it didn't work. If I am right it only expands variables which are ${}-embraced... And if you mean patching the file to replace this line - that was exactly what I was trying to avoid... But it seems that's the only way to fix this.
(In reply to Dmitry Pisklov from comment #31) > Sorry do you mean setting DESTINATION var in the > ./include/gaminggear/CMakeLists.txt ? Yes > Because that's where it is set, and I > don't think just setting DESTINATION var from portage is going to work - > there're lots of DESTINATION vars in different CMakeLists.txt across the > file tree, and I don't think it's good idea to replace all of those to be > /usr/share/doc... > Anyway I tried it in case I'm lucky but as I expected it didn't work. If I > am right it only expands variables which are ${}-embraced... > And if you mean patching the file to replace this line - that was exactly > what I was trying to avoid... But it seems that's the only way to fix this. That's exactly what I meant and that's exactly what you seem to have avoided. CC pacho and see if he can help here with advice.
I don't know much about cmake, sorry. But the first thing I would try is to modify: include/gaminggear/CMakeLists.txt INSTALL( DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html DESTINATION share/gaminggear ) -> change DESTINATION to "share/doc/${PF}". Could you give it a try? Thanks
All right, I was waiting for upstream to fix this for me, but the fix wasn't quite what I requested, so I still had to provide patch... Now we have new version of liggaminggear, and 2 roccat-tools ebuilds depending on it. I skipped previous version of libgaminggear to avoid providing 2 different patches.
Created attachment 405908 [details] New ebuild for sys-apps/roccat-tools-3.4.0
Created attachment 405910 [details] New ebuild for dev-libs/libgaminggear-0.10.0
Created attachment 405912 [details, diff] Patch for /usr/portage/dev-libs/libgaminggear/files
(In reply to Dmitry Pisklov from comment #34) > All right, I was waiting for upstream to fix this for me, but the fix wasn't > quite what I requested, so I still had to provide patch... > Now we have new version of libgaminggear, and 2 roccat-tools ebuilds > depending on it. I skipped previous version of libgaminggear to avoid > providing 2 different patches. well done Dmitry. The html docs install into libgaminggear-0.10.0/image//usr/share/doc/libgaminggear-0.10.0/html/. Perfect. *libgaminggear-0.10.0 (30 Jun 2015) 30 Jun 2015; Ian Delaney <idella4@gentoo.org> +files/libgaminggear-0.10.0-doc.patch, +libgaminggear-0.10.0.ebuild: bump; ebuild submitted via bug #548388 by proxy maintainer The patch could well have been a sed statement in src_prepare, but both work. It's good as is. Re the roccat-tools-3.4.0.ebuild, it might be good to postpone or remove the USE_EXPAND for lua52. repoman full yields dependency.bad [fatal] 50 sys-apps/roccat-tools/roccat-tools-3.4.0.ebuild: DEPEND: ~amd64(default/linux/amd64/13.0) for every entry under default/linux/amd64/13.0 under profiles. Note: $ eix dev-lang/lua * dev-lang/lua Available versions: (0) 5.1.4-r8 5.1.5 (~)5.1.5-r1 5.1.5-r3 (5.1) [M](~)5.1.5-r2 [M](~)5.1.5-r100 (5.2) [M](~)5.2.3 [M](~)5.2.3-r1 5.1 & 5.2 are both still masked. The only way I can commit this with lua52 and possibly lua51 is to firstly pmask it under profiles as well. For the sake of getting the roccat-tools-3.4.0.ebuild into the tree, to postpone their addition seems a fair compromise. I know nothing of dev-lang/lua and why those SLOTs have been pmasked.
Well basically I added Lua 5.2 support as a future-proofing, so it's there when 5.2 slot is unmasked. 5.1 at the moment can be used with slotted 5.1 or default :0 slot, which is the only one available at the moment. Essentially that means it's up to user to use 5.2 if he wants to go unstable route and unmask 5.2 slot, otherwise the only working combination is with default lua slot. And it seems I forgot to attach roccat-tools-3.5.0.ebuild, will do now.
Created attachment 405998 [details] New ebuild for sys-apps/roccat-tools-3.5.0
(In reply to Dmitry Pisklov from comment #39) > Well basically I added Lua 5.2 support as a future-proofing, so it's there > when 5.2 slot is unmasked. > 5.1 at the moment can be used with slotted 5.1 or default :0 slot, which is > the only one available at the moment. > Essentially that means it's up to user to use 5.2 if he wants to go unstable > route and unmask 5.2 slot, otherwise the only working combination is with > default lua slot. > And it seems I forgot to attach roccat-tools-3.5.0.ebuild, will do now. Yes the trouble is I can't commit an ebuild utilising the options that require the masked lua52. What I could do is commit ebuilds without lua52 in roccat-tools-3.4.0 roccat-tools-3.5.0 and make a revbump of each with the lua52 and mask them. Even then it's not std. procedure and I'd have to check it's a legit move. The practice of preparing for when they are unmasked is fine. However for the present, repoman rules the form with the lua52 as violating qa ( dependency.bad [fatal] 50 ) with repoman full. I can't argue with that.
OK please do as you think is better
(In reply to Dmitry Pisklov from comment #42) > OK please do as you think is better Dmitry the goal here is for you to decide. I have stated both are viable options and I have described the pros and cons. I suggest finding out some kind of time line on the unmasking of the dev-lang/lua for 5.1 5.2 which means researching why they were masked and ascertaining the state of progress towards them being unmasked. Rule of thumb; if the answer == it's unclear and no-one seems to know and there is no time line of anticipation to them being unmasked, my pov is to strip all mention of the lua51 lua52 from the ebuild and re-submit it, or, as I said, I can commit one in a revbump and mask the revbumped version. That way users can gain the advantage of the bumped roccat-tools in a working state and the better equipped revbump is sitting ready and waiting to be launched..
Created attachment 407178 [details] New ebuild for sys-apps/roccat-tools-3.4.0 All right, I removed lua 5.2 from both 3.4 and 3.5 ebuilds, and I also prepared 3.5.0-r1 one which should be package-masked until lua 5.2 slot arrives in portage. Also I prepared roccat-tools-3.2.0-r1 and libgaminggear-0.10.0-r1 to resolve bug 555244. @Ian please kill roccat-tools-3.2.0 and lingaminggear-0.10.0 from tree, they need to be replaced with *-r1 to resolve dependency issues.
Created attachment 407180 [details] New ebuild for sys-apps/roccat-tools-3.5.0
Created attachment 407182 [details] New ebuild for sys-apps/roccat-tools-3.2.0-r1
Created attachment 407184 [details] New ebuild for sys-apps/roccat-tools-3.5.0-r1
Created attachment 407186 [details] New ebuild for dev-libs/libgaminggear-0.10.0-r1
Hopefully now 2.5 months later we can finally close it... :) I have to admit I was quite bad at responding, took me very long time to sort outstanding things
libgaminggear-0.10.1 is out
Can confirm that the new ebuilds roccat-tools-3.2.0-r1 and libgaminggear-0.10.0-r1 adequately prevent combining to form a build failure. One note however is in the DEPEND list for roccat-tools: roccat-tools-3.2.0 has DEPEND=">=dev-libs/libgaminggear-0.7" roccat-tools-3.2.0-r1 has DEPEND="<dev-libs/libgaminggear-0.8" This is why I suggested =libgaminggear-0.7.0 in the ebuild on bug 555244 (I was assuming there was a specific reason for the >=libgaminggear-0.7). Lastly, if bug 555244 is resolved here, I'm not sure if it should be closed as duplicate, made a blocker or dependent, or what.
@wraeth I asked above for 3.2.0 ebuild to be removed from the tree, that means it will not be available for installation together with libgaminggear-0.10.0. As to other bug, I'd suggest it's resolved as soon as 3.2.0-r1 and 0.10.0-r1 hit the main portage tree (Or 0.10.1, as it's available now - I'll replace r1 now).
Created attachment 407294 [details] New ebuild for dev-libs/libgaminggear-0.10.1 Scrap 0.10.0-r1 ebuild, now we have 0.10.1.
Dmitry, In ebuild of libgaminggear-0.10.1, I have never seen a form like !<sys-apps/roccat-tools-3.4.0 before let alone used it. '!' is traditionally used as a blocker rather than to set a border version. By convention, to set bordering, use 1 line of >= and if really required, a 2nd line of <. Use of <package-version by itself is frought with flaws and should be avoided. The libgaminggear-0.10.0.ebuild has no equiv entry so it seems this line need be removed. Without bumping to libgaminggear-0.10.1 everything unravels so i am just removing the line. @Ian please kill roccat-tools-3.2.0 and libgaminggear-0.10.0 from tree.roccat-tools-3.0.[0-1].ebuild and roccat-tools-3.0.[0-1].ebuild? I have decided to rm them since their retention makes little sense with removing -3.2.0. ditto the old versions of libgaminggear. *libgaminggear-0.10.1 (21 Jul 2015) 21 Jul 2015; Ian Delaney <idella4@gentoo.org> +libgaminggear-0.10.1.ebuild, -libgaminggear-0.10.0.ebuild: bump; ebuild from bug #548388, rm all prior versions The ebuild of roccat-tools-3.4.0 has the refs to the masked lua, cannot add. *roccat-tools-3.5.0 (21 Jul 2015) *roccat-tools-3.5.0-r1 (21 Jul 2015) 21 Jul 2015; Ian Delaney <idella4@gentoo.org> +roccat-tools-3.5.0-r1.ebuild, +roccat-tools-3.5.0.ebuild, -roccat-tools-3.0.0.ebuild, -roccat-tools-3.1.0.ebuild, -roccat-tools-3.2.0.ebuild, metadata.xml: bump, revbump; the -3.5.0-r1 has been pmasked due to deps of masked slots of dev-lang/lua, ebuilds by maintainer sourced from Bug 548388, removal of old versions
The !<sys-apps/roccat-tools-3.4.0 was indeed intended as a blocker, it's not a dependency. roccat-tools depends on libgaminggear, not the other way round, but blocker is there to avoid upgrade of libgaminggear without upgrading roccat-tools as it will break ABI. And I'm surprised you can add 3.5.0 but not 3.4.0 as they are absolutely identical (bar the filename). Yes, make sense killing old versions of roccat-tools, but if you delete libgaminggear-0.7.0 you basically make roccat-tools-3.2 broken as it depends on it and can't be built against libgaminggear-0.10
(In reply to Dmitry Pisklov from comment #55) > The !<sys-apps/roccat-tools-3.4.0 was indeed intended as a blocker, it's not > a dependency. roccat-tools depends on libgaminggear, not the other way > round, but blocker is there to avoid upgrade of libgaminggear without > upgrading roccat-tools as it will break ABI. With all old versions purged this shouldn't be an issue > And I'm surprised you can add 3.5.0 but not 3.4.0 as they are absolutely > identical (bar the filename). Explanation: The 3.4.0 contains the refs to the masked slotts of lua. To add the 3.4.0, I would also need to mask it under profiles for repoman to allow the commit. At this point I don't think 3.4.0 is really required but if you want or need it say so. I will need to pmask it first. > Yes, make sense killing old versions of roccat-tools, but if you delete > libgaminggear-0.7.0 you basically make roccat-tools-3.2 broken as it depends > on it and can't be built against libgaminggear-0.10 You asked for roccat-tools-3.2 to be removed. If you want or need the revbumped version to be added and kept it wasn't made clear.
(In reply to Ian Delaney from comment #56) > > And I'm surprised you can add 3.5.0 but not 3.4.0 as they are absolutely > > identical (bar the filename). > > Explanation: The 3.4.0 contains the refs to the masked slotts of lua. To add > the 3.4.0, I would also need to mask it under profiles for repoman to allow > the commit. At this point I don't think 3.4.0 is really required but if you > want or need it say so. I will need to pmask it first. As I said - roccat-tools-3.4.0.ebuild and roccat-tools-3.5.0.ebuild are identical, and both have: lua? ( || ( dev-lang/lua:5.1 dev-lang/lua:0 ) ) I.e. I thought it makes sense to allow people to use slots if needed or just normal unmasked lua. So it can easily be built without any unmasking. On contrast, roccat-tools-3.5.0-r1.ebuild is the one to be masked as it has 5.2 flag which has dependency on 5.2 slot which is masked. > > Yes, make sense killing old versions of roccat-tools, but if you delete > > libgaminggear-0.7.0 you basically make roccat-tools-3.2 broken as it depends > > on it and can't be built against libgaminggear-0.10 > > You asked for roccat-tools-3.2 to be removed. If you want or need the > revbumped version to be added and kept it wasn't made clear. In my comment, I said: > Also I prepared roccat-tools-3.2.0-r1 and libgaminggear-0.10.0-r1 to resolve bug 555244. > @Ian please kill roccat-tools-3.2.0 and lingaminggear-0.10.0 from tree, they need to be replaced with *-r1 to resolve dependency issues. Which I hoped should mean "kill the non-r1 versions, and add XXX-r1 to resolve dependency issues". I initially thought of leaving 3.2.0 (in its -r1 reincarnation) just to have the version of package which is already tested and working, ditto for libgaminggear-0.7.0-r1. However I use 3.5.0 myself for quite some time so may be just to reduce possibilities for confusion we can just leave 3.4.0, 3.5.0, 3.5.0-r1(masked) and 0.10.1 and purge the rest.
(In reply to Dmitry Pisklov from comment #57) (In reply to Ian Delaney from comment #56) > > And I'm surprised you can add 3.5.0 but not 3.4.0 as they are absolutely > > identical (bar the filename). > I must have had an old form of roccat-tools-3.4.0.ebuild, it drew fatal error from repoman. The one in the current attachment does match the one in roccat-tools-3.5.0.ebuild so I shall add the roccat-tools-3.4.0. > I initially thought of leaving 3.2.0 (in its -r1 reincarnation) just to have > the version of package which is already tested and working, ditto for > libgaminggear-0.7.0-r1. However I use 3.5.0 myself for quite some time so > may be just to reduce possibilities for confusion we can just leave 3.4.0, > 3.5.0, 3.5.0-r1(masked) and 0.10.1 and purge the rest. Indeed. I'd say you did make it clear enough but there was so much to sort, I missed. *roccat-tools-3.4.0 (22 Jul 2015) 22 Jul 2015; Ian Delaney <idella4@gentoo.org> +roccat-tools-3.4.0.ebuild: add -3.4.0 by request of proxy maintainer in bug #548388
Looks ok to me. I think this bug finally can be resolved (and the bug 555244 as well). @Perfect Gentleman, @wraeth Guys if you could try if everything is fine for you that would be good.
...and thanks everyone for patience and support!
Things appear to be working from my side - roccat-tools-3.5.0 builds with libgaminggear-0.10.1 without problem. Thanks.