--- Log opened Wed Mar 08 00:00:04 2023
02:50 < real_or_random> hebasto: ha apparently you push faster than I can comment :D 
02:58 < hebasto> :D
07:53 -!- hg [~halosghos@user/halosghost] has joined #secp256k1
08:26 -!- pakaro [~quassel@104.221.123.79] has joined #secp256k1
08:42 -!- Apocalyptic_ [~Apocalypt@user/apocalyptic] has quit [Quit: Quit]
08:49 -!- Apocalyptic [~Apocalypt@user/apocalyptic] has joined #secp256k1
09:01 -!- jonatack1 [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.8]
09:01 -!- pakaro [~quassel@104.221.123.79] has quit [Ping timeout: 252 seconds]
09:02 -!- pakaro [~quassel@142.243.254.224] has joined #secp256k1
09:02 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
09:04 < real_or_random> hebasto: happy with https://github.com/bitcoin-core/secp256k1/pull/1225#issuecomment-1460497006 ?
09:11 < hebasto> real_or_random: ack
09:39 < hebasto> real_or_random: mark a checkbox (about changelog entry) as done in https://github.com/bitcoin-core/secp256k1/pull/1113#issuecomment-1453785807?
09:59 -!- pakaro [~quassel@142.243.254.224] has quit [Remote host closed the connection]
10:01 -!- pakaro [~quassel@142.243.254.224] has joined #secp256k1
10:14 < hebasto> real_or_random: wrt https://github.com/bitcoin-core/secp256k1/pull/1113#discussion_r1129842212 -- do you want me to open a PR? or you can add a fix into #1226?
10:23 < real_or_random> hebasto or cfields: quick review of https://github.com/bitcoin-core/secp256k1/pull/1227 ?
10:34 < real_or_random> let me merge this
10:37 < real_or_random> ... waiting for too many local and automatic pre-merge checks ... 
10:40 < real_or_random> nickler sipa: should we rebase the release PR on master to have clean CI run? or just go ahead? 
10:41 < sipa> I don't expect any problems, but it's probably better procedure to rebase it, so CI actual tests the exact release git tree?
10:41 < sipa> *actually
10:42 < real_or_random> yeah I guess so
10:42 < real_or_random> CI merges with master automatically but it's not guaranteed to be a non-ff merge
10:43 < real_or_random> *ff merge
10:48 < real_or_random> (afk for ~45 minutes)
10:49 -!- pakaro [~quassel@142.243.254.224] has quit [Ping timeout: 248 seconds]
10:55 < nickler> I rebased it
11:01 -!- pakaro [~quassel@142.243.254.224] has joined #secp256k1
11:11 -!- pakaro [~quassel@142.243.254.224] has quit [Ping timeout: 248 seconds]
11:30 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
11:31 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
11:43 < real_or_random> oh https://github.com/bitcoin-core/secp256k1/pull/1227 ignores the "maintenance release" section entirely 
11:43 < real_or_random> no wrong link
11:43 < real_or_random> https://github.com/bitcoin-core/secp256k1/pull/1226
12:13 < sipa> afk for ~30 min
12:20 < real_or_random> I was sanity-checking make install results for both build systems. Now after today's discussion about semver,  I wondered if this line should be "SameMinorVersion" instead https://github.com/bitcoin-core/secp256k1/blob/10602b0030e67c830596e08ffc775039ee0b2607/src/CMakeLists.txt#L144
12:21 < real_or_random> This is for discovering build deps. Basically CMake's replacement for pkgconfig. And this would now say that versions are compatible if the major version agrees. But as long as we have a 0 there, that's strictly speaking wrong
12:22 < hebasto> "discussion about semver" -- where?
12:25 < hebasto> I mean, if it was public, ofc
12:26 < sipa> yes in 1223
12:27 < real_or_random> and yet another nit: cmake sets the project name to secp256k1 whereas configure sets it to libsecp256k1
12:27 < hebasto> oh, I missed that SemVer was also mentioned there. Thanks!
12:29 < real_or_random> I guess it's better to keep them consistent, to avoid any packaging/dependency confusion. That's a second nit that would probably better addressed before a release. We could still correct afterwards but changing the project name is not nice for users either.
12:30 < real_or_random> sorry, we should have looked at "make install" more closely when reviewing the PR. Checking installation this was just a thought I had now for the release 
12:32 < sipa> With cmake, the build artefacts seem to end up in build/src/, while I'd expect them in build/. Is that intentional?
12:32 < sipa> This may also be something we'd rather not break later on.
12:34 < real_or_random> (I think I did the same install checking last time... Added a note here https://github.com/bitcoin-core/secp256k1/issues/1176#issuecomment-1460841336)
12:35 < real_or_random> sipa: hm I suspect this is because src/ has its own CMakeLists.txt
12:35 < real_or_random> hebasto probably knows better. 
12:35 < hebasto> ^^ corretc
12:35 < hebasto> * correct
12:35 < real_or_random> the question is whether we care 
12:36 < real_or_random> given that the location is anyway different (out-of-tree vs in-tree)
12:36 < real_or_random> (well, in fact autotools supports out-of-tree but noone uses it ^^)
12:37 < hebasto> so, we are interested to get all build artifacts in the root of build tree, right?
12:38 < sipa> I'm not sure if I'm interested in anything! If this is what typical cmake users would expect, great... it's just not what I'd have expected :)
12:40 < real_or_random> my feeling is that it won't matter. it's really what make install is supposed to be abstract away from
12:40 < sipa> I guess with well-supported integration into user applications (find_package, include_subdirectory) it also doesn't matter, because even if it's changed, it'll get linked correctly.
12:40 < real_or_random> and installing is what all sane distro packages use
12:40 < sipa> Right, and also what real_or_random said.
12:41 < real_or_random> hebasto: does cmake encourage having CMakeLists.txt in subdirs?
12:41 < hebasto> yes
12:41 < hebasto> a structure approach
12:41 < real_or_random> I mean you can do this stuff autotools too, but it comes with a bunch of glitches
12:42 < hebasto> for cmake it is a "native" approach
12:42 < real_or_random> (I guess that's a statement which is generally true for autotools ^^)
12:42 < nickler> what's blocking the release right now?
12:42 < hebasto> but again, cmake is quite flexible to place build artifacts anywhere users like
12:42 < real_or_random> then I think we should leave it as is
12:44 < real_or_random> nickler: we're discussing three nits that appeared when looking at the cmake output.
12:44 < sipa> Yeah, agree.
12:44 < real_or_random> 1) project name is secp256k1 in cmake but libsecp256k1 in autotools
12:45 < sipa> and 2) whether the build artefacts end up in build/ or in build/src/
12:46 < sipa> I think it'd be good to change the project name to libsecp256k1.
12:46 < sipa> Before release.
12:46 < real_or_random> 3) cmake's build dep discovery mechanism (read "pkgconfig equivalent") currently declares that versions are API compatible is major version is the same. but that's not correct, in particular given the discussion today. before 1.0.0, it should SameMinorVersion  -- it's literally changing one word in CMakeLists.txt
12:46 < hebasto> re (1) -- it is a difference for library users, and they will anyway replace something in their code with `find_package(secp256k1)`
12:47 < real_or_random> I also tend to think we should address 1)... Better to get this consistent now. 
12:47 < real_or_random> Same for 3). 
12:48 < real_or_random> Both are three-char diffs, so I'm not worried about reviewing them now. Will delay ~10 min ^^ 
12:48 < hebasto> I still don't get why (1) is an issue?
12:48 < hebasto> (3) -- agree
12:49 < real_or_random> I can't give you a definitive example but ... let's say a distro package wants to have a name for the library 
12:49 < real_or_random> this may be autogenerated from the build system 
12:50 < sipa> First example I think about checking: https://github.com/ridiculousfish/libdivide/blob/master/CMakeLists.txt
12:50 < sipa> uses "libdivide" as library name
12:50 < real_or_random> and then both systems should output the same.. It's already confusing that we have the two names. But builds have always used the "lib" prefix
12:51 < hebasto> that is automatic for library targets
12:51 < real_or_random> sipa: yeah, also the readme says "lib" 
12:52 < real_or_random> I guess I'm not sure whether it's a problem, but making it consistent is cheap and then I know it's not a problem 
12:53 < hebasto> ok
12:54 < sipa> I mean the question I think is whether we think of the project's name as "secp256k1" or "libsecp256k1", and to me, it's the latter since many years. It's a historical accident that the repository isn't named that way too.
12:54 < real_or_random> and I suggest not rebasing again after the two patches. no need to wait for macos CI again, unless someone insists ^^
12:54 < sipa> And I guess the API call prefixes...
12:54 < sipa> And this channel...
12:54 < sipa> Hmm.
12:54 < real_or_random> sipa: okay I had the same thought but I never heard it from you. then we agree
12:55 < real_or_random> no the prefixes are pragmatic
12:55 < real_or_random> sure you call into a "lib". good luck with autocomplete if all your libs use "lib"
12:55 < real_or_random> I've seen this in other libs too.
12:55 < sipa> libc_memcmp !
12:56 < hebasto> what about configuration variable name `SECP256K1_*` prefix?
12:56 < real_or_random> LOL okay that name is really an exception. I mean "c_memcmp" would really be confusing, hm?
12:57 < real_or_random> hebasto: I think this shares the same pragmatic reasoning as for API names
12:57 < real_or_random> and #defins
12:57 < sipa> https://github.com/bitcoin-core/secp256k1/commit/3f37bcc297eabd8127f84c9326da58fca6298028
12:57 < sipa> 9 years ago, README.md added, called the project "libsecp256k1"
12:58 < hebasto> no objections :)
12:58 < real_or_random> "This library is experimental, so use at your own risk." how it started
12:58 < real_or_random> ok, who wants to create the PR?
12:59 < real_or_random> how it's going: turned out it was OpenSSL which was experimental :P 
12:59 < hebasto> will we move build artifacts?
12:59 < sipa> I'd say don't move artifacts.
13:00 < real_or_random> yep, don't
13:00 < hebasto> I'll open PR
13:00 < real_or_random> nice
13:01 < sipa> thanks!
13:02 < real_or_random> sipa: something completely different... I'm curious whether you had benchmarked https://github.com/bitcoin-core/secp256k1/pull/1217
13:02 < sipa> I haven't.
13:03 < real_or_random> ok, don't
13:03 < real_or_random> we'd just risk figuring out that compilers are strange
13:04 < hebasto> `SameMinorVersion` is available in CMake 3.11+ -- bump minimum version?
13:04 < real_or_random> (don't get me wrong , I have not benchmarked it either ^^)
13:04 < real_or_random> hebasto: oops I missed that
13:04 < hebasto> https://cmake.org/cmake/help/latest/release/3.11.html
13:04 < sipa> I'm leaning towards keeping SameMajorVersion.
13:04 < real_or_random> so much about 10 min
13:05 < real_or_random> yeah, let's keep it for now.
13:05 < hebasto> kk
13:05 < real_or_random> Increasing minimum cmake version is probably fine but requires more thought
13:05 < real_or_random> and will unlock a bunch of other tricks
13:06 < sipa> cmake 3.1 is from 2015
13:06 < sipa> cmake 3.11 is from 2018
13:08 < real_or_random> https://repology.org/project/cmake/versions
13:09 < real_or_random> debian 10 is the oldest active debian and it has 3.13... so should be fine
13:10 < sipa> But that's a discussion we can also have later.
13:11 < real_or_random> but right
13:11 < real_or_random> *right
13:11 < real_or_random> for example, ubuntu 18.04 has 3.10... :D
13:12 < real_or_random> (I really find it amusing to look at this page with my arch linux system.)
13:13 < real_or_random> this is interesting by the way: https://repology.org/project/libsecp256k1/versions :D
13:14 < sipa> looks unmaintained
13:16 < real_or_random> totally
13:25 < hebasto> https://github.com/bitcoin-core/secp256k1/pull/1229
13:30 < hebasto> libsecp256k1 is able to be compiled with gcc 4.8, maybe even with older one. So, initially, I've chosen the oldest reasonable CMake version to support
13:31 < real_or_random> CI really loves us today lol
13:31 < sipa> hebasto:  Yes, I think that makes sense.
13:31 < real_or_random> hebasto: hehe have you tried 4.8?
13:32 < hebasto> yes, at some point on ubuntu bionic
13:34 < hebasto> or previous ubuntu's lts...
13:37 < real_or_random> hebasto: I suspect you changed the `target_link_libraries` for a reason?
13:37 < real_or_random> because "lib" is prepended automatically?
13:37 < hebasto> yes
13:38 < real_or_random> but does it work if you keep lib?
13:39 < hebasto> it will work
13:39 < hebasto> only build artifact will be `liblibsecp256k1.a`
13:40 < hebasto> actually, three entities were renamed: a project, a shared library and a static library
13:40 < sipa> oh, i see the rationale for changing things
13:41 < real_or_random> ah no, it won't work .. /usr/bin/ld: cannot find -llibsecp256k1: No such file or directory
13:41 < real_or_random> okay yes... then let's keep the PR as is? I still think it's an improvement
13:42 < hebasto> ^^ I'm not sure all renamings are consistent in that case
13:42 < real_or_random> output looks good
13:42 < hebasto> and `make install`?
13:43 < real_or_random> for clarity, that error message appeared when I changed it in to libsecp256k(_static) when linking examples
13:43 < real_or_random> so in target_link_libraries in examples/
13:44 < real_or_random> https://www.irccloud.com/pastebin/YWcAKj4o/
13:45 < real_or_random> looks good to me
13:45 < hebasto> cool
13:46 < sipa> Looks good
13:48 < hebasto> wait, need to update release docs as well
13:49 < real_or_random> where?
13:49 < hebasto> sorry, nm
13:49 < hebasto> https://github.com/bitcoin-core/secp256k1/pull/1226 is not merged yet
13:50 < real_or_random> right yes, and those don't need to be correct in the release, I suppose :D
13:53 < sipa> make -j check doesn't actually parallellize in the cmake build, which is a bit unfortunate
13:53 < real_or_random> we can add it to the list
13:54 < hebasto> `ctest` should
13:55 < real_or_random> ctest -j at least
13:55 < hebasto> right
13:57 < real_or_random> sipa: can you merge https://github.com/bitcoin-core/secp256k1/pull/1229 ?
13:59 < sipa> Done.
13:59 < real_or_random> nice. ok.
13:59 < real_or_random> I already ACKed the release PR
14:00 < nickler> I need to rebase
14:01 < real_or_random> lol argh
14:01 < nickler> done
14:01 < real_or_random> right, it's in the same line :X
14:37 < real_or_random> here we go https://github.com/bitcoin-core/secp256k1/releases/tag/v0.3.0
14:37 < sipa> \o/
14:38 < sipa> \o \o/ o//
14:38 < real_or_random> :)
14:39 < real_or_random> diff is larger than I expected: https://github.com/bitcoin-core/secp256k1/compare/v0.2.0...v0.3.0 good to see that we got some stuff done
14:39 < hebasto> 🔥
14:39 < sipa> Jacobi symbols I guess are a non-trivial portion of the code (but unused so far...)
14:41 < real_or_random> yes, jacobi and cmake were the two big ones. plus a bunch of small improvements and fixes, as always 
14:44 < real_or_random> hebasto: thanks for all the build work
14:45 < hebasto> it was my honor
14:45 < hg> 🙌
14:47 < real_or_random> sipa: do we have other release channels?
14:48 < real_or_random> last time we wrote to the list.
14:48 < real_or_random> I think that's appropriate
14:48 < sipa> Yeah I'm not sure this warrants informing the list.
14:54 < real_or_random> I think yes, Bitcoin Core and other releases are announced there too 
14:55 < real_or_random> I expect that most of our serious users read there
14:56 < real_or_random> but yeah, I guess a lot of relevant libraries don't announce their releases there
15:27 -!- hg [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.8]
--- Log closed Thu Mar 09 00:00:05 2023