Skip to content

Support latest Debian libsecp256k1 package #8185

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 3, 2023

Conversation

romanz
Copy link
Contributor

@romanz romanz commented Feb 3, 2023

@romanz
Copy link
Contributor Author

romanz commented Feb 3, 2023

It's available as:

# apt install libsecp256k1-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libpkgconf3 libsecp256k1-1 pkg-config pkgconf pkgconf-bin
The following NEW packages will be installed:
  libpkgconf3 libsecp256k1-1 libsecp256k1-dev pkg-config pkgconf pkgconf-bin
0 upgraded, 6 newly installed, 0 to remove and 40 not upgraded.
Need to get 2432 kB of archives.
After this operation, 2817 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian testing/main amd64 libpkgconf3 amd64 1.8.1-1 [36.1 kB]
Get:2 http://deb.debian.org/debian testing/main amd64 libsecp256k1-1 amd64 0.2.0-2 [1157 kB]
Get:3 http://deb.debian.org/debian testing/main amd64 pkgconf-bin amd64 1.8.1-1 [29.5 kB]
Get:4 http://deb.debian.org/debian testing/main amd64 pkgconf amd64 1.8.1-1 [25.9 kB]
Get:5 http://deb.debian.org/debian testing/main amd64 pkg-config amd64 1.8.1-1 [13.7 kB]
Get:6 http://deb.debian.org/debian testing/main amd64 libsecp256k1-dev amd64 0.2.0-2 [1170 kB]
Fetched 2432 kB in 1s (4244 kB/s)         
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libpkgconf3:amd64.
(Reading database ... 6009 files and directories currently installed.)
Preparing to unpack .../0-libpkgconf3_1.8.1-1_amd64.deb ...
Unpacking libpkgconf3:amd64 (1.8.1-1) ...
Selecting previously unselected package libsecp256k1-1:amd64.
Preparing to unpack .../1-libsecp256k1-1_0.2.0-2_amd64.deb ...
Unpacking libsecp256k1-1:amd64 (0.2.0-2) ...
Selecting previously unselected package pkgconf-bin.
Preparing to unpack .../2-pkgconf-bin_1.8.1-1_amd64.deb ...
Unpacking pkgconf-bin (1.8.1-1) ...
Selecting previously unselected package pkgconf:amd64.
Preparing to unpack .../3-pkgconf_1.8.1-1_amd64.deb ...
Unpacking pkgconf:amd64 (1.8.1-1) ...
Selecting previously unselected package pkg-config:amd64.
Preparing to unpack .../4-pkg-config_1.8.1-1_amd64.deb ...
Unpacking pkg-config:amd64 (1.8.1-1) ...
Selecting previously unselected package libsecp256k1-dev:amd64.
Preparing to unpack .../5-libsecp256k1-dev_0.2.0-2_amd64.deb ...
Unpacking libsecp256k1-dev:amd64 (0.2.0-2) ...
Setting up libpkgconf3:amd64 (1.8.1-1) ...
Setting up pkgconf-bin (1.8.1-1) ...
Setting up libsecp256k1-1:amd64 (0.2.0-2) ...
Setting up pkgconf:amd64 (1.8.1-1) ...
Setting up libsecp256k1-dev:amd64 (0.2.0-2) ...
Setting up pkg-config:amd64 (1.8.1-1) ...
Processing triggers for libc-bin (2.36-7) ...

# ls -l /usr/lib/x86_64-linux-gnu/libsecp256k1*
-rw-r--r-- 1 root root 1214390 Dec 27 12:11 /usr/lib/x86_64-linux-gnu/libsecp256k1.a
lrwxrwxrwx 1 root root      21 Dec 27 12:11 /usr/lib/x86_64-linux-gnu/libsecp256k1.so -> libsecp256k1.so.1.0.0
lrwxrwxrwx 1 root root      21 Dec 27 12:11 /usr/lib/x86_64-linux-gnu/libsecp256k1.so.1 -> libsecp256k1.so.1.0.0
-rw-r--r-- 1 root root 1202320 Dec 27 12:11 /usr/lib/x86_64-linux-gnu/libsecp256k1.so.1.0.0

@SomberNight
Copy link
Member

