< warren>
https://twitter.com/wtogami/status/1164805975615795202 <--- libfaketime 0.9.8 release is soon. I found it has regressions when tested against older userspace, maybe glibc. I don't know if this affects gitian but it really should be tested there.
< fanquake>
warren: I've compiled and run the tests on macOS. Looks like that got an autotools PR in progress. Might check that out later.
< warren>
fanquake: he's brute force "fixing" problems by adding lots of ifdefs, I'm not sure if those fixes are actually fixes. Now I'm told to edit the Makefile to workaround a failure on older glibc.
< warren>
I don't understand a lot of the more recent changes myself so I can't analyze
< fanquake>
jonatack: Let me know if that issue persists. I'm seeing scrolling to the invalid recipient, regardless of it's position or if the address or amount is invalid.
< jonatack>
fanquake: Yep, tested PR/master/PR on testnet with Debian, not scrolling into sight... btw the gui looks much nicer in your video then it does irl for me ;D
< fanquake>
jonatack: eh, if it doesn't work for everyone I'll just close and we can move onto other things.
< fanquake>
Definitely don't want to waste time with PRs like that.
< jonatack>
fanquake: Right. Maybe see if someone else on Debian confirms.
< jonatack>
hebasto: Qt 5.11.3 according to the GUI Help tab -> About Qt
< achow101>
anyone else seeing "Warning: unknown new rules activated (versionbit 1)" in getblockchaininfo? Were we just that unlucky with asicboost miners or did burying bip9 deployments accidentally cause this?
< achow101>
using a build of master from a few days ago
< jonatack>
achow101: yes i'm seeing it as well on recent master
< bitcoin-git>
[bitcoin] leto opened pull request #16695: Add window final block height to getchaintxstats (master...getchaintxstats_height) https://github.com/bitcoin/bitcoin/pull/16695
< bitcoin-git>
[bitcoin] shargon opened pull request #16696: [validation] static_assert to ensure width in unit class (master...fix-uintbase) https://github.com/bitcoin/bitcoin/pull/16696
< bitcoin-git>
[bitcoin] shargon closed pull request #16679: [validation] static_assert to ensure width in unit class (master...fix-unit-base) https://github.com/bitcoin/bitcoin/pull/16679
< bitcoin-git>
[bitcoin] amitiuttarwar opened pull request #16698: [WIP] Mempool: rework rebroadcast logic to improve privacy (master...rebroadcast) https://github.com/bitcoin/bitcoin/pull/16698
< bitcoin-git>
[bitcoin] hebasto opened pull request #16701: qt: Replace functions deprecated in Qt 5.13 (partly) (master...20190823-qt13-deprecated) https://github.com/bitcoin/bitcoin/pull/16701
< jnewbery>
achow101: almost certainly due to burying bip9 deployments
< provoostenator>
If you look at those logs it says "No output has been received in the last 10m0s" right before the functional test suite is supposed to run.
< provoostenator>
That's a bug that was fixed in #15561, so the problem should go away after you rebase.
< provoostenator>
instagibbs ariard: sorry, typo, I meant #16561
< gribble>
https://github.com/bitcoin/bitcoin/issues/16561 | tests: Use colors and dots in test_runner.py output only if standard output is a terminal by practicalswift · Pull Request #16561 · bitcoin/bitcoin · GitHub
< jnewbery>
I'd suggest we remove the "unknown new rules activated" warning entirely. It seems of dubious benefit.
< provoostenator>
jnewbery: it seems useful after a softfork, becuase e.g. you might have something in your mempool that other nodes will never confirm
< provoostenator>
I suppose not actually, because of the standardness rules.
< provoostenator>
Still seems reasonable to warn people about softforks they don't know about.
< jnewbery>
we also warn on every block that 40-50 of the last 100 blocks were of unexpected version
< provoostenator>
I thought we killed those?
< harding>
provoostenator: those are still in the logs, but no longer the GUI.
< provoostenator>
Only keeping actual activation
< jnewbery>
A warning in the software that tries to tell you about an event that didn't exist when the software was written isn't very robust. We don't even know if there will be another BIP 9 activation.
< bitcoin-git>
[bitcoin] naumenkogs opened pull request #16702: p2p: supplying and using asmap to improve IP bucketing in addrman (master...asn_buckets) https://github.com/bitcoin/bitcoin/pull/16702
< provoostenator>
I would say that even a false positive BIP9 activation message suggests something is going on that the user needs to look into.
< achow101>
I don't think it makes sense to get rid of fork warnings altogether
< gleb>
Could you mark #16702 draft? It certainly has couple questions to address (todos) before merging, although the code is working and I even have tests :)
< gribble>
https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub
< harding>
I worry that the warning could be abused. E.g., miners with sufficient hashrate can trigger the warning at any time. If this was combined with, say, a compromise of Bitcoin.org or BitcoinCore.org, they could possibly get a lot of people to "upgrade" to compromised software.
< achow101>
reading through the warning code, I can't actually figure out how having the deployment parameters prevented the warning from constantly triggering
< jnewbery>
that prevents it triggering for STARTED or LOCKED_IN versionbits activations
< achow101>
oh, I see now
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16703: rpc: Expose GetUTXOStats for testing (master...1908-rpcTestGetUTXOStats) https://github.com/bitcoin/bitcoin/pull/16703
< bitcoin-git>
[bitcoin] achow101 opened pull request #16704: Don't warn about activated buried BIP 9 deployments (master...buried-versionbits-cache) https://github.com/bitcoin/bitcoin/pull/16704
< emilengler>
What are the steps to do to add a new file to the compilation process?
< emilengler>
Only add it to Makefile.am and then run a ./configure again?
< ariard>
provoostenator: works now, was a potential deadlock issue well hindered by a boost mishandling of abort in a obscure travis log (see 16700)
< luke-jr>
emilengler: there might be some dumb MSVC stuff now too :x
< emilengler>
luke-jr: That will be funny, not even full C98 support iirc
< luke-jr>
emilengler: C++ is not C
< emilengler>
luke-jr: Sure thing but we use C functions right?
< sipa>
the libsecp256k1 subtree is compiled with a C compiler
< sipa>
but libsecp256k1 is C89
< sipa>
the rest is all compiled with C++ i believe
< sipa>
also, the msvc makefile is autogenerated from Makefile.am i think
< emilengler>
But back to my question, is adding it to Makefile.am enough for a unix compilation? I'm not familiar with autotools
< sipa>
yes
< sipa>
you could figure this out yourself by grepping for an existing source file name
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #16453: validation: Run CheckBlockIndex only on success for now (master...1907-validationCheckBlockIndexSuccess) https://github.com/bitcoin/bitcoin/pull/16453