< dermoth>
Hey... I worked out a small speedup to initial blockchain load from bootstrap.dat (and likely rescan operations)... If you're interested it would be best implemented as a separate thread in the bitcoin node...
< dermoth>
the details are in comments, but basically I ensure each blockfile is loaded in OS cache before bitcoin-qt opens them while rescanning the whole blockchain
< gmaxwell>
dermoth: did you benchmark it? did it help?
< dermoth>
the percent per hour went from around 4 to 7... nothing really scientific
< gmaxwell>
wumpus: I was looking at the rc1 release notes and I see there isn't a list of commits in it... are we dropping them or are they just not there yet?
< dermoth>
but I know it's not going to spend much time on IO for the SSD, so the slowness comes manly from reading blocks.... There's a couple other things loading those disks too
< gmaxwell>
wumpus: (and do you need help with them)
< dermoth>
I just thought I'd share...
< gmaxwell>
Thanks.
< sipa>
gmaxwell: i assume the final list of commits will only be added when final
< sipa>
and iirc wumpus has some tooling for that
< gmaxwell>
OK. It's the best part of the release notes (IMO) :) so I just wanted to make sure we weren't losing it.
< dermoth>
timed two days's import times each without and with the script running... without: Jan 15-16: 73s; Jan 16-17: 71s; -- with: Jan 18-19: 58s, Jan 19-20: 67s
< dermoth>
not a big diff indeed, but does speed up a bit at least on my setup
< dermoth>
that's blocks from January this year...
< dermoth>
ugh, it's ionice not schedtool I should have been using :/
< dermoth>
ionice -c 3 <command>
< wumpus>
gmaxwell: yes, I'll add that in later
< wumpus>
the only thing I've done is sync from the wiki, and then I had to get a list of names from git too, as crediting only the people mentioned on the wiki was a bit strange
< arowser>
Hi, if exists a place that can download the dbg file that split from the released bitcoin core ?
< jonasschnelli>
arowser: dbg? You mean the debug symbols?
< arowser>
yes
< wumpus>
AFAIK no one hosts that - they're huge
< achow101>
arowser: for which version?
< arowser>
0.14.2
< achow101>
hmm. I have those locally
< wumpus>
I don't have them at the moment (they're easy to build though)
< achow101>
is there a command line way to put release assets on github? I can upload mine to github, but I'm away from that computer right now
< wumpus>
there might be a way through the API
< achow101>
bleh. the API is a mess
< wumpus>
that might be, but it's the way to do website things though e.g. a command line tool. Easier at least than reverse-engineering what the website does...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10752: Use quoted form when including primitives/transaction.h and wallet/wallet.h (master...transaction-h) https://github.com/bitcoin/bitcoin/pull/10752
< wumpus>
arowser: I meant it's easy for me, and I'd have built them if achow101 and jonasschnelli hadn't jump in
< wumpus>
jonasschnelli: yes
< promag>
MarcoFalke: is nc something we could use in tests?
< MarcoFalke>
Sorry, what is nc?
< promag>
netcat
< MarcoFalke>
The tests should run on windows as well, so I don't think this would be possible
< promag>
right
< promag>
the idea is to avoid files, have the blocknotify script write to a socket, then read it from python
< MarcoFalke>
oh wait. I am sure blocknotify.py is unlikely to pass on native windows, due to echo.
< MarcoFalke>
So my objection is invalid
< MarcoFalke>
Though, I am not convinced this warrants the extra dependency. It should be doable with just files.
< promag>
we can also ship util scripts to be used in these tests?
< MarcoFalke>
There should be no "loose" scripts hanging around. You can extend ./test_framework/util.py with helper functions.
< promag>
right
< bitcoin-git>
[bitcoin] laanwj opened pull request #11053: refactor: Make all #includes relative to project root (master...2017_08_includes_absolute) https://github.com/bitcoin/bitcoin/pull/11053
< MarcoFalke>
^ does this require mention in the release notes for 0.16?
< MarcoFalke>
oh already listed: #11054 :)
< bitcoin-git>
[bitcoin] jnewbery opened pull request #11055: getreceivedbyaddress should return error if called with address not owned by the wallet (master...getreceivedbyaddress_error) https://github.com/bitcoin/bitcoin/pull/11055
< cfields>
wumpus: i think #7522 broke version detection for gitian. v0.15.0rc1 binaries show -dirty :(
< cfields>
imo that's no big deal for rc1. I'll try to track down the issue
< cfields>
luke-jr: ^^
< luke-jr>
hmm
< cfields>
luke-jr: i'm just assuming 7522 is what did it, as I can't think of what else might've changed in that regard
< gribble>
https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub
< luke-jr>
cfields_: 7522 is a bug fix. it should not be reverted.
< luke-jr>
unless you have a better fix, I guess.
< cfields_>
luke-jr: suggestions for fixing the issue, then? Setting GIT_DIR in the gitian script throws off 'git diff' in a way that i don't really understand
< luke-jr>
probably the best way, would be to have the tarball-source build with the version we want, and don't rely on git at all
< luke-jr>
maybe that's already the case, and we should just drop GIT_DIR?
< cfields_>
luke-jr: agreed, but i think it's too late for those types of changes for 0.15
< luke-jr>
what happens if we just drop GIT_DIR right now?
< cfields_>
pretty sure it ends up with unknown version
< luke-jr>
:/
< luke-jr>
does that mean building from the source tarball is similarly broken?
< cfields_>
hmm, probably
< cfields_>
checking
< cfields_>
"Bitcoin Core Daemon version v0.15.0.0-g252ca9c"
< luke-jr>
I guess that's what we want?
< cfields_>
well the tag would be ideal, but i don't think it's different from before
< cfields_>
what's broken is the tag detection when building from git because the work-tree check now fails
< luke-jr>
IMO we should have it so the result is the same as building from the source tarball, and if that isn't what is ideal, we should fix that so it is ;)
< cfields_>
er, that's not right. I think that works, but 'git diff' thinks there are extra files dirtying things up
< luke-jr>
the work-tree check *should* fail in gitian, since gitian doesn't build from git
< cfields_>
it builds from a workdir that's part of the git tree
< luke-jr>
it's not part of the git tree..
< luke-jr>
it just happens to be in a directory below the git tree's root
< cfields_>
it builds in a subdir of the repo
< cfields_>
right
< cfields_>
sorry, work-tree has a specific meaning in this discussion :)
< luke-jr>
one that isn't met by what we're doing there ;)
< cfields_>
yea, we need to change the gitian layout and embed the version into the tarball. But I'd really not do all that at this stage
< luke-jr>
"v0.15.0.0-g252ca9c" seems fine until we do?
< cfields_>
luke-jr: it's what shows on the splash screen. All other stable versions have had the correct (tag) string.
< luke-jr>
a simple hacky workaround would be to have gitian make a build.h file
< bitcoin-git>
bitcoin/master 08f71c2 Gregory Maxwell: [Trivial] Add a comment on the use of prevector in script.
< bitcoin-git>
bitcoin/master 7db65c3 MarcoFalke: Merge #11011: [Trivial] Add a comment on the use of prevector in script....
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11011: [Trivial] Add a comment on the use of prevector in script. (master...201708-prevector-comment) https://github.com/bitcoin/bitcoin/pull/11011