< 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
< 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
< 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
< 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
< 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
< 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"
< 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 0.19.0.1 release I've added your torrent tracker to the trackers
< 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
< 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] 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 0.19.0.1 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.
< 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