< earlz>
Has anyone tried porting the gitian build system to run on xenial instead of trusty since trusty is getting old and GCC 4.8's C++11 support is considered experimental?
< sipa>
4.8 is enough
< earlz>
Even with the (still somewhat far away) 2019 EOL for Trusty?
< sipa>
we don't use any c++11 features that aren't in gcc 4.8
< gmaxwell>
jnewbery: I really think we should split the PR and merge the mark-used and topup if possible stuff, and make the shutdown and don't update parts a seperate PR. The first part is done, solves the issue for unlocked wallets. And even for locked wallets results in rescan instructions that we can give to succesfully rescan "(unlock the wallet with a long time, run rescan)"... and doesn't have an r
< gmaxwell>
isk of making things worse for anyone.
< earlz>
My concern isn't bitcoin itself, but rather it's dependencies will start using C++11 features, making for more and more patches being required for gitian compiles
< sipa>
earlz: i'm confused
< sipa>
gitian is a fully deterministic environment, we control all the dependencies
< sipa>
and their exact version
< earlz>
yes of course, but at some point there will be a discussion "no, we can't upgrade boost because it will require patching out their use of things gcc 4.8 doesn't support"
< sipa>
heh, then we'll just upgrade gcc...
< earlz>
that seems... non-trivial without also upgrading from trusty to xenial or building our own compilers within gitian as another dependency
< sipa>
which we should do anyway
< earlz>
heh at that point might as well make a deterministic linux distro too ;)
< earlz>
but seriously, I guess it's nothing to worry about for now, just concerning for the future, and if EOL affects gitian builds using trusty
< gmaxwell>
earlz: eventually our depends system will compile GCC.
< gmaxwell>
earlz: and wrt upgrading normally the barrier there is just that it often restricts our ability to produce binaries that will run on older systems.
< earlz>
What is the official target for "older systems"? Like what distros and such?
< eck>
earlz: btw if you wanted to upgrade gcc on gitian you'd probably have to upgrade it on travis as well, which is non-trivial/challenging, as trusty is the latest release supported by travis (and they didn't even roll that out until relatively recently)
< eck>
thre are some changes they made to the std::string ABI in GCC 5.1+ but I'm not sure how pertinent they are here
< earlz>
wow really? That's ridiculous
< eck>
it's not ridiculous, c++11 changed the std::string spec
< earlz>
No I mean about Travis just recently supporting a 4 year old distro
< earlz>
regarding std::string ABI stuff, would that really matter that much? I know compiling Bitcoin outside of Gitian (ie with system deps) works fine in every version of GCC I've tried
< eck>
libstdc++ now supports both ABIs but it would be an issue if you built an executable that used the new ABI and tried to run it on a system with an old copy of libstdc++
< earlz>
ah, and I assume static linking of stdc++ isn't feasible?
< eck>
i would recommend against it, anyway it would presumably be less of an issue in a year when trusty is closer to EOL
< cfields_>
we static link libstdc++
< cfields_>
so the abi is not an issue
< Chris_Stewart_5>
funny, wumpus and i had a convo about upgrading gcc earlier today
< cfields_>
yes, it was on my list for 0.15 but i didn't make it :(
< cfields_>
0.16 will use a self-built toolchain
< Chris_Stewart_5>
Is there consensus on what the oldest version of gcc will be that we support?
< cfields_>
well that's independent of gitian and the release process
< Chris_Stewart_5>
Just 4.9.x instead of 4.8?
< Chris_Stewart_5>
What does gcc version have to do with a self built toolchain? Does your self built toolchain stuff require a bunch of fancy c++11 features?
< cfields_>
no. maybe i'm the one who conflated things there. I'm not sure what you meant by "upgrading gcc". If you mean "bumping the minimum version required", i doubt that'll change soon
< Chris_Stewart_5>
ah, yes that is what i meant.
< bitcoin-git>
[bitcoin] theuni opened pull request #11012: Make sure to clean up mapBlockSource if we've already seen the block (master...cleanup-blocksource) https://github.com/bitcoin/bitcoin/pull/11012
< luke-jr>
[20:23:44] <jonasschnelli> sdaftuar, luke-jr: about NODE_NETWORK_LIMITED_*. If we would treat them independently, would this mean, a peer signalling NODE_NETWORK_LIMITED_HIGH will always singal NODE_NETWORK_LIMITED_LOW? <-- I disagree with this approach
< luke-jr>
jonasschnelli: … but I didn't realise nodes would OR service bits themselves. Nevermind.
< * kallewoof>
wonders why net_processing.cpp:~1552 (if (inv.type == MSG_BLOCK) {..) is okay, when the inv type is OR'd with MSG_WITNESS_FLAG and stuff. Is INV not used in segwit? Why will e.g. MSG_WITNESS_BLOCK (MSG_BLOCK | MSG_WITNESS_FLAG) never happen?
< sipa>
kallewoof: MSG_WITNESS_FlAG is only used in getdata, not inv
< kallewoof>
sipa: gotcha, thanks!
< achow101>
kallewoof: see bip 141: "New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK"
< achow101>
kallewoof: the response to an inv is a getdata, in which we will specify that we want the witnesses by setting MSG_WITNESS_FLAG. this also means that we won't break compatibility with old nodes
< kallewoof>
achow101: Thanks for clarifying. I sort of missed that INV had a successor, or I forgot. I haven't dug around here in awhile.
< sipa>
it's similar to BIP37's MSG_FILTERED_BLOCK btw
< kallewoof>
Ahh yes, I noticed that too. Hence e.g.
< kallewoof>
Will re-read BIPs though, while at it.
< kallewoof>
sipa: since it kind of overlapped with BIP154 (anti-DoS via POW) I am interested in the work in replacing the misbehaving stuff with how useful a node has been that you mentioned before. Is there any work being done on this currently?
< bitcoin-git>
bitcoin/master fd05132 practicalswift: Restore default format state of cout after printing with std::fixed/setprecision
< bitcoin-git>
bitcoin/master ecd2135 MarcoFalke: Merge #10963: [bench] Restore format state of cout after printing with std::fixed/setprecision...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10963: [bench] Restore format state of cout after printing with std::fixed/setprecision (master...restore-format-state-of-cout) https://github.com/bitcoin/bitcoin/pull/10963
< aj>
wumpus: (in particular, not clear to me if -includeconf is basically okay to merge as is; or should be able to include multiple files and/or recursively like #include would)
< bitcoin-git>
bitcoin/master 4d4fb33 Pavel Janík: Rename member field according to the style guide.
< bitcoin-git>
bitcoin/master e526ca6 MarcoFalke: Merge #10835: Rename member field according to the style guide...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10835: Rename member field according to the style guide (master...20170715_Wshadow_reverseiterator) https://github.com/bitcoin/bitcoin/pull/10835
< jnewbery>
gmaxwell : paring 10882 back to just mark-used and topup doesn't fix the most important issue: potentially missing txs and funds loss if you restore an old encrypted backup wallet
< earlz>
anyone ever seen this error from a gitian build? It recently popped up and won't go away "error: newly created file is older than distributed files!"
< remote>
earlz: clock out of whack?
< earlz>
ah, it is. I guess that happened from hibernating the virtualbox vm
< smill>
Hello, I have a problem using bitcore-wallet-service and insight-api, I have everything working with bitcoind from bitcoin-0.12.1 bitcore build (the one that gets installed if you follow the dosc) but im trying to get the new release working from https://github.com/bitpay/bitcoin/releases and im basically having the same problem as this guy https://github.com/bitpay/insight-ui/issues/746 and there are no answers yet