< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/746318179884...e6f167bfdfc0
< bitcoin-git> bitcoin/master f6e4225 Wladimir J. van der Laan: build: Allow export of environ symbols
< bitcoin-git> bitcoin/master eafd259 Wladimir J. van der Laan: build: Add NX workaround for RV64
< bitcoin-git> bitcoin/master e6f167b MarcoFalke: Merge #17569: build: Allow export of environ symbols and work around rv64 ...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #17569: build: Allow export of environ symbols and work around rv64 toolchain issue (master...2019_11_environ) https://github.com/bitcoin/bitcoin/pull/17569
< bitcoin-git> [bitcoin] jonatack opened pull request #17585: rpc: deprecate getaddressinfo label (master...deprecate-getaddressinfo-label) https://github.com/bitcoin/bitcoin/pull/17585
< wumpus> appveyor failing: "C:\projects\bitcoin\src\httpserver.cpp(373,5): error C3861: 'evthread_use_windows_threads': identifier not found [C:\projects\bitcoin\build_msvc\libbitcoin_server\libbitcoin_server.vcxproj]"
< wumpus> that symbol is definitely supposed to exist on windows libevent
< meshcollider> when is appveyor *not* failing...
< wumpus> I'm not sure what broke it this time, last time it was clear (someone forgot to update the MSVC buidl system) but this is less apparent
< wumpus> the most recent libevent related change was #17008 but it definitely passed after that, and the depends version shouldn't affect the version used in appveyor
< gribble> https://github.com/bitcoin/bitcoin/issues/17008 | build: bump libevent to 2.1.11 in depends by stefanwouldgo . Pull Request #17008 . bitcoin/bitcoin . GitHub
< meshcollider> perhaps some weird header include thing with #17518 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/17518 | refactor, wallet: Nuke coincontrol circular dependency by hebasto . Pull Request #17518 . bitcoin/bitcoin . GitHub
< wumpus> I mean the reason that appveyor breaks all the time is because people ignore appveyor before merging, because it breaks all the time, we kind of need to break that circle *shrug*
< wumpus> at least gitian builds work again!
< meshcollider> true, appveyor has failed on pretty much every single open PR so it kinda just becomes cry-wolf
< meshcollider> we need to fix it and then rebase every PR at once ;)
< hebasto> meshcollider: which include do you mean?
< meshcollider> Not sure, it was just the first PR that was merged after the last appveyor fix and appveyor failed on it
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.19: https://github.com/bitcoin/bitcoin/compare/1bc9988993ee...dd198064b5d9
< bitcoin-git> bitcoin/0.19 dd19806 Wladimir J. van der Laan: doc: Clear out release notes after
< meshcollider> because when fanquake merged #17571, appveyor actually passed
< wumpus> I don't think the linking error can be caused by an include change
< gribble> https://github.com/bitcoin/bitcoin/issues/17571 | Add libtest_util library to msvc build configuration by sipsorcery . Pull Request #17571 . bitcoin/bitcoin . GitHub
< meshcollider> something must have changed in between those two PRs though right, if it passed on one and failed on the other?
< wumpus> true
< wumpus> though it could also be a change in between when the appveyor test was run on 17571 and merging time, on master
< meshcollider> it did pass on the merge commit though
< meshcollider> not just sipsorcery's commit
< wumpus> right, it could also be something entirely unrelated, like a dependency/cache change by appveyor itself
< wumpus> we've had similar things with travis at times
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.19: https://github.com/bitcoin/bitcoin/compare/dd198064b5d9...a284bbbee805
< bitcoin-git> bitcoin/0.19 2aba76c Hennadii Stepanov: qt: Fix missing qRegisterMetaType for size_t
< bitcoin-git> bitcoin/0.19 a284bbb Hennadii Stepanov: refactor: Styling w/ clang-format, comment update
< wumpus> the 0.19 branch is free for merging for 0.19.1
< sipsorcery> for the appveyor job it would be worthwhile to force an update of the vcpkg installed dependencies
< hebasto> appveyor complains about error in httpserver.cpp and warning "boost-system's buildsystem uses very long paths and may fail on your system." They seem related to each other/
< sipsorcery> i don't get the 'evthread_use_windows_threads' compilation error on my own job and the only difference should be the vcpkg state
< sipsorcery> hebasto: that warning has been around for a while and is harmless
< wumpus> hebasto: the boost build warning is standard
< wumpus> right
< sipsorcery> the appveyor job's cache can be triggered to purge by touching the build_msvc\vcpkg-pacakges.txt file, or
< sipsorcery> manually by sending a http request of the form curl -H "Authorization: Bearer $APPVEYOR_TOKEN" -X DELETE https://ci.appveyor.com/api/projects/sipsorcery/bitcoin-72c17/buildcache
< wumpus> ah, something that doesn't involve changing a file in the repository seems preferable
< sipsorcery> the latter method is preferable but it requires access to the APPVEYOR_TOKEN
< wumpus> does not need a specific person's token?
< wumpus> or does it?
< wumpus> I see mine under "API key"
< sipsorcery> the token needs to be of the account that owns the job
< meshcollider> which would be DrahtBot I believe
< wumpus> right, I get {"message":"Account not found or access denied."}
< wumpus> if it's DrahtBot, let's wait for MarcoFalke
< sipsorcery> has anyone use the new github actions for bitcoin core builds?
< sipsorcery> seems they have linux, windows and mac images
< wumpus> I haven't used github actions, as we have our own build process, it doesn't seem particularly useful for us so haven't paid much attention to it
< sipsorcery> the appveyor build takes over 2x the time it takes on my average machine
< sipsorcery> was wondering if github actions would be faster
< sipsorcery> I'll have a play around
< wumpus> not very different from travis :)
< hebasto> meshcollider: wumpus: I've restored removed header from 17518 - it doesn't help https://ci.appveyor.com/project/hebasto/bitcoin/builds/29095602
< meshcollider> hebasto: oh thanks! Good to know
< wumpus> I managed to get Drahtbot's token (there's a dropdown in the API key page), but unfortunatly, still get the same "Account not found or access denied." error with that curl command
< sipsorcery> you also need to change the owner and project ID to match
< sipsorcery> this bit in the url is specific to my account and job "sipsorcery/bitcoin-72c17"
< wumpus> ok, tried it with https://ci.appveyor.com/api/projects/DrahtBot/bitcoin/buildcache, which at least gives me a different permission denied error :-)
< sipsorcery> it won't be DrahtBot/bitcoin
< sipsorcery> it will be DrahtBot/bitcoin-xxxx
< sipsorcery> if you open the appveyor project and go to the settings the ID is in the "Project URL slug" field
< hebasto> if skip AppVeyor's error in httpserver.cpp it fires another one: torcontrol.cpp(745,5): error C3861: 'evthread_use_windows_threads': identifier not found
< hebasto> Interesting that event2/thread.h is included...
< sipsorcery> looks like the vcpkg libevent port did change something to do with threads on 25th of Sep, https://bit.ly/2XK3biN
< hebasto> So, AppVeyor build uses Libevent that built without support for evthread_use_windows_threads(); submitting an issue.
< sipsorcery> my appveyor job does build bitcoin core successfully on master and the only difference will be my job has a more recent update of vcpkg
< hebasto> sipsorcery: see #17568
< gribble> https://github.com/bitcoin/bitcoin/issues/17568 | wallet: fix when sufficient preset inputs and subtractFeeFromOutputs by achow101 . Pull Request #17568 . bitcoin/bitcoin . GitHub
< hebasto> Sorry: #17586
< gribble> https://github.com/bitcoin/bitcoin/issues/17586 | build: AppVeyor build uses Libevent that built without support for evthread_use_windows_threads() . Issue #17586 . bitcoin/bitcoin . GitHub
< sipsorcery> hebasto: thx, i'll try and reproduce
< bitcoin-git> [bitcoin] Sjors opened pull request #17587: gui: show watch-only balance in send screen (master...2019/11/send_balance) https://github.com/bitcoin/bitcoin/pull/17587
< wumpus> provoostenator: btw, for the release I've added your torrent tracker to the trackers
< vasild> jkczyz: What do you think of https://github.com/bitcoin/bitcoin/pull/17577?
< wumpus> sipsorcery: from what I understand from the change in https://github.com/microsoft/vcpkg/pull/8349, "thread" needs to be specified as an explicit feature since that change, e.g. libevent[thread]
< wumpus> I'm somewhat unsure why anyone in almost-2020 would want to default to a non-thread build, but okay, at least it's an explanation
< sipa> wumpus: perhaps there is a significant performance difference?
< sipsorcery> wumpus: ah I see now. I somehow missed "feature packages" being added to vcpkg. I'll test the build again swapping libevent to libevent[thread].
< wumpus> sipa: the threading implementation is pluggable, I don't think there's much overhead on a threading-built libevent with threading not initialized versus one built without threading-- anyhow I definitely hope linux distributions won't do this...
< sipsorcery> the vcpkg PR that disabled threads for libevent didn't give an explanation. I've put a whinge in the PR comments to try and get one.
< wumpus> I'm really happy that this got caught on the missing function instead of silently going to thread-unsafe
< wumpus> I remember we had an issue in the beginning (2011? 2012?) where for some reason, bitcoin was linked against a single-threaded standard library on windows and this wasn't caught as a compile time issue, resulting in some really ugly unpredictable crashes
< wumpus> which reminds me I recently stumbled on a mechanism called ".gnu.build.attributes" which fedora uses, it allows auditing that an entire binary (and its dependencies) have been compiled with certain build settings and hardening flags, by storing these per address region
< wumpus> this might be something useful for us in the future
< bitcoin-git> [bitcoin] muzafa-popo opened pull request #17590: reade (master...master) https://github.com/bitcoin/bitcoin/pull/17590
< wumpus> fanquake: that was fast!
< bitcoin-git> [bitcoin] fanquake closed pull request #17590: reade (master...master) https://github.com/bitcoin/bitcoin/pull/17590
< sipa> "fanquake, faster than his shadow bitcoin-git"
< wumpus> hehehe
< bitcoin-git> [bitcoin] elichai opened pull request #17591: Testing bitcoin in a Big Endian platform - s390x (master...2019-11-s390x) https://github.com/bitcoin/bitcoin/pull/17591
< bitcoin-git> [bitcoin] sipsorcery opened pull request #17592: Appveyor install libevent[thread] vcpkg (master...vcpkg_libevent_thread) https://github.com/bitcoin/bitcoin/pull/17592
< bitcoin-git> [bitcoin] mzumsande opened pull request #17593: test: move more utility functions into test utility library (master...201911_test_moveutil) https://github.com/bitcoin/bitcoin/pull/17593
< provoostenator> wumpus: the 0.17.2 seems stuck in limbo?
< wumpus> provoostenator: yes
< provoostenator> What needs to happen?
< provoostenator> By the way, I whitelisted the on my tracker (thanks for adding that) and it now has the most seeders of all of the trackers :-)
< provoostenator> *torrent
< wumpus> I don't know, I think 0.17 became EOL while 0.19 was released
< wumpus> is the gitian build done? is it just a matter of uploading binaries for it? might still do it in that case
< provoostenator> It has 6 signed binaries
< provoostenator> So indeed seems like a matter of releasing it. I'll whitelist that torrent as well.
< provoostenator> (looks like we don't link to torrents for old releases anywhere though)
< provoostenator> Might be useful to link those from the release page, because such a link is more likely to survice a .org apocalypse than a binary.
< wumpus> oh, I wonder why not
< wumpus> I suppose the magnet link is still in the yml files for people intent on finding it; it's just not exposed. FWIW I'm still seeding the latest release on 0.17 0.18 0.19 branch
< wumpus> well, 0.17 is not the latest at the moment :)
< fanquake> Speaking of older releases. Review beg for #16617.
< gribble> https://github.com/bitcoin/bitcoin/issues/16617 | [0.18.2] Backports by fanquake . Pull Request #16617 . bitcoin/bitcoin . GitHub
< fanquake> Seems this is our second uninitialized var issue in as many weeks: https://github.com/bitcoin/bitcoin/pull/17568#issuecomment-558026462
< wumpus> fanquake: oh noo
< elichai2> I guess it's time for a valgrind run in the CI ?
< wumpus> yes, IIRC there's a PR for that
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e6f167bfdfc0...89a1f7a250ef
< bitcoin-git> bitcoin/master f13e274 Aaron Clauson: Appveyor install libevent[thread] vcpkg
< bitcoin-git> bitcoin/master 89a1f7a MarcoFalke: Merge #17592: Appveyor install libevent[thread] vcpkg
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #17592: Appveyor install libevent[thread] vcpkg (master...vcpkg_libevent_thread) https://github.com/bitcoin/bitcoin/pull/17592
< fanquake> thanks wumpus
< bitcoin-git> [bitcoin] laanwj merged pull request #16617: [0.18.2] Backports (0.18...0_18_2_backports) https://github.com/bitcoin/bitcoin/pull/16617
< bitcoin-git> [bitcoin] dongcarl opened pull request #17595: guix: Enable building for `x86_64-w64-mingw32` target (master...2019-09-guix-staging-win-mingw-6.0.0) https://github.com/bitcoin/bitcoin/pull/17595
< instagibbs_> BlueMatt, Is there any larger discussion on what is left that #17573 is solving? Or is this a general "more is better" approach
< gribble> https://github.com/bitcoin/bitcoin/issues/17573 | Seed RNG with precision timestamps on receipt of net messages. by TheBlueMatt . Pull Request #17573 . bitcoin/bitcoin . GitHub
< instagibbs_> without derailing that PR which looks reasonable, hence asking here
< BlueMatt> instagibbs_: the second
< BlueMatt> more is better, especially more *different types* of entropy is better.
< BlueMatt> just performance data is fine, but...
< instagibbs_> thanks
< dviola> hi
< dviola> in bitcoin-qt "Current number of transactions" and "Memory usage" stays at "N/A"
< dviola> any ideas?
< fanquake> dviola see #17576
< gribble> https://github.com/bitcoin/bitcoin/issues/17576 | Mempool fields in Debug Windows show "N/A" . Issue #17576 . bitcoin/bitcoin . GitHub
< fanquake> This is a known issue, and will be fixed in 0.19.1
< dviola> fanquake: thanks
< wumpus> dviola: please help testing the rc next time :) this only came to light after the RC phase
< dviola> wumpus: sure thing
< bitcoin-git> [bitcoin] laanwj opened pull request #17596: doc: Change doxygen URL to doxygen.bitcoincore.org (master...2019_11_doxygen_url) https://github.com/bitcoin/bitcoin/pull/17596
< wumpus> provoostenator: any idea how to do a partial redirect like that in nginx?
< provoostenator> wumpus: not much better than Google...
< wumpus> oh I think I already have it
< wumpus> (you do need to clear your cache first because it remembers the old permanent redirect)
< MarcoFalke> appveyor is green again, btw
< wumpus> great!
< fanquake> MarcoFalke can you add libevent 2.1.11 to the bots depends fallback
< MarcoFalke> sure
< MarcoFalke> How do you find these so quick?
< fanquake> Just remembered that we'd merged a newer libevent recently
< provoostenator> Looks like the redirect worked!
< provoostenator> Try googling a class name, e.g. WalletModelTransaction
< wumpus> provoostenator: thanks for checking
< fanquake> wumpus sipa think you might be about to block Dianne120 for spamming
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/89a1f7a250ef...12230529e330
< bitcoin-git> bitcoin/master 41d7db0 Wladimir J. van der Laan: doc: Change doxygen URL to doxygen.bitcoincore.org
< bitcoin-git> bitcoin/master 1223052 fanquake: Merge #17596: doc: Change doxygen URL to doxygen.bitcoincore.org
< bitcoin-git> [bitcoin] fanquake merged pull request #17596: doc: Change doxygen URL to doxygen.bitcoincore.org (master...2019_11_doxygen_url) https://github.com/bitcoin/bitcoin/pull/17596
< bitcoin-git> [bitcoin] hebasto opened pull request #17597: qt: Fix height of QR-less ReceiveRequestDialog (master...20191125-height-without-qr) https://github.com/bitcoin/bitcoin/pull/17597
< wumpus> fanquake: done
< hebasto> if AppVeyor is fixed why do I see red crosses? Timeouts or something else?
< wumpus> hebasto: where?
< bitcoin-git> [bitcoin] hebasto closed pull request #17597: qt: Fix height of QR-less ReceiveRequestDialog (master...20191125-height-without-qr) https://github.com/bitcoin/bitcoin/pull/17597
< sipsorcery> 3rd last appveyor build had a genuine compilation error which looks like it was introduced by the PR
< sipsorcery> 2nd last build failed on the a python test, this is a sporadic issue that needs to be tracked down
< hebasto> sipsorcery: I see, thank you for the fix and clarification
< sipsorcery> last build (backports on 0.18 branch) failed for what looks to be missing vcpkg packages
< fanquake> probably a bunch of stuff that needs to be backported to 0.18 for appveyor
< bitcoin-git> [bitcoin] hebasto reopened pull request #17597: qt: Fix height of QR-less ReceiveRequestDialog (master...20191125-height-without-qr) https://github.com/bitcoin/bitcoin/pull/17597
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17598: doc: Update release process with latest changes (master...1911-docRelNotes) https://github.com/bitcoin/bitcoin/pull/17598
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/12230529e330...2c1c43754b7a
< bitcoin-git> bitcoin/master 2fa65e0 Elichai Turkel: Add ci script to install on s390x
< bitcoin-git> bitcoin/master da1f153 Elichai Turkel: Add s390x tests to travis
< bitcoin-git> bitcoin/master 2c1c437 MarcoFalke: Merge #17591: ci: Add big endian platform - s390x
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #17591: ci: Add big endian platform - s390x (master...2019-11-s390x) https://github.com/bitcoin/bitcoin/pull/17591
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17599: ci: Run functional tests on s390x (master...1911-ciS390x) https://github.com/bitcoin/bitcoin/pull/17599
< fanquake> So the new hardware has already turned up a bug in the functional tests?
< sipa> fanquake: it's a bug in the tests, yes
< sipa> (python code interpreting LE data using struct unpack, marking the data as native)
< bitcoin-git> [bitcoin] hebasto opened pull request #17600: qt: Remove connection for unused accepted() signal in ReceiveRequestDialog (master...20191125-unused-connection) https://github.com/bitcoin/bitcoin/pull/17600
< bitcoin-git> [bitcoin] jnewbery opened pull request #17601: Validation: Move CheckBlock() mutation guard to AcceptBlock() (master...2019-11-checkblock-in-acceptblock) https://github.com/bitcoin/bitcoin/pull/17601
< bitcoin-git> [bitcoin] dongcarl opened pull request #17602: net: Lower # of IPs learned from a DNS seed (master...2019-11-lower-nMaxIPs) https://github.com/bitcoin/bitcoin/pull/17602
< bitcoin-git> [bitcoin] fanquake opened pull request #17604: doc: correct ScheduleBatchPriority return value documentation (master...fix_ScheduleBatchPriority_comment) https://github.com/bitcoin/bitcoin/pull/17604
< dviola> the git tags in the bitcoin repo and the releases at bitcoincore.org are the same thing, right?
< dviola> I'm currently using the release tarballs but I might switch to compiling from the repo, this way I can test RCs too
< dviola> are rc tarballs also signed?
< achow101> dviola: yes, they are the same. rcs go through the same release process as the final releases so they are signed too
< dviola> I see, thanks
< dviola> I'll keep using the tarballs but I might switch to using git after a while
< luke-jr> dviola: no tarballs are signed..
< luke-jr> well, except by gitian in separate files
< luke-jr> (ie, git-made tarballs are not)
< dviola> luke-jr: I was talking about the verification process described here: https://bitcoincore.org/en/download/
< dviola> gpg --verify, etc