Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 548388 - sys-apps/roccat-tools-3.4.0 + sys-apps/roccat-tools-3.5.0 & dev-libs/libgaminggear-0.10.0: version bump
Summary: sys-apps/roccat-tools-3.4.0 + sys-apps/roccat-tools-3.5.0 & dev-libs/libgamin...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Dmitry Pisklov
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-02 09:25 UTC by Perfect Gentleman
Modified: 2015-07-23 00:48 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
3.3.0 ebuild workaround (roccat-tools-3.3.0.ebuild,2.30 KB, text/plain)
2015-05-14 08:18 UTC, Perfect Gentleman
Details
New ebuild for dev-libs/libgaminggear-0.9.0 (libgaminggear-0.9.0.ebuild,986 bytes, text/plain)
2015-05-26 21:07 UTC, Dmitry Pisklov
Details
New ebuild for sys-apps/roccat-tools-3.4.0 (roccat-tools-3.4.0.ebuild,2.43 KB, text/plain)
2015-05-26 21:07 UTC, Dmitry Pisklov
Details
New metadata.xml for sys-apps/roccat-tools-3.4.0 (metadata.xml,660 bytes, text/xml)
2015-05-26 21:08 UTC, Dmitry Pisklov
Details
New ebuild for sys-apps/roccat-tools-3.4.0 (roccat-tools-3.4.0.ebuild,2.63 KB, text/plain)
2015-05-27 20:44 UTC, Dmitry Pisklov
Details
New ebuild for sys-apps/roccat-tools-3.4.0 (roccat-tools-3.4.0.ebuild,2.66 KB, text/plain)
2015-05-28 10:05 UTC, Dmitry Pisklov
Details
New ebuild for sys-apps/roccat-tools-3.4.0 (roccat-tools-3.4.0.ebuild,2.67 KB, text/plain)
2015-06-28 12:22 UTC, Dmitry Pisklov
Details
New ebuild for dev-libs/libgaminggear-0.10.0 (libgaminggear-0.10.0.ebuild,1.05 KB, text/plain)
2015-06-28 12:23 UTC, Dmitry Pisklov
Details
Patch for /usr/portage/dev-libs/libgaminggear/files (libgaminggear-0.10.0-doc.patch,451 bytes, patch)
2015-06-28 12:24 UTC, Dmitry Pisklov
Details | Diff
New ebuild for sys-apps/roccat-tools-3.5.0 (roccat-tools-3.5.0.ebuild,2.67 KB, text/plain)
2015-06-30 16:53 UTC, Dmitry Pisklov
Details
New ebuild for sys-apps/roccat-tools-3.4.0 (roccat-tools-3.4.0.ebuild,2.21 KB, text/plain)
2015-07-19 19:56 UTC, Dmitry Pisklov
Details
New ebuild for sys-apps/roccat-tools-3.5.0 (roccat-tools-3.5.0.ebuild,2.21 KB, text/plain)
2015-07-19 19:57 UTC, Dmitry Pisklov
Details
New ebuild for sys-apps/roccat-tools-3.2.0-r1 (roccat-tools-3.2.0-r1.ebuild,2.31 KB, text/plain)
2015-07-19 19:57 UTC, Dmitry Pisklov
Details
New ebuild for sys-apps/roccat-tools-3.5.0-r1 (roccat-tools-3.5.0-r1.ebuild,2.67 KB, text/plain)
2015-07-19 19:57 UTC, Dmitry Pisklov
Details
New ebuild for dev-libs/libgaminggear-0.10.0-r1 (libgaminggear-0.10.0-r1.ebuild,1.09 KB, text/plain)
2015-07-19 19:58 UTC, Dmitry Pisklov
Details
New ebuild for dev-libs/libgaminggear-0.10.1 (libgaminggear-0.10.1.ebuild,1.09 KB, text/plain)
2015-07-20 19:28 UTC, Dmitry Pisklov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Perfect Gentleman 2015-05-02 09:25:12 UTC
roccat-tools-3.3.0 & libgaminggear-0.8 out.
Comment 1 Perfect Gentleman 2015-05-12 06:30:03 UTC
up
Comment 2 Dmitry Pisklov 2015-05-12 18:10:30 UTC
@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!
Comment 3 Perfect Gentleman 2015-05-14 08:17:03 UTC
(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
Comment 4 Perfect Gentleman 2015-05-14 08:18:14 UTC
Created attachment 403230 [details]
3.3.0 ebuild workaround
Comment 5 Dmitry Pisklov 2015-05-14 18:38:07 UTC
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
Comment 6 Perfect Gentleman 2015-05-15 11:25:23 UTC
(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.
Comment 7 Dmitry Pisklov 2015-05-16 08:56:28 UTC
Sorry man - why do you think Kova[+] requires Kone[+]? I don't see any mention of this on erazor_de's sourceforge page...
Comment 8 Perfect Gentleman 2015-05-16 09:06:18 UTC
(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/
Comment 9 Dmitry Pisklov 2015-05-16 09:12:21 UTC
I probably will need to check with the original developer - not sure this is intentional change.
Comment 10 Perfect Gentleman 2015-05-17 07:27:19 UTC
(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
Comment 11 Ian Delaney (RETIRED) gentoo-dev 2015-05-24 08:18:38 UTC
(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.
Comment 12 Perfect Gentleman 2015-05-25 07:16:24 UTC
sys-apps/roccat-tools-3.4.0 & dev-libs/libgaminggear-0.9: version bump
Comment 13 Dmitry Pisklov 2015-05-26 21:07:23 UTC
Created attachment 404024 [details]
New ebuild for dev-libs/libgaminggear-0.9.0
Comment 14 Dmitry Pisklov 2015-05-26 21:07:54 UTC
Created attachment 404026 [details]
New ebuild for sys-apps/roccat-tools-3.4.0
Comment 15 Dmitry Pisklov 2015-05-26 21:08:27 UTC
Created attachment 404028 [details]
New metadata.xml for sys-apps/roccat-tools-3.4.0
Comment 16 Perfect Gentleman 2015-05-27 02:12:46 UTC
CMake Error at CMakeLists.txt:84 (FIND_PACKAGE):
  find_package called with invalid argument "ON"

smth wrong with USE for lua.
Comment 17 Perfect Gentleman 2015-05-27 02:14:48 UTC
please, correct
>=dev-libs/libgaminggear-0.7 -> >=dev-libs/libgaminggear-0.9
Comment 18 Dmitry Pisklov 2015-05-27 20:44:10 UTC
Created attachment 404106 [details]
New ebuild for sys-apps/roccat-tools-3.4.0

Apologize - was drunk.
Now correct ebuild...
Comment 19 Perfect Gentleman 2015-05-28 02:34:13 UTC
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.
Comment 20 Dmitry Pisklov 2015-05-28 09:52:53 UTC
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.
Comment 21 Dmitry Pisklov 2015-05-28 10:05:23 UTC
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.
Comment 22 Perfect Gentleman 2015-05-28 11:12:20 UTC
now it works.
excellent.
thanx.
Comment 23 Ian Delaney (RETIRED) gentoo-dev 2015-05-30 14:01:49 UTC
shall attempt to complete this tomorrow
Comment 24 Ian Delaney (RETIRED) gentoo-dev 2015-05-31 05:52:49 UTC
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
Comment 25 Ian Delaney (RETIRED) gentoo-dev 2015-06-01 05:43:56 UTC
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
Comment 26 Dmitry Pisklov 2015-06-01 20:44:37 UTC
@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?
Comment 27 Ian Delaney (RETIRED) gentoo-dev 2015-06-03 11:41:07 UTC
(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
Comment 28 Dmitry Pisklov 2015-06-05 21:45:54 UTC
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
Comment 29 Ian Delaney (RETIRED) gentoo-dev 2015-06-06 07:09:34 UTC
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
Comment 30 Ian Delaney (RETIRED) gentoo-dev 2015-06-06 07:56:06 UTC
(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.
Comment 31 Dmitry Pisklov 2015-06-08 18:29:26 UTC
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.
Comment 32 Ian Delaney (RETIRED) gentoo-dev 2015-06-10 10:04:29 UTC
(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.
Comment 33 Pacho Ramos gentoo-dev 2015-06-10 20:42:42 UTC
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
Comment 34 Dmitry Pisklov 2015-06-28 12:22:22 UTC
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.
Comment 35 Dmitry Pisklov 2015-06-28 12:22:47 UTC
Created attachment 405908 [details]
New ebuild for sys-apps/roccat-tools-3.4.0
Comment 36 Dmitry Pisklov 2015-06-28 12:23:27 UTC
Created attachment 405910 [details]
New ebuild for dev-libs/libgaminggear-0.10.0
Comment 37 Dmitry Pisklov 2015-06-28 12:24:10 UTC
Created attachment 405912 [details, diff]
Patch for /usr/portage/dev-libs/libgaminggear/files
Comment 38 Ian Delaney (RETIRED) gentoo-dev 2015-06-30 15:24:54 UTC
(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.
Comment 39 Dmitry Pisklov 2015-06-30 16:51:17 UTC
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.
Comment 40 Dmitry Pisklov 2015-06-30 16:53:40 UTC
Created attachment 405998 [details]
New ebuild for sys-apps/roccat-tools-3.5.0
Comment 41 Ian Delaney (RETIRED) gentoo-dev 2015-07-01 00:50:26 UTC
(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.
Comment 42 Dmitry Pisklov 2015-07-02 10:51:00 UTC
OK please do as you think is better
Comment 43 Ian Delaney (RETIRED) gentoo-dev 2015-07-04 01:38:43 UTC
(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..
Comment 44 Dmitry Pisklov 2015-07-19 19:56:42 UTC
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.
Comment 45 Dmitry Pisklov 2015-07-19 19:57:00 UTC
Created attachment 407180 [details]
New ebuild for sys-apps/roccat-tools-3.5.0
Comment 46 Dmitry Pisklov 2015-07-19 19:57:28 UTC
Created attachment 407182 [details]
New ebuild for sys-apps/roccat-tools-3.2.0-r1
Comment 47 Dmitry Pisklov 2015-07-19 19:57:44 UTC
Created attachment 407184 [details]
New ebuild for sys-apps/roccat-tools-3.5.0-r1
Comment 48 Dmitry Pisklov 2015-07-19 19:58:31 UTC
Created attachment 407186 [details]
New ebuild for dev-libs/libgaminggear-0.10.0-r1
Comment 49 Dmitry Pisklov 2015-07-19 19:59:27 UTC
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
Comment 50 Perfect Gentleman 2015-07-20 04:40:54 UTC
libgaminggear-0.10.1 is out
Comment 51 Sam Jorna (wraeth) gentoo-dev 2015-07-20 13:05:54 UTC
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.
Comment 52 Dmitry Pisklov 2015-07-20 19:26:53 UTC
@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).
Comment 53 Dmitry Pisklov 2015-07-20 19:28:37 UTC
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.
Comment 54 Ian Delaney (RETIRED) gentoo-dev 2015-07-21 08:21:48 UTC
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
Comment 55 Dmitry Pisklov 2015-07-21 08:57:45 UTC
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
Comment 56 Ian Delaney (RETIRED) gentoo-dev 2015-07-21 15:15:00 UTC
(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.
Comment 57 Dmitry Pisklov 2015-07-21 16:49:27 UTC
(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.
Comment 58 Ian Delaney (RETIRED) gentoo-dev 2015-07-22 02:07:38 UTC
(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
Comment 59 Dmitry Pisklov 2015-07-22 14:37:50 UTC
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.
Comment 60 Dmitry Pisklov 2015-07-22 14:39:17 UTC
...and thanks everyone for patience and support!
Comment 61 Sam Jorna (wraeth) gentoo-dev 2015-07-23 00:48:51 UTC
Things appear to be working from my side - roccat-tools-3.5.0 builds with libgaminggear-0.10.1 without problem.

Thanks.