< bitcoin-git> [bitcoin] fjahr opened pull request #17843: wallet: Reset reused transactions cache (master...getbalances) https://github.com/bitcoin/bitcoin/pull/17843
< wumpus> heh thanks CubicEarth
< wumpus> happy 2020 everyone
< fanquake> wumpus ?
< wumpus> lets do my first 'git pull' of the repository this decade
< fanquake> Watch out for all the copyright headers ?
< wumpus> that causes make / ccache to forget everything resulting in a clean build for the new year!
< fanquake> heh. Looking forward to another decade of bitcoind!
< wumpus> yes!
< wumpus> what would be cool to merge as first PR?
< wumpus> #10785 would be nice
< gribble> https://github.com/bitcoin/bitcoin/issues/10785 | Serialization improvements by sipa . Pull Request #10785 . bitcoin/bitcoin . GitHub
< fanquake> Right now I can probably only tell you what would not be cool to merge
< wumpus> very futuristic to have improved serialization for the new decade
< wumpus> hehe yes
< sipa> agree! ;)
< fanquake> I'll be very biased, an suggest that #17787 is just a tiny bit "cool"
< gribble> https://github.com/bitcoin/bitcoin/issues/17787 | scripts: add MACHO PIE check to security-check.py by fanquake . Pull Request #17787 . bitcoin/bitcoin . GitHub
< sipa> MACHO does sound very cool
< fanquake> Got some pie as well. Sounds like a good deal all round
< wumpus> MACHO PIE
< wumpus> it's good branding for security features
< fanquake> macOS has all the cool flags heh
< wumpus> switching to macos this year because of the cool flags
< wumpus> fanquake: any idea about the travis error in that PR? "import configparser" fails in the python tests, seems unrelated
< wumpus> but it is on macos
< fanquake> Just watch out, you might run out of harddrive space if you do that #17827
< gribble> https://github.com/bitcoin/bitcoin/issues/17827 | Blocks directory on macOS uses more disk space than expected . Issue #17827 . bitcoin/bitcoin . GitHub
< fanquake> wumpus From what I could see, brew tries to upgrade Python, but fails during the linking step, so I assumed it was related to that. I can have a proper look into it tonight given it's affecting everything.
< wumpus> oh I seee now it fails everywhere
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/35fff5be60e8...0655c7a94cc9
< bitcoin-git> bitcoin/master 4ca92dc fanquake: scripts: add MACHO PIE check to security-check.py
< bitcoin-git> bitcoin/master 7c9e821 fanquake: scripts: add MACHO NOUNDEFS check to security-check.py
< bitcoin-git> bitcoin/master 0655c7a Wladimir J. van der Laan: Merge #17787: scripts: add MACHO PIE check to security-check.py
< bitcoin-git> [bitcoin] laanwj merged pull request #17787: scripts: add MACHO PIE check to security-check.py (master...add_macOS_to_security_check) https://github.com/bitcoin/bitcoin/pull/17787
< bitcoin-git> [bitcoin] emilengler closed pull request #17842: util: Check for curl in Posix PATH (master...2020-01-check-curl-path) https://github.com/bitcoin/bitcoin/pull/17842
< elichai2> how do people feel about some re-organizing includes such that we "include only what we use"? (hopefully it will make compilation faster and make it more obvious what parts are still highly connected)
< fanquake> Related #15442
< gribble> https://github.com/bitcoin/bitcoin/issues/15442 | Running iwyu on Bitcoin Core . Issue #15442 . bitcoin/bitcoin . GitHub
< elichai2> ha thanks :) well IWYU itself has a problem with boost. boost isn't built with the IWYU idea in mind
< elichai2> I assume we still want the `fs.h` separation even though it can increase compile time? (a lot of units only need the path.hpp and not the whole fs)
< Chris_Stewart_5> Is there a document anywhere on bitcoin core's key handling and storage procedures? Or is this a "read the code" situation?
< sipa> i don't think it's documented anywhere
< MarcoFalke> Is there a meeting today?
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/0655c7a94cc9...3f8dbcd65547
< bitcoin-git> bitcoin/master 6f6465c John Newbery: scripted-diff: [validation] Rename CheckInputs to CheckInputScripts
< bitcoin-git> bitcoin/master 3bd8db8 John Newbery: [validation] fix comments in CheckInputScripts()
< bitcoin-git> bitcoin/master 3f8dbcd MarcoFalke: Merge #16658: validation: Rename CheckInputs to CheckInputScripts
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16658: validation: Rename CheckInputs to CheckInputScripts (master...2019-08-rename-CheckInputs) https://github.com/bitcoin/bitcoin/pull/16658
< wumpus> elichai2: yes, please keep fs.h
< wumpus> after filesystem lands in c++ itself and we can use that, we can discuss splitting it up (depending on how the standard library does it), but before that this is supposed to abstract out that particular boost usage
< elichai2> makes sense
< wumpus> (also, having the fs functions in one header is useful for sandboxing platforms that don't have direct file access)
< wumpus> MarcoFalke: I'm okay with doing a meeting today
< elichai2> MarcoFalke: how do you feel about the `for XXXX` comments IWYU leaves?
< MarcoFalke> elichai2: spammy unless a header is used for 3 things or less
< elichai2> and easily gets out of date
< MarcoFalke> Jup
< MarcoFalke> I guess most useful would be documentation on how to run it on a single file (e.g. a freshly created file)
< elichai2> that's the easiest actually. but still requires fixing the problems it makes
< elichai2> I want to make a PR showing how the changes look, altough this is something that isn't reviewable easily
< elichai2> where should I document how to use this?
< MarcoFalke> Maybe in my issue or in our developer docs
< MarcoFalke> #proposedmeetingtopic Vanilla debian Bitcoin Core package, #17343
< gribble> https://github.com/bitcoin/bitcoin/issues/17343 | Meta: Packaging Bitcoin Core as vanilla system package . Issue #17343 . bitcoin/bitcoin . GitHub
< sipsorcery> wumpus: In case you didn't already spot it the GitHub Action job is being triggered on every repo action (issue comments etc).
< elichai2> since when github actions working in core? :O
< sipsorcery> not sure why issue comments are triggering the job... the "on: push:" should restrict triggering to commits
< sipsorcery> will try and replicate
< promag> #16963 review/merge ?
< gribble> https://github.com/bitcoin/bitcoin/issues/16963 | wallet: Fix unique_ptr usage in boost::signals2 by promag . Pull Request #16963 . bitcoin/bitcoin . GitHub
< bitcoin-git> [bitcoin] hebasto opened pull request #17849: ci: Fix brew python link (master...20200102-travis-brew-python) https://github.com/bitcoin/bitcoin/pull/17849
< hebasto> hi
< sipsorcery> hi
< jonatack> hi
< achow101> HI
< 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
< wumpus> jeremyrubin lightlike emilengler jonatack
< amiti> hi
< MarcoFalke> hi
< kanzure> hi
< moneyball> happy new year everyone
< promag> hi
< MarcoFalke> travis macOS is fixed thanks to hebasto. I just reset all travis runs. Let me know if I missed one
< wumpus> yes, happy new year everyone
< wumpus> thanks hebasto
< hebasto> nm
< sipa> hi
< wumpus> one proposed topic this week by MarcoFalke : Vanilla debian Bitcoin Core package, #17343
< gribble> https://github.com/bitcoin/bitcoin/issues/17343 | Meta: Packaging Bitcoin Core as vanilla system package . Issue #17343 . bitcoin/bitcoin . GitHub
< wumpus> anything else to discuss?
< luke-jr> HNY
< wumpus> #topic High priroity for review
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #17669: tests: have coins simulation test also use CCoinsViewDB (master...2019-12-coins-tests) https://github.com/bitcoin/bitcoin/pull/17669
< sipa> From Wikipedia, the free encyclopedia. HNY may refer to: Happy New Year (2014 film) Hengyang Nanyue Airport, IATA code HNY.
< gleb> Hi
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #17669: tests: have coins simulation test also use CCoinsViewDB (master...2019-12-coins-tests) https://github.com/bitcoin/bitcoin/pull/17669
< wumpus> 10 blockers (!), 7 chasing concept ACK https://github.com/bitcoin/bitcoin/projects/8
< luke-jr> sipa: it has to be a film? O.o
< wumpus> better get to reviewing :)
< sipa> new year's resolution: review more PRs (and also, 1080p)
< wumpus> would be nice to get #10785 in soon, it's about time, it's from 2017
< gribble> https://github.com/bitcoin/bitcoin/issues/10785 | Serialization improvements by sipa . Pull Request #10785 . bitcoin/bitcoin . GitHub
< wumpus> I definitely wouldn't have the patience to keep rebasing a PR for that long
< MarcoFalke> sipa, review in 1080 pixel instead of 360 pixel?
< sipa> wumpus: making a minimal initial PR with just 2 commits
< jonatack> i think kallewoof wanted to move #16411 from chasing concept acks over to high-priority
< gribble> https://github.com/bitcoin/bitcoin/issues/16411 | BIP-325: Signet support by kallewoof . Pull Request #16411 . bitcoin/bitcoin . GitHub
< wumpus> sipa: oh, it grew over time
< wumpus> jonatack: ok
< sipa> wumpus: not really, and the recent protobuf purging simplified it a bit, actually
< sipa> but still, it seems there is little appetite to review the whole thing at once
< sipa> in any case, concept ack on moving #16411 from chasing concept ack to blocker
< gribble> https://github.com/bitcoin/bitcoin/issues/16411 | BIP-325: Signet support by kallewoof . Pull Request #16411 . bitcoin/bitcoin . GitHub
< wumpus> well tons of people reviewed it
< wumpus> looking at number of comments at least
< sipa> many ryanofsky reviews mostly, iirc :)
< wumpus> ah couldn't really see due to github comment hiding gymnastics
< luke-jr> XD
< wumpus> #topic Vanilla debian Bitcoin Core package (MarcoFalke)
< sipa> must be heavy on their poor Ruby infrastructure
< sipa> MarcoFalke: ^
< MarcoFalke> So packaging is still an unsolved problem for Linux distros. We stopped maintaining the Ubuntu PPA due to numerous problems and provided flatpak and snapcraft packages.
< wumpus> oh, the ppa is no longer maintained?
< MarcoFalke> Though, that uncovered other issues
< luke-jr> MarcoFalke: Matt stopped maintaining the PPA. I didn't.
< luke-jr> wumpus: the bitcoin/bitcoin one Matt used to have is unmaintained now
< MarcoFalke> luke-jr: There are still issues with the ppa, even if maintained.
< wumpus> yes, if it was just a matter of maintenance we could try to find someone else to do it
< achow101> what are the issues?
< luke-jr> IMO flatpak/snapcraft aren't comparable, but go on
< wumpus> yes, what are ths issues?
< MarcoFalke> achow101: On the top of my head: * not reproducible builds, no way to verify what happened on the build servers. * People installing the ubuntu ppa on non-ubuntu distros (https://wiki.debian.org/DontBreakDebian )
< wumpus> except non-determinism
< wumpus> yes I mean non-reproducible
< jamesob> hi
< bitcoin-git> [bitcoin] sipa opened pull request #17850: Serialization improvements (minimal initial commits) (master...202001_noncastserial) https://github.com/bitcoin/bitcoin/pull/17850
< luke-jr> ok, so no real issues? :P
< luke-jr> (non-determinism isn't an issue IMO since it's built by the distro co)
< wumpus> is there a ppa-like system for debian?
< luke-jr> wumpus: you can manually add repos, but nothing as easy as PPA AFAIK :/
< MarcoFalke> * The ppa is also updated only after the OS has been released, so upgrading the Ubuntu might lead to issues
< luke-jr> QuickBuild.io provides PPAs for Debian, but in my experience they don't work :/
< luke-jr> MarcoFalke: I don'
< luke-jr> MarcoFalke: I don't understand what you mean there
< MarcoFalke> * The ppa only supports one version of Bitcoin Core, so (not) updating Bitcoin Core might lead to issues
< wumpus> I'm interested in that problem, yes, auto-update kind of sucks for bitcoin
< wumpus> it should be a user decision to upgrade
< luke-jr> auto-update is the entire point of PPAs, though
< MarcoFalke> luke-jr: The ppa was only compiled for (let's say Ubuntu 18.04 after it has been released. I.e. Apr 18) So it is harder to install it for the Ubuntu Beta?
< wumpus> could we do better?
< luke-jr> MarcoFalke: not if we update the PPA timely
< wumpus> (apart from having a new package for every new release0
< jamesob> Wouldn't it be better just to provide a shell script that people can curl that builds from source than trying to cater to bad distro build infra?
< luke-jr> jamesob: eww, no
< achow101> MarcoFalke: is your suggestion that we also build debs and upload them to bitcoincore.org?
< wumpus> I mean ,we already have binary builds for linux
< wumpus> they should work on most distros
< wumpus> definitely debian and fedora
< luke-jr> I've been keeping an archive of PPA-generated .debs locally FWIW
< jamesob> Yeah, so what's wrong with saying "ppa build infra isn't up to our standards, so go to these other places"
< luke-jr> wumpus: they only work on Ubuntu in my experience; at least not on Gentoo
< wumpus> the only exception really is non-glibc
< MarcoFalke> luke-jr: Are you volunteering to update the PPA timely for the full matrix of distros/version of Bitcoin Core?
< luke-jr> jamesob: I see no problem w/ the build infra
< jamesob> didn't someone say the buids aren't reproducible?
< luke-jr> MarcoFalke: I can only update the PPA for Launchpad-supported distros, but yes, I have been and intend to continue updating it
< luke-jr> jamesob: neither is the rest of the OS
< luke-jr> jamesob: PPAs are Canonical built for Canonical distros
< wumpus> so anyway: what is the proposal here?
< MarcoFalke> And also, PPAs are not friendly for new users (novice linux users). E.g. I avoid them because it is easy to break the whole system with them.
< MarcoFalke> wumpus: My proposal is to have vanilla packages
< wumpus> how would you do that?
< MarcoFalke> in the vanilla package manager of the distro
< luke-jr> MarcoFalke: we explicitly advise distros NOT to do that..
< wumpus> that's up to the distros, right?
< luke-jr> also, that has the same problems as the PPA?
< MarcoFalke> luke-jr: Why?
< luke-jr> MarcoFalke: 1) their LevelDB packages don't meet consensus-safety standards, and they will not use embedded copies
< luke-jr> MarcoFalke: 2) they won't deploy even minor fixes to stable versions
< fanquake> Hi
< * luke-jr> looks up our advisement to see if there's anything else
< MarcoFalke> 1) We release versions of Bitcoin Core with different versions of leveldb. So the versioning shouldnt' be an issue. If the packaging is an issue, it can be changed, maybe
< wumpus> bleh, not using the embedded leveldb would really be inadvisable
< MarcoFalke> 2) Releasing new versions can be done with "backports", like it is done with clang-8 on Bionic Ubuntu and security fixes are alwasy deployed
< luke-jr> MarcoFalke: backports are no less trouble than PPAs
< luke-jr> PPAs are better because users already have them
< luke-jr> (for the initial install)
< luke-jr> also, the existence of bad PPAs doesn't mean *our* PPAs need to be bad; and not using a PPA ourselves doesn't make the bad ones go away
< MarcoFalke> PPAs are bad pratice in general
< luke-jr> they aren't
< wumpus> I don't think PPAs are bad practice in general, not on ubuntu at least, installing them to other distros like debian is obviously bad
< MarcoFalke> And the bitcoin Core PPA is being used against best practices, so providing one is like encouraging those bad practices
< sipa> MarcoFalke: what do you mean by that (just curious, i know very little about them)
< luke-jr> yes, PPAs target a specific distro/release and shouldn't be used on others
< wumpus> in any case, I think we need to be really careful to reconsider the advisement
< wumpus> we don't want zillions of nodes running years-old software by accident, not because they want to but just because there's no upgrade path
< MarcoFalke> sipa: PPAs are usually compiled for a specific OS version and might break things if installed on a different OS version. E.g. install an Bionic ppa on Ubuntu 19.10 or even Debian
< sipa> agreed
< luke-jr> distro packages are likely to end up with *new* users installing obsolete versions
< sipa> luke-jr: perhaps - but is that really the alternative? given things like snap/flatpak?
< wumpus> MarcoFalke: at least the ppa-add script avoids that, it will only add the ppa for the release that a user has
< MarcoFalke> Ok, so if the preference is to stick with PPAs, we should maintain them
< luke-jr> sipa: that's the topic ;)
< sipa> luke-jr: i think a reasonable conclusion could be that for our use case both distro packages and PPAs are bad
< luke-jr> sipa: PPAs aren't bad though.. :/
< luke-jr> yes, they're targetted, but that's kinda the point
< sipa> luke-jr: i said for our use case
< wumpus> I'm not convinced PPAs are really bad
< sipa> if they result in people running old unupgradable versions
< luke-jr> sipa: they don't
< wumpus> though I prefer people to use the deterministic binaries from bitcoincore.org
< luke-jr> PPAs can be updated for every release
< wumpus> but distro packages wouldn't improve that
< luke-jr> every Core release*
< MarcoFalke> Well, some people use curl $latest_release, so they end up with no upgrade path through $package_manager update
< luke-jr> sipa: for example, my PPA currently has for every supported Ubuntu version; when 0.19.1 is out, it will get that for all versions too
< wumpus> no, PPAs (at least used to) be updated with every release of core
< sipa> ok
< MarcoFalke> So I don't really like the bitcoincore.org/bin/* either
< wumpus> the bitcoin/bitcoin ones are unmaintained at the moment but that's not a fault in PPA
< wumpus> well, nothing is ideal
< luke-jr> I suppose I could update bitcoin/bitcoin if Matt wants to give me access - I just figured it made more sense to retire it
< MarcoFalke> wumpus: True :)
< luke-jr> perhaps it should be updated with a .txt package saying to switch to another source
< wumpus> packaging bitcoin is a difficult issue
< MarcoFalke> luke-jr: It should be maintained in https://github.com/bitcoin-core/packaging
< luke-jr> (although it might be rude to effectively delete from users' PCs on an update)
< MarcoFalke> There is a debian subfolder, but no one has touched it in years: https://github.com/bitcoin-core/packaging/tree/master/debian
< achow101> I'm pretty sure lots of instructions point to the bitcoin/bitcoin ppa
< luke-jr> MarcoFalke: that's the source code, not the PPA
< achow101> and it would screw with people's existing installs from it
< luke-jr> MarcoFalke: I *think* I'm using it as-is still\
< wumpus> I think it would be better if someone took over maintenance of the current one instead of retire it
< luke-jr> maybe deleting the bitcoin/bitcoin PPA will work best - it won't uninstall anything, and will give the user an error when they update repos
< MarcoFalke> At least two people should have access (bus factor) or at least a way to reset the credentials
< wumpus> that's also not very friendly
< wumpus> yes
< MarcoFalke> And we should have documentation how to maintain it
< luke-jr> well, Matt isn't here, so we need to defer that discussion I think
< luke-jr> MarcoFalke: I have a gitian yml that updates it for me; I suppose I should add that to the packaging repo
< luke-jr> (it doesn't generate any files, just uploads)
< wumpus> yes, would be good to have the instructions public
< wumpus> any other topics?
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Jan 2 19:38:37 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/52900a764c42...190a4051fde7
< bitcoin-git> bitcoin/master 4d88c3d Wladimir J. van der Laan: net: Log to net category for exceptions in ProcessMessages
< bitcoin-git> bitcoin/master 4bdd68f Wladimir J. van der Laan: Add missing typeinfo includes
< bitcoin-git> bitcoin/master 190a405 Wladimir J. van der Laan: Merge #17762: net: Log to net category for exceptions in ProcessMessages
< bitcoin-git> [bitcoin] laanwj merged pull request #17762: net: Log to net category for exceptions in ProcessMessages (master...2019_12_network_exceptions) https://github.com/bitcoin/bitcoin/pull/17762
< bitcoin-git> [bitcoin] practicalswift opened pull request #17851: tests: Add std::to_string to list of locale dependent functions (master...locale-dependence-of-to_string) https://github.com/bitcoin/bitcoin/pull/17851
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/190a4051fde7...17e14ac92fce
< bitcoin-git> bitcoin/master 6666ef1 MarcoFalke: test: Properly document blockinfo size in miner_tests
< bitcoin-git> bitcoin/master faa92a2 MarcoFalke: rpc: Remove mempool global from miner
< bitcoin-git> bitcoin/master 17e14ac MarcoFalke: Merge #17781: rpc: Remove mempool global from miner
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #17781: rpc: Remove mempool global from miner (master...1912-mempoolMiner) https://github.com/bitcoin/bitcoin/pull/17781