< fanquake> I think this is one of the most explicit "help me create an altcoin" issues we've ever had: #16616
< gribble> https://github.com/bitcoin/bitcoin/issues/16616 | Technical Issue : rename command ..It is recognized as a file. · Issue #16616 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f418c3379cba...8516285d2ea4
< bitcoin-git> bitcoin/master 36f7697 Chuf: doc: Fix typos in COPYRIGHT
< bitcoin-git> bitcoin/master 8516285 fanquake: Merge #16615: doc: Fix typos in COPYRIGHT
< bitcoin-git> [bitcoin] fanquake merged pull request #16615: doc: Fix typos in COPYRIGHT (master...patch-1) https://github.com/bitcoin/bitcoin/pull/16615
< promag> fanquake: github could do that when someone forks the project -> it could ask for altcoin name and then it would rename everything
< sipa> promag: coingen :)
< promag> sipa: ah that's a thing already
< promag> err, fucking libevent
< sipa> i think it died in 2014
< promag> `nc localhost 18443` doesn't trigger any callback
< promag> only if a http request goes through
< sipa> promag: there's also forkgen
< sipa> oh, that died too
< promag> lol "and the world is kind of sort of back to normal."
< promag> quoting satoshilite from bitcoincore slack:@fanquake you should point him to https://build-a-co.in/ :)
< sipa> based on litecoin, lol
< esotericnonsense> lol, that's great (16616). could only be improved slightly if it were an s/bit/something-else. wonder how many important instances of 'bit' are in the code. :P
< phantomcircuit> promag, i assume you're using the libevent http stuff and not the socket handling stuff?
< promag> phantomcircuit: right
< promag> phantomcircuit: are you suggesting to create a read event on evhttp_bound_socket_get_fd?
< bitcoin-git> [bitcoin] fanquake opened pull request #16617: [0.18.2] Backports (0.18...0_18_2_backports) https://github.com/bitcoin/bitcoin/pull/16617
< bitcoin-git> [bitcoin] fanquake closed pull request #16541: qt: Add better icon for Open URI (master...2019-08-qt-update-open-uri-icon) https://github.com/bitcoin/bitcoin/pull/16541
< kallewoof> luke-jr: splitting out sounds sensible to me
< fanquake> Apparently I cannot get the GUI to run at more than 10 FPS.
< wumpus> fanquake: have you tried enabling hardware acceleration :-)
< fanquake> wumpus: heh, probably have a better chance of ramping up the FPS by disabling sync.
< wumpus> qt can render using opengl and even vulkan, a smooth 1000fps should be piece of cake with a decent GPU!
< wumpus> yes, disabling sync definitely a good start :)
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8516285d2ea4...8fc7f0cba9b1
< bitcoin-git> bitcoin/master a2714a5 Andrew Chow: Give QApplication dummy arguments
< bitcoin-git> bitcoin/master 8fc7f0c fanquake: Merge #16578: Do not pass in command line arguments to QApplication
< bitcoin-git> [bitcoin] fanquake merged pull request #16578: Do not pass in command line arguments to QApplication (master...no-qapp-args) https://github.com/bitcoin/bitcoin/pull/16578
< bitcoin-git> [bitcoin] fanquake closed pull request #15954: refactor: remove old bootstrap relevant code (master...patch-2) https://github.com/bitcoin/bitcoin/pull/15954
< bitcoin-git> [bitcoin] NicolasDorier opened pull request #16618: [Fix] Allow connection of a noban banned peer (master...fix/noban-banned) https://github.com/bitcoin/bitcoin/pull/16618
< fanquake> Is Travis just having a bad day? Seeing a lot of timeouts like https://travis-ci.org/bitcoin/bitcoin/jobs/572183150
< wumpus> oh those dependency fetching timeouts, saw a few yesterday too
< wumpus> maybe archive.ubuntu.com is getting sick of being continuously hammered by them, i'm really surprised travis don't have their own apt mirror
< fanquake> Has anyone here ever used distcc when building core / depends etc ?
< wumpus> not me
< fanquake> wumpus #16400 now has 3 ACKs. I'm going to add it to the HPFR list. Maybe we could save merging anything into validation while this gets some final review over today and tomorrow?
< gribble> https://github.com/bitcoin/bitcoin/issues/16400 | [refactor] Rewrite AcceptToMemoryPoolWorker() using smaller parts by sdaftuar · Pull Request #16400 · bitcoin/bitcoin · GitHub
< wumpus> fanquake: SGTM
< fanquake> I've asked meshcollider for a final look over #15986, he should be able to merge that if he's happy.
< gribble> https://github.com/bitcoin/bitcoin/issues/15986 | Add checksum to getdescriptorinfo by sipa · Pull Request #15986 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj closed pull request #16612: qt: Remove menu icons (master...2019_08_remove_menuicons) https://github.com/bitcoin/bitcoin/pull/16612
< wumpus> gah
< wumpus> I'm increasingly unable to contribute to opens ource software, I just don't have the energy anymore
< wumpus> always so many things everyone wants differently, sometimes reasonable, sometimes not, but it's just too busy for me
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8fc7f0cba9b1...e00501e00ccd
< bitcoin-git> bitcoin/master 37f2784 practicalswift: tests: Use colors and dots in test_runner.py output only if standard outpu...
< bitcoin-git> bitcoin/master e00501e MarcoFalke: Merge #16561: tests: Use colors and dots in test_runner.py output only if ...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16561: tests: Use colors and dots in test_runner.py output only if standard output is a terminal (master...parsable) https://github.com/bitcoin/bitcoin/pull/16561
< fanquake> wumpus: I know exactly how you're feeling at the moment.
< wumpus> fanquake: thank you
< jonasschnelli> ariard: can you explain that comment further: https://github.com/bitcoin/bitcoin/pull/16562#discussion_r314112055
< jonasschnelli> I can't follow
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16620: util: Move ResolveErrMsg to util/error (master...1908-utilErrorResolveErrMsg) https://github.com/bitcoin/bitcoin/pull/16620
< elichai2> achow101: is there a way for me to sign a psbt using a descriptor with private key instead of the wallet? (I'm doing `utxoupdatepsbt` with it and now i want to do `walletprocesspsbt`, or should I use `importmulti` instead?)
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/e00501e00ccd...8bd5e0af9983
< bitcoin-git> bitcoin/master fac3dcf MarcoFalke: test: Generate one block for each send in wallet_import_rescan
< bitcoin-git> bitcoin/master fa79af2 MarcoFalke: test: Replace fragile "rng" with call to random()
< bitcoin-git> bitcoin/master fa25668 MarcoFalke: test: Test p2sh-witness and bech32 in wallet_import_rescan
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16465: test: Test p2sh-witness and bech32 in wallet_import_rescan (master...1907-testAllAddressTypesImport) https://github.com/bitcoin/bitcoin/pull/16465
< bitcoin-git> [bitcoin] gapeman opened pull request #16621: doc: add default bitcoin.conf locations (master...patch-2) https://github.com/bitcoin/bitcoin/pull/16621
< ariard> jonasschnelli: destructor is currently unused for V1, do you plan to use it for V2 serializer?
< achow101> elichai2: there is not
< sipa> ariard: i think tha5 whenever you have subclasses stored as pointers to superclass objects, the superclass must have a virtual destructor
< sipa> even if the subclass types don't define their own destructors
< jonasschnelli> yes. what sipa said
< ariard> good to know, thanks
< bitcoin-git> [bitcoin] emilengler closed pull request #16590: init: systemd directory fix (master...2019-08-systemd-fix) https://github.com/bitcoin/bitcoin/pull/16590
< bitcoin-git> [bitcoin] jonatack opened pull request #16622: autoconf: property tests status and options (master...property-tests-autoconf-improvements) https://github.com/bitcoin/bitcoin/pull/16622
< elichai2> I wish people would've used more switch/case for enums instead of if/else that way the compiler will warn you on all the uses of that enum if you modify it
< jonatack> fanquake, Chris_Stewart_5: rapidcheck seems to be coming back to life a bit https://github.com/emil-e/rapidcheck/commits/master
< provoostenator> I know everyone wants to review the create wallet GUI PR #15450...
< gribble> https://github.com/bitcoin/bitcoin/issues/15450 | [GUI] Create wallet menu option by achow101 · Pull Request #15450 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/8bd5e0af9983...85883a9f8ea0
< bitcoin-git> bitcoin/master fae6ab6 James O'Beirne: refactor: pcoinsTip -> CChainState::CoinsTip()
< bitcoin-git> bitcoin/master 5693530 James O'Beirne: refactor: have CCoins* data managed under CChainState
< bitcoin-git> bitcoin/master 582d2cd James O'Beirne: Cover UTXO set access with lock annotations
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #16612: qt: Remove menu icons (master...2019_08_remove_menuicons) https://github.com/bitcoin/bitcoin/pull/16612
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16443: refactor: have CCoins* data managed under CChainState (master...2019-07-au-coins-under-chainstate) https://github.com/bitcoin/bitcoin/pull/16443
< provoostenator> ^^ *wumpus calls Github CEO: please allow PR owner transfer*
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/85883a9f8ea0...367b023ae444
< bitcoin-git> bitcoin/master fafe78f MarcoFalke: ci: Rename .travis/ to ./ci/
< bitcoin-git> bitcoin/master fa0aac0 MarcoFalke: ci: Add retry
< bitcoin-git> bitcoin/master fa31bc3 MarcoFalke: ci: Remove dependence on travis, use it as fallback env
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16582: test: Rework ci (Use travis only as fallback env) (master...1908-ciRework) https://github.com/bitcoin/bitcoin/pull/16582
< sipa> emilengler: done
< emilengler> sipa: thank you
< gleb> wumpus: I just figured out something, and I feel like we can remove #16599 from "seeking conceptual review" for now to not distract people until I implement something.
< gribble> https://github.com/bitcoin/bitcoin/issues/16599 | ASN-based bucketing of the network nodes · Issue #16599 · bitcoin/bitcoin · GitHub
< gleb> Sorry for bothering :)
< provoostenator> gleb: that's not a bad idea. I'll probably have a stronger opinion (as opposed to no opinion) if I can see the implemations for both options.
< wumpus> gleb: ok, will remove it
< MarcoFalke> Short update on the ci stuff:
< MarcoFalke> * GitHub ci is in early beta and there is not much I can evaluate
< MarcoFalke> They don't have caching, nor can own hardware be attached
< MarcoFalke> * Travis timeout was bumped to 90 minutes, so we shouldn't see any timeout anymore
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Aug 15 19:00:21 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< provoostenator> hi
< jonasschnelli> hi
< MarcoFalke> (In theory, in practice `apt update` times out ...)
< MarcoFalke> hi
< wumpus> yes, that's nice, hopefully the theory starts working out :)
< real_or_random> 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
< wumpus> no proposed topics on the weekly meeting list
< cfields> MarcoFalke: I wasn't here last week to post, but here was my feedback for Github: https://pastebin.com/raw/3PS5rtdN
< sipa> hi
< MarcoFalke> But the good news is that the ci can be run locally (or anywhere now). See ./ci/ subfolder
< jonasschnelli> nice
< gleb> hi
< Chris_Stewart_5> hi
< sipa> MarcoFalke: nice
< cfields> Glad to see you're trying it out, though :)
< jonasschnelli> Though I still not fully buying into the concept that a CI configuration should be part of the main repository
< wumpus> right, at least we know its limitations now, thanks!
< MarcoFalke> cfields: Yeah, I guess in the end we'll go with jonasschnelli's ci
< jonasschnelli> (once it's mature enough)
< ryanofsky> fun fact: the ci folder contains 4 mentions of the word "poop"
< MarcoFalke> jonasschnelli: Why not? travis.yml is part of the main repo
< achow101> hi
< jonasschnelli> Just conceptually I don't understand why the CI configuration needs to be part of the project sources
< jonasschnelli> Could be another repo, config-file, whatever
< jnewbery> hi
< MarcoFalke> jonasschnelli: Because the config needs to be updated atomically with the source code
< jonasschnelli> why?
< MarcoFalke> Let's say I add a new dependency boost-process, the ci runner needs to install it
< jonasschnelli> Yes. But it could be update in that secondary config file / repository then
< MarcoFalke> And in the meantime the ci couldn't run?
< MarcoFalke> Also you couldn't run it on older branches
< jonasschnelli> Maybe...
< jonasschnelli> It just feels this would not scale with multiple build systems / CI
< jonasschnelli> With the Appvayor, it's already a problem IMO
< jonasschnelli> but I'm probably complicating things...
< MarcoFalke> My plan was to only have one place to put the config and have all build systems use that config
< MarcoFalke> I tested it with GitHub CI, Cirrus CI, Travis CI. They all use the same config and it works
< jonasschnelli> Wouldn't that lead to a monotonic CI/test system?
< MarcoFalke> It includes the whole build matrix. But I agree
< kanzure> hi
< ryanofsky> i think it's convenient for things like ci and lint to be in the main repository, it would be a headache to have a change like #16367 that requires a ci update and have to stage it in multiple prs
< gribble> https://github.com/bitcoin/bitcoin/issues/16367 | Multiprocess build support by ryanofsky · Pull Request #16367 · bitcoin/bitcoin · GitHub
< jonasschnelli> My understanding would be, that there are a bunch of test-systems (call it CIs), running aside of our repo...
< * dongcarl> enjoyed ryanofsky's fun fact
< jonasschnelli> They have all their custom setup to test various configurations
< provoostenator> I'd like to be able to run CI without Docker at some point...
< jonasschnelli> If we run the same matrix on all CIs,.. seems a bit pointless
< MarcoFalke> jonasschnelli: Right. Agree on that
< jonasschnelli> provoostenator: bitcoinbuilds at least runs without docker...
< MarcoFalke> It is more a plan to not be married to one CI supplier
< wumpus> dongcarl: same :)
< jonasschnelli> which is a good point. If we have one CI script that always runs in docker...
< MarcoFalke> provoostenator: jonasschnelli: You can also run ./ci/ without docker
< MarcoFalke> Though that messes up the host (obviously)
< jonasschnelli> Okay. Let me continue to think about this... but I see the point of convenience
< provoostenator> Right, it would be happy to run just one specifiic host
< provoostenator> E.g. I have a Bionic x86 machine here, or an ARM machine elsewhere.
< MarcoFalke> jonasschnelli: Yeah let's continue in #bitcoin-builds or in one of my follow up pull requests that I plan to open soon :)
< jonasschnelli> ack
< sipa> proposed topic: libsecp256k1 maintenance
< MarcoFalke> #topic libsecp256k1 maintenance (sipa)
< sipa> so, lately i haven't had too much time to deal with maintaining libsecp256k1
< sipa> and also the other existing maintainers haven't been active
< sipa> real_or_random has been pretty active, and i'd like to transition to giving him maintainer rights
< * jonasschnelli> looks at real_or_random
< sipa> but i wanted to bring this up here, as the secp256k1 repo is under the bitcoin-core org
< MarcoFalke> I was about to suggest the first one to say a word will become the next maintainer
< real_or_random> glad I haven't said a word
< instagibbs> congrats... jonasschnelli ;P
< MarcoFalke> good to hear that real_or_random is volunteering for that position
< jonasschnelli> ack on real_or_random
< jonasschnelli> instagibbs: that was just an irc-action.. :P
< wumpus> I'd like to volunteer but currently, I'm just not able to
< MarcoFalke> wumpus: We should make a rule that Bitcoin Core maintainers are not allowed to maintain other projects :)
< nickler> ack real_or_random
< real_or_random> I think nickler was volunteering too :)
< wumpus> MarcoFalke: that's okay with me too :)
< provoostenator> also ack real_or_random
< MarcoFalke> ack nickler and real_or_random
< wumpus> *leaves bitcoin core for secp256k1* hehe
< sipa> also ack nickler from me, obviously :)
< jonasschnelli> also ack nickler
< sipa> that was easy.
< nickler> I'd be happy to help
< instagibbs> should people be removed?
< instagibbs> or is it just too small a number
< jonasschnelli> I guess greg and sipa?
< provoostenator> nickler what's your Github name?
< jonasschnelli> Fine for me to keep it for now
< sipa> it's andytoshi and me
< nickler> provoostenator: jonasnick
< sipa> currently
< provoostenator> Ah ok, ACK
< instagibbs> ok ACK
< wumpus> are you going to add them sipa or should I?
< sipa> i will.
< MarcoFalke> Is it that repo: https://github.com/bitcoin-core/secp256k1 ?
< sipa> correct
< wumpus> yes
< jonasschnelli> I think removing is something that could be done after 1y of inactivity or if someone explicitly wants to be removed
< MarcoFalke> why is the latest merge not signed and done with GitHub?
< MarcoFalke> (ot)
< jonasschnelli> valid point... some merge policy would probably be wise
< sipa> we should probably add merge checks in CI just like in bitcoin core itself
< real_or_random> MarcoFalke: yeah I think there are a few related issues to discuss
< provoostenator> Could reuse some of the Bitcoin Core tools over?
< sipa> yeah.
< real_or_random> also e.g., I have an open issue about a security.md file
< real_or_random> which raises the question who should be in there. secp256k1 maintainers or bitcoin-core maintainers?
< * MarcoFalke> has set a bash alias `ghm` for "github-merge.py" that works on any repo
< real_or_random> and we also don't have super clear guidelines for what should be in the repo and what not (e.g., we have the JNI bindings that we may want to remove)
< wumpus> we should probably move github-merge.py to maintainer-tools
< wumpus> instead of having it in the bitcoin core repository
< wumpus> that way it's much easier to use it for different projects
< sipa> i think that libsecp256k1 issues which don't directly affect bitcoin core can be kept inside the secp256k1 project (bitcoin core has no need for JNI... :p)
< sipa> and discussed on the #secp256k1 channel
< wumpus> secp256k1 issues should probably be reported to secp256k1 maintainers, in general
< sipa> agree; though very serious issues that impact bitcoin could of course also be reported to bitcoin core
< real_or_random> wumpus: yes this seems sensible they can escalate to core if necessary
< sipa> wumpus: agree on moving over github-merge to maintainer-tools
< sipa> i use it for unrelated projects too :)
< wumpus> yes, if it affects use in bitcoin, or is even an issue that threatens bitcoin, that seems an exception
< wumpus> sipa: ok!
< real_or_random> ack on a using github-merge and/or related tools
< real_or_random> core vendors secp256k1, so the changes need to be accepted there too
< wumpus> #action move github-merge.py to bitcoin-maintainer-tools repo
< sipa> real_or_random: occasionally we open a PR to core that updates the subtree, summarizing the changes
< real_or_random> but tbh, if we open a large +500/-500 PR from time to time, it's too late to spot weirdnesses
< sipa> yeah perhaps that's a question whether people here prefer more regular updates of the subtree
< real_or_random> yes, indeed. I think my point is that these tend to get ACKed with the idea in mind that they're fine because they were merged in secp256k1
< wumpus> it's another opportunity for review, though yes, if it groups too many different things it'll likely not get more than cursory glances
< real_or_random> so it makes sense to have the same careful committing/merging process for secp too
< wumpus> also a lot of bitcoin core reviewers don't have much knowledge of the details of the cryptography and implementation
< wumpus> yes
< real_or_random> right
< real_or_random> sipa: this question is also related to possible releases
< real_or_random> AFAIK it was always planned to have releases, we may reconsider that
< sipa> yeah
< sipa> i guess not everything needs to be resolved in this meeting
< real_or_random> sure
< sipa> but it's good to have some communication
< wumpus> yes, it's fine, it's not like there's other proposed topics for this meeting :) and I don't think sharing a meeting with secp256k1 stuff is that bad so people are aware what is happening there
< sipa> high priority for review?
< wumpus> oh yes, we could do that
< wumpus> #topic High priority for review
< BlueMatt> an I add #16421 to the list?
< gribble> https://github.com/bitcoin/bitcoin/issues/16421 | Conservatively accept RBF bumps bumping one tx at the package limits by TheBlueMatt · Pull Request #16421 · bitcoin/bitcoin · GitHub
< wumpus> sure we can always add more, I'm most interested in whether some things are getting ready for merge though :)
< aj> BlueMatt: fanquake did that already i thought?
< jeremyrubin> correct
< BlueMatt> oh, maybe
< BlueMatt> I just want to get it in for .19, and its gotten very little review
< BlueMatt> despite being an incredibly simple pr
< instagibbs> BlueMatt, will review
< MarcoFalke> I think we got three high-prio things merged this week
< MarcoFalke> maybe even more
< wumpus> 8 things on the list is a lot though
< wumpus> oh one is merged, good
< aj> oh fanquake added 16400
< MarcoFalke> #16400 should get removed
< gribble> https://github.com/bitcoin/bitcoin/issues/16400 | [refactor] Rewrite AcceptToMemoryPoolWorker() using smaller parts by sdaftuar · Pull Request #16400 · bitcoin/bitcoin · GitHub
< wumpus> so yes, the soft translation string freeze for 0.19 is already in two weeks, the feature freeze in a month
< MarcoFalke> It needs rebase and I think #15759 was in first
< gribble> https://github.com/bitcoin/bitcoin/issues/15759 | [p2p] Add 2 outbound blocks-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
< wumpus> ok
< wumpus> 16400 removed from now, let's re-add it after 15759 merged
< wumpus> anything else to discuss?
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Aug 15 19:39:57 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/367b023ae444...1bf2ff2bf8e8
< bitcoin-git> bitcoin/master 3862e47 John Newbery: [rpc] Tidy up reporting of buried and ongoing softforks
< bitcoin-git> bitcoin/master 1c93b9b John Newbery: [Consensus] Bury CSV deployment height
< bitcoin-git> bitcoin/master 0328dcd John Newbery: [Consensus] Bury segwit deployment
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16060: Bury bip9 deployments (master...bury_bip9_deployments) https://github.com/bitcoin/bitcoin/pull/16060
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16623: ci: Add environment files for all settings (master...1908-ciEnv) https://github.com/bitcoin/bitcoin/pull/16623
< bitcoin-git> [bitcoin] ariard opened pull request #16624: wallet : encapsulate trransactions state (master...2019-08-encapsulate-tx-state) https://github.com/bitcoin/bitcoin/pull/16624
< fanquake> I put 16400 in there because it had 3 ACKs and was much closer to being merged than 15799 at the time (also didn’t need a rebase). Guess someone merged into validation and broke it.
< fanquake> I don’t think it should necessarily matter which PR was in there “first”. As there are things that have lingered in HP for weeks. It should also matter what has had recent/active review.
< roconnor> Hi all. After building bitcoin-0.18.0 and bitcoin-0.18.1 when I run the test_bitcoin program it lists a large number of "Error: Specified -walletdir "wallets" is a relative path ... followed by "*** No errors detected". I didn't have this issue with bitcoin-0.17.1. Have I made some sort of configuration error here?
< lightlike> roconnor: that was described in #15944 and recently fixed (#16277): as a side effect of a negative test these messages are written to stderr. so it's no problem.
< gribble> https://github.com/bitcoin/bitcoin/issues/15944 | Path error messages while executing test_bitcoin · Issue #15944 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16277 | [Tests] Suppress output in test_bitcoin for expected errors by gertjaap · Pull Request #16277 · bitcoin/bitcoin · GitHub
< roconnor> Great thanks. I won't sweat about it then.