$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
I have not forgotten about this, but upstream has not real interest supporting the new version at all. The changes are significant and no one has sent a PR for it. If someone needs to remove the older version of sdrplay they are welcome to simply mask the use flag or remove it. Otherwise this stays pending for now.
