19:00:31 <wumpus> #startmeeting
19:00:31 <lightningbot> Meeting started Thu May 14 19:00:31 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:31 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:38 <kanzure> hi
19:00:44 <sipsorcery> hi
19:00:53 <elichai2> Hi
19:00:55 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
19:00:57 <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
19:01:00 <jonasschnelli> Hi
19:01:04 <hebasto> hi
19:01:05 <jnewbery> hi
19:01:08 <fjahr> hi
19:01:10 <jkczyz> hi
19:01:33 <meshcollider> hi
19:01:35 <aj> hi
19:01:48 <jeremyrubin> hola
19:02:07 <wumpus> no proposed meeting topics in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt (only a suggestion for high prio for review)
19:02:48 <achow101> hi
19:03:04 <jeremyrubin> w.r.t. hi prio, i'd like to get the mempool project back on track it's review blocked
19:03:15 <sipa> i have a topic: ok to update to boost 1.59? and if so, when?
19:03:19 <wumpus> any any last minute proposals?
19:03:51 <wumpus> sipa: sgtm (though I'm not sure everyone is here wrt that discussion)
19:04:01 <wumpus> #topic High priority for review
19:04:35 <wumpus> Add #18638 to high prio (MarcoFalke, not actually a topic)
19:04:37 <gribble> https://github.com/bitcoin/bitcoin/issues/18638 | net: Use mockable time for ping/pong, add tests by MarcoFalke · Pull Request #18638 · bitcoin/bitcoin · GitHub
19:05:01 <jnewbery> Could we add #18960 as a blocker?
19:05:02 <gribble> https://github.com/bitcoin/bitcoin/issues/18960 | [indexes] Add compact block filter headers cache by jnewbery · Pull Request #18960 · bitcoin/bitcoin · GitHub
19:05:26 <wumpus> sure
19:05:59 <wumpus> added
19:06:06 <jnewbery> thanks!
19:06:58 <wumpus> https://github.com/bitcoin/bitcoin/projects/8   6 blockers, 1 bugfix, 4 chasing concept ACK now
19:07:21 <jeremyrubin> Can we add https://github.com/bitcoin/bitcoin/pull/18191?
19:07:24 <wumpus> jeremyrubin: do you have any specific suggestions wrt prs?
19:07:28 <wumpus> ah thanks
19:08:13 <wumpus> added
19:09:28 <wumpus> #topic required boost to 1.59 (sipa)
19:09:50 <sipa> hi
19:10:04 <wumpus> see also  #8875
19:10:04 <sipa> i'm considering various approaches to improving to some of the p2p tx download logic
19:10:05 <gribble> https://github.com/bitcoin/bitcoin/issues/8875 | Bump minimum required Boost version · Issue #8875 · bitcoin/bitcoin · GitHub
19:10:51 <sipa> and one of them would rely on boost multi_index's ranked indexes
19:11:00 <sipa> which were added in boost 1.59
19:11:14 <sipa> so i was wondering if that's a possibility for 0.21
19:11:23 <sipa> or if i should consider other options (which i may do anyway)
19:11:24 <wumpus> that seems a fair enough reason
19:11:42 * luke-jr grumbles about RHEL/CentOS packages being hard to search
19:11:49 <wumpus> I think the most important thing to check is the versions in currently supported linux distros for building
19:12:14 <wumpus> "Version 1.59.0  August 13th, 2015 15:23 GMT" that sounds old enough, but knowing what old crap some distros ship with, it doesn't say everything
19:12:42 <sipa> well if we're going to be building with c++17, it seems we'd be relying on compilers newer than that anyway
19:13:01 <hebasto> https://github.com/bitcoin/bitcoin/pull/16381#issuecomment-511277755
19:13:03 <wumpus> yes
19:13:16 <jeremyrubin> sipa: ranked indexes look pretty cool
19:13:21 <sipa> they're very cool
19:13:32 <luke-jr> sounds like RHEL/CentOS 8 has boost 1.66
19:13:56 <wumpus> sipa: the dumbest way to find out would be to do a PR that uses that feature and see if it passes travis :)
19:14:14 <wumpus> luke-jr: oh! that's surprisingly new
19:14:14 <luke-jr> Debian has 1.67
19:14:40 <sipa> ok, will try opening a dummy PR and see what happens
19:14:43 <sipa> good enough for me
19:14:48 <jeremyrubin> does it make sense to do a minimum bump for feature or to bump to the highest minimum target we support?
19:14:51 <luke-jr> wumpus: not 100% sure
19:15:07 <wumpus> well sipa has a good reason now
19:15:08 <jeremyrubin> sipa: maybe check there's no bug-fixes to that new functionality in newer versions?
19:15:22 <wumpus> the reason #16381 was closed is that it wasn't important/urgent at the time
19:15:23 <gribble> https://github.com/bitcoin/bitcoin/issues/16381 | Set minimum required Boost to 1.53.0 by hebasto · Pull Request #16381 · bitcoin/bitcoin · GitHub
19:15:36 <sipa> 1.64 has a bug fix related to ranked indices
19:15:56 <jeremyrubin> sipa: how severe?
19:15:58 <sipa> but the bug is just something that doesn't compile, which should
19:16:01 <sipa> so not severe at all
19:16:21 <wumpus> "it's eight years old" isn't enough to bump a minimum version, "I need this new data structure" well might be
19:16:58 <luke-jr> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/8.0_release_notes/index "Boost updated to version 1.66"
19:17:08 <wumpus> we already use boost 1.70 in depends so that's definitely new enough
19:17:15 <sipa> oh!
19:17:16 <sipa> ok
19:17:38 <wumpus> so yeah the current version used for gitian builds doesn't need to be bumped, only the minimum version
19:17:43 <sipa> that's enough for my topic
19:17:45 <jeremyrubin> sipa: are you adding this to mempool or to a diff data structure?
19:17:48 <wumpus> (supported at all)
19:18:07 <luke-jr> Ubuntu LTS is at 1.71
19:18:14 <luke-jr> Arch has 1.72
19:18:15 <jeremyrubin> Just worried that if it goes to mempool multiindex it looks like there's a non-trivial perfromance overhead on all erases
19:18:24 <luke-jr> Gentoo stablre is 1.72
19:18:25 <wumpus> if luke-jr  is right it's complely uncontroversial to bump the minimum to 1.59
19:18:28 <jeremyrubin> but this is less build systemy and more about how you're using it
19:18:46 <wumpus> (it likely depends on CenOS which is alwasys slowest)
19:19:18 <luke-jr> SuSE is 1.66
19:19:25 <sipa> jeremyrubin: no, this is unrelated to mempool
19:19:29 <luke-jr> any other popular distros these days?
19:19:40 <sipa> it's in net processing
19:19:57 <jeremyrubin> cool looking forward to seeing it.
19:20:48 <jeremyrubin> use might actually have some speedups for mempool come to think of it for the eviction logic & mining logic. will noodle on that.
19:21:50 <wumpus> any other topics for this week?
19:21:59 <wumpus> PSA: we're wrapping up 0.20.0rc2 at the moment
19:22:05 <sipa> they add 1 pointer memory usage per entry, fwiw (compared to ordered_index)
19:22:11 <luke-jr> wumpus: do you want me to try to reduce the size of my 0.20 release tarball fixes PR?
19:22:17 <wumpus> #18973
19:22:19 <gribble> https://github.com/bitcoin/bitcoin/issues/18973 | [0.20] Final backports for rc2 by fanquake · Pull Request #18973 · bitcoin/bitcoin · GitHub
19:22:22 <wumpus> (finally)
19:22:24 <jeremyrubin> sipa: it's the log n erase that's more worrisome
19:22:46 <wumpus> luke-jr: sure, but we're not going to hold up the rc on it
19:23:37 <luke-jr> wumpus: it's a security violation for users who build from source
19:23:45 <luke-jr> to answer how relevant it is
19:24:08 <wumpus> how so?
19:24:11 <luke-jr> and can result in leaking user private info to the network
19:24:25 <luke-jr> wumpus: it's looking at every parent directory to the source code for a git repo
19:24:33 <wumpus> I mean, it's been absurd how long it's taking to roll this release
19:24:33 <luke-jr> and taking whatever HEAD hash it finds into the version number
19:25:03 <luke-jr> pulling a hash out of an unrelated git repo the user might have, and publishing it, isn't very nice
19:25:16 <wumpus> I agree
19:25:19 <sipa> that sounds like something we should fix
19:25:29 <luke-jr> (Gentoo will kill the build instead)
19:26:01 <wumpus> but honestly we should cut a release at some point, there's aalways some edge case
19:26:13 <luke-jr> this is a regression, too
19:27:16 <wumpus> also #18902 rewrites a large part of the gitian descriptor and changes 6 files, can't this be fixed with some small patch?
19:27:18 <gribble> https://github.com/bitcoin/bitcoin/issues/18902 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #18902 · bitcoin/bitcoin · GitHub
19:27:32 <luke-jr> probably
19:27:55 <luke-jr> I was trying to avoid conflicts with the autogen fix, but I guess we're missing that?
19:28:04 <wumpus> in any case: I agree it should be fixed, but I don't think it's terribly urgent
19:28:39 <hebasto> as a workaround a user could use BITCOIN_GENBUILD_NO_GIT variable
19:28:59 <luke-jr> maybe a release notes mention of the known issues
19:29:07 <wumpus> yes
19:29:21 <wumpus> I think that's fine
19:31:11 <luke-jr> current draft is in wiki still? or git?
19:31:56 <wumpus> wiki https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.20.0-Release-Notes-Draft
19:32:15 <luke-jr> k, I'll see about writing something up for that
19:32:22 <wumpus> thanks!
19:32:56 <luke-jr> should I reduce the footprint of #18902 and/or #18909 also?
19:32:58 <gribble> https://github.com/bitcoin/bitcoin/issues/18902 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #18902 · bitcoin/bitcoin · GitHub
19:32:59 <gribble> https://github.com/bitcoin/bitcoin/issues/18909 | [0.20] Fix release tarball by luke-jr · Pull Request #18909 · bitcoin/bitcoin · GitHub
19:33:58 <luke-jr> would be nice to just get 18902 merged to master as-is to fix all the issues at once :x   but maybe reducing 18909 makes more sense
19:35:30 <wumpus> fwiw the git_check_in_repo() check looks straightforward enough
19:35:42 <wumpus> why isn't that enough?
19:36:25 <wumpus> (or alternatively, check if a .git is in the top level of the source directory)
19:37:11 <wumpus> besides that change in genbuild.sh, are any other changes needed to fix this?
19:37:57 <hebasto> it is all about "version hack"
19:38:18 <hebasto> in gitian builds
19:38:28 <luke-jr> wumpus: we'd need to restore the "version hack"
19:38:38 <wumpus> luke-jr talks about a security vulnerability importing data from a git repository above the bitcoin one, this can be avoided by checking in genbuild that we're really in a git repo right?
19:38:40 <luke-jr> the genbuild changes in 18902 are a proper fix for that
19:39:03 <wumpus> (I mean, in the right git repo)
19:39:22 <wumpus> yes my question is why isn't that the only change needed?
19:40:16 <wumpus> hebasto: so we can fix this by reverting a change too?
19:40:23 <hebasto> #18349 probably has simpler approach
19:40:24 <luke-jr> those are the only commits specific to 18902 - the other 3 are inherited from 18818
19:40:25 <gribble> https://github.com/bitcoin/bitcoin/issues/18349 | build: Fix quick hack for version string in releases by hebasto · Pull Request #18349 · bitcoin/bitcoin · GitHub
19:40:30 <wumpus> (at least in 0.20)
19:41:04 <hebasto> wumpus: not sure
19:41:44 <luke-jr> reverting a change would be the first commit of 18902 + restoring the "version hack"
19:42:05 <wumpus> ok
19:42:10 <luke-jr> (to literally revert, would be undoing all of the git-archive stuff)
19:42:18 <wumpus> so it's much more complex than I thought
19:42:38 <luke-jr> wumpus: it can be simplified with a few hours I suspect
19:42:41 <wumpus> let's just add a note to the release notes then
19:42:50 <wumpus> any other topics?
19:44:05 <wumpus> #endmeeting