$summary.
Upstream urh is pretty responsive, and I have reported this to them. It looks like sdrplay made significant changes in their 3.x series (they refer to it as api 3), I'm not sure how significant. Hopefully upstream urh can solve this in a reasonable amount of time, if not, please feel free to mask the sdrplay use flag with a note pointing to this bug.
any progress here at all?
upstream seems to have no interest here https://github.com/jopohl/urh/issues/783 We could mask the use flag and remove it if idl0r really wants to remove the old sdrplay version. If it's not a big deal I'd prefer to keep it so people can have working urh with their sdrplay, but I won't be angry if we need to remove this flag.
We can keep the older version if it's causing trouble. I haven't used it at all for quite some time yet so if anyone wants to take over maintainership, feel free.
If you want to keep it, then please bump to EAPI-8.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bb60618fb5a9d873880b5b2d5388fd684068342e commit bb60618fb5a9d873880b5b2d5388fd684068342e Author: Christian Ruppert <idl0r@gentoo.org> AuthorDate: 2024-05-21 14:54:26 +0000 Commit: Christian Ruppert <idl0r@gentoo.org> CommitDate: 2024-05-21 14:54:26 +0000 net-wireless/sdrplay: EAPI 6->8 Bug: https://bugs.gentoo.org/867280 Signed-off-by: Christian Ruppert <idl0r@gentoo.org> net-wireless/sdrplay/sdrplay-2.13.1-r1.ebuild | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
Not blocking EAPI=6 since both packages are EAPI=8
