Complaints about libsecp256k1-so.2 not found. Here is a trivial fix: diff --git a/net-misc/electrum/electrum-4.5.8.ebuild b/net-misc/electrum/electrum-4.5.8.ebuild index 7a63e2d4f444..c180bbd37206 100644 --- a/net-misc/electrum/electrum-4.5.8.ebuild +++ b/net-misc/electrum/electrum-4.5.8.ebuild @@ -27,7 +27,7 @@ REQUIRED_USE="|| ( cli ncurses qt5 )" RDEPEND=" ${PYTHON_DEPS} - dev-libs/libsecp256k1 + <dev-libs/libsecp256k1-0.6 >=dev-python/aiohttp-socks-0.8.4[${PYTHON_USEDEP}] =dev-python/aiorpcx-0.23*[${PYTHON_USEDEP}] >=dev-python/attrs-20.1.0[${PYTHON_USEDEP}]
or just : # cd /usr/lib64 && ln -s libsecp256k1.so.5.0.0 libsecp256k1.so.2
(In reply to Christophe PEREZ from comment #1) > or just : > # cd /usr/lib64 && ln -s libsecp256k1.so.5.0.0 libsecp256k1.so.2 Please don't do that.
(In reply to Sam James from comment #2) > (In reply to Christophe PEREZ from comment #1) > > or just : > > # cd /usr/lib64 && ln -s libsecp256k1.so.5.0.0 libsecp256k1.so.2 > > Please don't do that. If no choice, and need to use electrum... The same as using: # add libversion 5 as tested # sed -i 's/tested_libversions = \[2, 1, 0, \]/tested_libversions = [5, 2, 1, 0, ]/' /usr/lib/python3.12/site-packages/electrum/ecc_fast.py
libsecp256k1.so.5 and libsecp256k1.so.2 do not have compatible ABIs. (That's why they have different sonames.) So you can't just alias them and call it a day. You're likely to get crashes at best or subtly incorrect run-time behavior at worst. You should file a report upstream (on the Electrum project) if they've fallen behind the current libsecp256k1 ABI. In the meantime, yes, the net-misc/electrum ebuild should be modified to specify an upper version bound on dev-libs/libsecp256k1, as shown in comment #0.
A quick fix for those who do not wish to wait this bug's resolution is emerge -a =dev-libs/libsecp256k1-0.5.1 Which will downgrade to a working version of libsecp256k1, asking for confirmation before proceeding. In my system there were no conflicts, only Electrum uses it, so it was a breeze. You can check which packages depend on it on your system with: equery d dev-libs/libsecp256k1
(In reply to Alef Farah from comment #5) > emerge -a =dev-libs/libsecp256k1-0.5.1 And to make your selection permanent, you can add this line to your /etc/portage/package.accept_keywords: >=dev-libs/libsecp256k1-0.6 -* Then Portage won't keep trying to upgrade it.
(In reply to Sam James from comment #2) > (In reply to Christophe PEREZ from comment #1) > > or just : > > # cd /usr/lib64 && ln -s libsecp256k1.so.5.0.0 libsecp256k1.so.2 > > Please don't do that. Meanwhile they do a worse thing: load_library() in ecc_fast.py tries to load libsecp256k1.so.2, libsecp256k1.so.1, libsecp256k1.so.0, but libsecp256k1 0.6.0 provides libsecp256k1.so.5! Upstream bug ticket: https://github.com/spesmilo/electrum/issues/9315 Perhaps until they learn to identify libraries correctly, this workaround could be included in the ebuild? Couldn't be worse than the current state (doesn't run).
(In reply to Paweł Metelski from comment #7) > Meanwhile they do a worse thing: > load_library() in ecc_fast.py tries to load libsecp256k1.so.2, > libsecp256k1.so.1, libsecp256k1.so.0 That's not bad, assuming they've verified that their code works with each of those ABIs. Most likely they just need to add .5 to that list after they've verified that .5 hasn't introduced any changes that break their calls into it (or they fix their calls if it has).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=80bedd835f50a7a2a5cae30500ff01e0234d304d commit 80bedd835f50a7a2a5cae30500ff01e0234d304d Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2025-01-01 06:32:40 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2025-01-01 06:42:57 +0000 net-misc/electrum: Require <libsecp256k1-0.6 Closes: https://bugs.gentoo.org/946232 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-misc/electrum/{electrum-4.5.8.ebuild => electrum-4.5.8-r1.ebuild} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