Thanks.
I guess this is related to bitcoin-core/secp256k1#1055.
Would the other cases above not have to be updated? Well, ok, not for the debian pkg ofc.

I also don't understand why our own contrib/make_libsecp256k1.sh script puts the old version number in the name of the generated file (after bumping the hardcoded git commit there)... Where is this .1 coming from? I guess autotools or similar is putting it there...

@SomberNight
Copy link
Member

I've added a follow-up in dd141c7 based on bitcoin-core/secp256k1#1055 (comment)

but I still don't understand why contrib/make_libsecp256k1.sh is creating dists with the old version number...
libsecp256k1.la, generated by libtool, still has the old version number for some reason.

. "$here/$pkgname/dist/lib/libsecp256k1.la"

SomberNight added a commit that referenced this pull request Feb 3, 2023
@SomberNight
Copy link
Member

ok, figured it out.
fixed in c66411f

@romanz romanz deleted the new-libsecp256k1 branch February 3, 2023 19:49
@romanz
Copy link
Contributor Author

romanz commented Feb 3, 2023

Many thanks!

@Kixunil
Copy link

Kixunil commented Feb 6, 2023

Oh, this may be a bad idea. libsecp256k1 is not considered stable and maybe shouldn't have been packaged.

See recent discussion here: rust-bitcoin/rust-secp256k1#566 (comment)
That one is Rust-related but unless Electrum has some protection against loaing the wrong library it still applies.

@SomberNight
Copy link
Member

SomberNight commented Feb 6, 2023

I don't fully understand what you mean.

  • wasn't the point of libsecp256k1 finally getting releases/tags that it's now ~stable? (at least for a given version number)
    • indeed many old .0 libs are likely not sufficient for us (recent ones are), but this PR and recent changes did not touch that
  • there's been a debian package of libsecp256k1 (and ubuntu, and probably other distros) for many years
  • this PR in particular has not changed much; electrum happily loaded any secp256k1 shared lib it found even before this. this PR and follow-ups just extended that to include the (now stable??) .1 version.
    • but note that a local .so is always preferred to a system one (so if you run ./contrib/make_libsecp256k1.sh yourself, or if you just use an appimage, distro installations are ignored)

What part specifically is the bad idea?

@Kixunil
Copy link

Kixunil commented Feb 9, 2023

Basically, I'm not really sure it's safe. Pinging @apoelstra if you have time could you give us a hint whether depending on Ubuntu -packaged libsecp256k1 is OK?

@apoelstra
Copy link

If it's the recently-released 0.2 then it should be fine.

We deliberately chose 0.2 because as far as we're aware, the "shouldn't have been packaged" packages used 0.1, so it should be easy to tell :).

SomberNight added a commit to SomberNight/electrum that referenced this pull request Apr 21, 2023
We don't actually need the development headers, instead using this as
a hack to be agnostic to the version scheme and pull in the latest.

related:
spesmilo#8185
spesmilo#8320
spesmilo#8328 (comment)

debian 11 (stable) only has libsecp256k1-0
debian 12 (testing) atm only has libsecp256k1-1
ubuntu 23.04 only has libsecp256k1-1
I expect libsecp256k1-2 might soon get packaged too, now that upstream secp released v0.3.0.
So what do tell users to install? well, turns out most distros have libsecp256k1-dev, which
just pull in the latest secp.
Caveat: if there is a new secp release that actually gets packaged on a distro before we can react,
then this new instruction will not work.
SomberNight added a commit to SomberNight/electrum that referenced this pull request Apr 21, 2023
We don't actually need the development headers, instead using this as
a hack to be agnostic to the version scheme and pull in the latest.

related:
spesmilo#8185
spesmilo#8320
spesmilo#8328 (comment)

debian 11 (stable) only has libsecp256k1-0
debian 12 (testing) atm only has libsecp256k1-1
ubuntu 23.04 only has libsecp256k1-1
I expect libsecp256k1-2 might soon get packaged too, now that upstream secp released v0.3.0.
So what do we tell users to install? well, turns out most distros have libsecp256k1-dev, which
just pulls in the latest secp.
Caveat: if there is a new secp release that actually gets packaged on a distro before we can react,
then this new instruction will not work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants