< sdaftuar>
lpersona: the way rbf works is that a new transaction must pay more in total fee than all the transactions it evicts
< lpersona>
sdaftuar: tks - i'm trying to find on the code where the sum of descendant fees is kept to be used by RBF, and also check if it's only for immediate descendants or if it keeps the entire tree of descendants - is it part of txmempool?
< sdaftuar>
in main.cpp, see AcceptToMemoryPoolWorker
< sdaftuar>
while each transaction in the mempool caches its fee with descendants, for RBF purposes we walk the descendants of all the transactions that are conflicted, so that we don't double count
< sdaftuar>
(ie in situations where a child transaction has 2 parents, both of which are being replaced)
< sdaftuar>
cfields: around?
< cfields>
hi
< sdaftuar>
if you have a few minutes i was hoping to get some help with a build issue i'm having in #7222
< sdaftuar>
(sorry to bother you with this, i'm sure i'm doing something silly)
< cfields>
sdaftuar: sure. looking
< sdaftuar>
somehow i broke the qt build when i took some code out of rpcblockchain.cpp
< cfields>
sdaftuar: do you see the error locally too? or just on travis?
< sdaftuar>
yeah i see it locally as well
< sdaftuar>
i added a new file, policy/rbf.h and policy/rbf.cpp
< sdaftuar>
the functions added were previously used in both rpcblockchain.cpp and wallet/rpcwallet.cpp
< sdaftuar>
and linking was fine
< sdaftuar>
when i deleted the code that invoked it from rpcblockchain.cpp, linking bitcoin-qt broke
< sdaftuar>
i assume i screwed up the makefile?
< cfields>
ah, some dependency thing then. i'll pull it down and build
< cfields>
sdaftuar: probably created some circular dep
< sdaftuar>
ah, ok if the makefile is fine, then i can probably track down my circular dependency. <embarrassed>
< cfields>
sdaftuar: nm, not that. i don't see where it was moved from (different commit?), but looks like you need rbf.cpp in a lib other than _server
< sdaftuar>
yeah i force pushed (too quickly it seems!), blew away the commit where it was building
< sdaftuar>
is there a simple fix to the Makefile?
< cfields>
building now. i'm not familiar with what's changing here, so i'll have to poke around for a min
< sdaftuar>
hmm, moving policy/rbf.cpp from libbitoin_server to libbitcoin_wallet appears to make the build work, with the wallet and without
< cfields>
sdaftuar: right, i'm seeing the same. so turns out there is a circular dep between wallet and server
< sdaftuar>
ah, is that something i introduced?
< cfields>
hmm, maybe not circular. bitcoind links with the order jumbled around...
< cfields>
let me see if everything links this way
< cfields>
sdaftuar: still trying to understand. i don't see how this is altering the wallet's deps
< sdaftuar>
well, rpcwallet.cpp depends on policy/rbf.cpp
< sdaftuar>
and nothing else does now
< cfields>
sdaftuar: yea, but wallet depends on tons of other stuff from server
< sdaftuar>
somehow does that cause libbitcoin_server to optimize it out?
< sdaftuar>
is it crazy for me to put policy/rbf.cpp in libbitcoin_wallet? it looks funny, though it seems to work...
< cfields>
sdaftuar: mm, i'd prefer to figure out what make it different
< cfields>
still poking
< sdaftuar>
i see what you mean about the library order being different for qt than for bitcoind
< sdaftuar>
if i rearrange the library order for qt, i think that also solves the problem. testing a bit more
< cfields>
well the wallet order is tangled anyway. worth fixing even without this issue
< sdaftuar>
no, looks like that change i made to the qt build didn't actually fix it
< cfields>
heh, built with a stale .a? i did that :)
< sdaftuar>
yeah i think so :)
< sdaftuar>
uh, i'm not sure how i overlooked this. bitcoind also doesn't compile. this qt stuff is a red herring.
< sdaftuar>
er
< sdaftuar>
bitcoind doesn't link i mean
< phantomcircuit>
sdaftuar, git clean -fdx
< cfields>
sdaftuar: right. it was the same on travis
< cfields>
i've been playing with bitcoind here
< cfields>
sdaftuar: i'm pretty sure this is building up to a facepalm. i just don't see what sets this apart.
< cfields>
rpcwallet locks cs_main ffs. it's obviously not a new dep.
< cfields>
sdaftuar: ok, here we go
< sdaftuar>
cfields: solution?
< cfields>
sdaftuar: yes. let me build clean before i spout more dumb stuff though.
< cfields>
sdaftuar: ok, you were right a long time ago
< sdaftuar>
when i said i probably did something silly?
< sdaftuar>
:)
< cfields>
<sdaftuar> somehow does that cause libbitcoin_server to optimize it out?
< cfields>
looks like if an object isn't use at all in the lib, it'll leave it out
< cfields>
which also doesn't make any sense, but one step at a time :)
< sdaftuar>
wow, okay. i really don't understand computers, because i would have thought that the whole point was you don't know if something linking against your library might use it?
< cfields>
throw that in main.cpp somewhere, and it'll link
< sdaftuar>
hm. so where does that leave us? are we building the libraries the wrong way somehow?
< cfields>
er, fix the func name. I nuked the "Signal" cause i thought the preprocessor might've been screwing with it
< cfields>
sdaftuar: still investigating.
< sdaftuar>
oh interesting, somehow referencing just one function must pull in teh whole file?
< cfields>
sdaftuar: still not making any sense. playing around.
< sdaftuar>
cfields: i'm going to call it a night soon. i've pushed up a temporary hack (just moved rbf.cpp -> libbitcoin_wallet) to make travis happy for now while we figure out the right way to solve this
< sdaftuar>
cfields: Thanks for diving into this, sorry if I sucked away your evening!
< cfields>
sdaftuar: np. i'm not sure there's much of a fix. our libs don't work how libs usually do, they're all inter-connected...
< cfields>
they're supposed to be listed from most to least dependent, and the linker makes a note of what syms are needed along the way...
< cfields>
but in our case, they need eachother. so there's no ordering where the linker can sanely mark unresolved deps along the way. i suppose we just happen to be inter-connected enough to trick it into working :)
< sdaftuar>
that is more than a little disturbing :)
< PRab>
I think I found a bug with the RC's Banned peers display.
< PRab>
I had a peer that was supposed to be unbanned about an hour ago, but it is still showing up there.
< PRab>
Should I report this as an issue on github?
< Luke-Jr>
PRab: probably
< PRab>
I wonder if it doesn't refresh until the gui is closed and reopened. Testing...
< GitHub104>
bitcoin/master fd83615 Peter Todd: Improve CheckInputs() comment about sig verification
< GitHub104>
bitcoin/master f9fd4c2 Wladimir J. van der Laan: Merge pull request #7281: Improve CheckInputs() comment about sig verification...
< GitHub3>
[bitcoin] laanwj closed pull request #7281: Improve CheckInputs() comment about sig verification (master...2016-01-improve-checkinputs-comment) https://github.com/bitcoin/bitcoin/pull/7281
< wumpus>
sdaftuar: I'm not sure I quite understand why rbf.cpp should be part of the wallet - does it use any wallet functions?
< wumpus>
I understand it's only used in the wallet, but having it in policy then linking it only into the wallet is a bit strange
< wumpus>
cfields, what circular dependency is this? we should get rid of it
< wumpus>
come on, this linker behavior can't be so random we have to do something random to make a problem seem to go away
< wumpus>
I'll take a look...
< wumpus>
also I don't understand why github says #7222 has 'conflicts that need to be resolved', even though travis apparently builds it
< wumpus>
I don't think server can depend on the wallet in any way, if we do a --disable-wallet build the wallet library won't even be built
< wumpus>
oh it does - the problem is that the RPC calls for the wallet are referenced from libbitcoin_server. this may be solved by something like #7307, which moves the registration of the wallet RPC calls to the wallet itself
< wumpus>
and that's only part of it, there are other parts of e.g. init.cpp which are part of the server and make direct calls into the wallet
< wumpus>
basically, we need to get rid of all #ifdef ENABLE_WALLET code in bitcoin_server library
< wumpus>
that's too much for 0.12 backport so I agree on sdaftuar 's intermediate "hack"
< sdaftuar>
wumpus: thanks for taking a look.
< sdaftuar>
wumpus: will look at the new merge conflicts (was clean when i last pushed)
< wumpus>
oh sorry if I broke your pull
< wumpus>
seems a conflict in listtransactions.py
< sdaftuar>
yeah
< sdaftuar>
hmm
< sdaftuar>
oh yeah the mocktime thing
< sdaftuar>
in #7164
< wumpus>
yeah
< wumpus>
should be easy to resolve
< wumpus>
(add-add conflict)
< sdaftuar>
yep agreed.
< sdaftuar>
just want to make sure the 0.12 backport will be clean before i push
< sdaftuar>
ok when i fix the issue and try to cherrypick to 0.12, i get a conflict to resolve. it's easy to fix, but would it better to open a second PR for the 0.12 branch which is clean?
< sdaftuar>
ah, if i just move my new method to further down in the file, then no conflict in 0.12. i'll just do that for simplicity
< bsm117532>
Is it possible to be invited to the bitcoincore slack channel? Is relevant dev discussion happening there or is it essentially all here?
< michagogo>
Slack?
< jonasschnelli>
bitcoincore.slack.com (no invitation required)
< instagibbs>
bsm117532, mostly a community outreach deal. CEOs, press, others actually idle there now
< bsm117532>
Ok thanks
< bsm117532>
instagibbs: It looks like I can't log into bitcoincore.slack.com without an invitation. But not so concerned about it, the last thing I need is another chat I have to pay attention to!
< michagogo>
What is that, who uses it, and what for?
< bsm117532>
Let's just use IRC. ;-)
< instagibbs>
michagogo, "mostly a community outreach deal. CEOs, press, others actually idle there now"
< btcdrak>
instagibbs: it's also for Bitcoin Core community to gather
< btcdrak>
it's not a replacement for IRC or developer collaboration though, that remains in IRC.
< instagibbs>
^^ that's what I meant
< bsm117532>
Thanks btcdrak. Looked briefly, this looks like it's probably about as useful as the #bitcoin IRC channel (very low signal/noise, no serious dev discussion)...
< michagogo>
cfields: just checking, you saw that wumpus figured out the fix, right?
< cfields>
michagogo: the gitian issue, you mean?
< michagogo>
yeah
< michagogo>
(at the cost of a non-matching in hash)
< cfields>
michagogo: yea, i saw. did't look into it, though. I guess lxc doesn't install python but kvm does, somehow?
< michagogo>
It would seem so.
< cfields>
weird
< cfields>
i suppose we should put it in the descriptor then. obviously it's needed, even if it happens to be pulled in by something else already
< michagogo>
I guess it boils down to debootstrap vs pxc
< michagogo>
lxc*
< michagogo>
Yeah, I wonder what changed from 0.11 to 0.2
< michagogo>
0.12*
< cfields>
michagogo: does trusty only install python3 by default, maybe?
< cfields>
(or default to it)
< michagogo>
If so, kvm should also fail
< michagogo>
And I don't think they're there yet. IIRC I saw on the MLs that they're working on removing it from the default packages in xenial...
< cfields>
michagogo: i was thinking part of the kvm install switched the default somehow
< cfields>
but yea, that doesn't really make sense
< michagogo>
the question is really what does debootstrap do different from vmbuilder
< michagogo>
And yeah, https://wiki.ubuntu.com/Python confirms. Under "Plans for 16.04": UOS for Xenial had a session on the removal of Python 2.7 from the default images/seeds.
< cfields>
ok
< michagogo>
so there are 3 real questions. 1) why does debootstrap not install python? 2) what changed from 0.11 to 0.12? and 3) why does this only affect OS X?
< Luke-Jr>
cfields: I'm trying to add a depends pkg for qtsvg, and I have it with a dependencies on qt, but how do I get qmake? :/
< cfields>
michagogo: unsure on all counts :\
< cfields>
Luke-Jr: yuck, what's qtsvg for?
< Luke-Jr>
cfields: I want to make the icons SVG only? :/
< cfields>
Luke-Jr: isn't that just a config switch for the qt build?
< cfields>
to enable the svg module?
< Luke-Jr>
no, qtsvg is the svg module
< cfields>
Luke-Jr: right. ./configure ... -svg
< Luke-Jr>
…
< cfields>
Luke-Jr: oh, i see the confusion, i think
< cfields>
Luke-Jr: we grab the modules, put them in place, then tell qt's main configure which ones to build
< Luke-Jr>
cfields: yuck? :P
< Luke-Jr>
why can't packages use their dependencies?
< cfields>
Luke-Jr: shrug, it never seemed to work well for me to try to split it into native/target builds
< Luke-Jr>
oh!
< cfields>
you're welcome to give it a shot, of course :)
< Luke-Jr>
so I need to depend on native too, makes sense
< michagogo>
So the answer is to add ..qtsvg....tar.gz to the qt package file list, and then add the configure flag?
< cfields>
Luke-Jr: yea, the tools are native, but qt doesn't make it easy to _just_ build the native parts. so in the end, it's easier to just build it all in one go
< Luke-Jr>
eh, but there's no native-qt pkg
< cfields>
Luke-Jr: what michagogo said. see qttranslations as an example
< Luke-Jr>
cfields: that's ugly though :<
< cfields>
Luke-Jr: very.
< cfields>
Luke-Jr: maybe they've fixed it up lately and you'll have better luck these days splitting it up
< Luke-Jr>
:|
< Luke-Jr>
so how would I get access to qmake?
< cfields>
Luke-Jr: you'd have to create a native package for just qmake/rcc/etc
< Luke-Jr>
eh, nothing else already uses qmake?
< cfields>
then add that as a dependency to the child package
< cfields>
Luke-Jr: no, only qt internally
< Luke-Jr>
i c
< cfields>
Luke-Jr: see protobuf as an example of native/target split
< Luke-Jr>
nah, if you and Gentoo both couldn't figure it out, I'll give up and go the qttranslations route
< cfields>
Luke-Jr: heh, they do it the same way?
< Luke-Jr>
no, but they don't make qmake available independently
< cfields>
Luke-Jr: from what i could tell last time, trying to build just the native tools was painful, as well as trying to force the rest of the build stuff to use an out-of-tree qmake/rcc
< cfields>
Luke-Jr: they probably make lots of assumptions that the versions being built are the ones used to compile the rest. kinda understandable.
< Luke-Jr>
//home/ubuntu/cache/common/qttools-opensource-src-5.5.0.tar.gz: OK
< Luke-Jr>
tar: /home/ubuntu/cache/common/qtsvg-opensource-src-5.5.0.tar.gz: Cannot open: No such file or directory
< Luke-Jr>
cfields: any idea why it wasn't fetched? :x
< cfields>
Luke-Jr: not without seeing what you changed