1 2015-06-03 00:07:45 <warren> somebody file a ticket
  2 2015-06-03 00:10:53 <btcdrak> done in #6223
  3 2015-06-03 01:41:06 <sipa> ;;nethash
  4 2015-06-03 01:41:07 <gribble> 343005830.794
  5 2015-06-03 06:38:59 <Luke-Jr> sipa: my practical application involves iterating over the blockchain for analysis
  6 2015-06-03 13:35:21 <wumpus> is there anyone with serious sed (the unix tool) skills in here that can review this? https://github.com/bitcoin/bitcoin/pull/5872/files
  7 2015-06-03 13:38:01 <wangchun> gmaxwell: I am trying to build Bitcoin Core v0.10.2, got error while running autogen.sh:
  8 2015-06-03 13:38:04 <wangchun> Makefile.am:5: user variable `GZIP_ENV' defined here...
  9 2015-06-03 13:38:08 <wangchun> /usr/share/automake-1.11/am/distdir.am: ... overrides Automake variable `GZIP_ENV' defined here
 10 2015-06-03 13:38:15 <wangchun> Makefile.am:48: user target `distcleancheck' defined here...
 11 2015-06-03 13:38:15 <wangchun> /usr/share/automake-1.11/am/distdir.am: ... overrides Automake target `distcleancheck' defined here
 12 2015-06-03 13:38:33 <wangchun> no issue building version 0.9.5
 13 2015-06-03 13:43:54 <hulkhogan_> wangchun: update automake
 14 2015-06-03 13:44:11 <hulkhogan_> wangchun: and autotools libtool etc
 15 2015-06-03 14:10:44 <sdaftuar> wumpus: what do you think of including any of the proposed fixes for #6184 in rc1?
 16 2015-06-03 14:11:10 <sdaftuar> ie #6221, #6224
 17 2015-06-03 14:14:43 <wumpus> sdaftuar: we can keep going forever merging things for rc1, but at some point we have to cut a release candidate
 18 2015-06-03 14:15:54 <wumpus> (the idea was to do that monday, but we've again slipped a few days, because a mac renaming issue and today's JSON problem)
 19 2015-06-03 14:17:09 <wumpus> #6221 and #6224 have had no ACKs at all yet
 20 2015-06-03 14:17:12 <sdaftuar> ok, i thought it would be good to include a fix for a reported problem, do you think there would still be time to do that before 0.11 is finalized?
 21 2015-06-03 14:18:01 <wumpus> well this is a major release, I'm sure rc1 won't be the last rc
 22 2015-06-03 14:18:12 <hearn> is there any way in gitian to retrieve the build outputs after a different build has started?
 23 2015-06-03 14:18:16 <hearn> or does it really delete the files for good?
 24 2015-06-03 14:18:24 <sdaftuar> ok.  separately, any reason not to merge 5875?  it has a few ack's
 25 2015-06-03 14:18:25 <wumpus> there's probably tons of other problems that need to be solved too, but the only way to get testing on a larger scale is to do rcs
 26 2015-06-03 14:18:36 <wumpus> hearn: they're gone for good :(
 27 2015-06-03 14:18:57 <wumpus> hearn: shot myself in the foot so many times, I now have a script that automatically copies the build output
 28 2015-06-03 14:19:59 <wumpus> sdaftuar: that IS a good point
 29 2015-06-03 14:21:21 <wumpus> sdaftuar: I planned on merging that but somehow got lost in the queue
 30 2015-06-03 14:21:24 <sdaftuar> great, thanks
 31 2015-06-03 14:25:27 <wumpus> ok, merged to 0.11 and master
 32 2015-06-03 14:38:33 <hearn> wumpus: yeah, my foot is bleeding a bit at the moment , sigh :(
 33 2015-06-03 14:39:11 <wumpus> hearn: at least with 0.10+ the depends cache keeps around a large part of the result, so the second time will be faster
 34 2015-06-03 14:39:27 <hearn> hmm. it looks like it's rebuilding qt though
 35 2015-06-03 14:39:48 <slkz9> does anyone here have any experience with building :master on openbsd?
 36 2015-06-03 14:43:15 <wumpus> slkz9: it should be the same as building for linux
 37 2015-06-03 14:43:43 <wumpus> (at least you're not the first to compile it on *bsd, there have been various compile fixes for it, so it should just work)
 38 2015-06-03 14:44:00 <slkz9> should :] well i managed to build it yesterday actually, but the tests tank
 39 2015-06-03 14:44:42 <slkz9> read through the issues on github but couldnt find anything relevant to my error
 40 2015-06-03 14:45:38 <slkz9> i get this when running tests:  /bitcoind:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.17.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your program
 41 2015-06-03 14:46:10 <cfields> estdc++.so ?
 42 2015-06-03 14:48:41 <slkz9> must've been too early in the morning didn't even notice the -e- -.- why does it link like that? (im not exactly an expert on c++ so go easy on me) :]
 43 2015-06-03 14:49:04 <cfields> wumpus: have you done gitian builds of 0.11 to be sure that there are no major build issues before tagging?
 44 2015-06-03 14:49:21 <cfields> either way, i'll kick some off now
 45 2015-06-03 14:49:34 <wumpus> cfields: not yet, good idea
 46 2015-06-03 14:49:39 <cfields> slkz9: well is that the stdlib that you link against?
 47 2015-06-03 14:50:32 <cfields> i've not seen that name before, i assume it's an openbsd thing.
 48 2015-06-03 14:52:05 <slkz9> yeah i guess, i'll look into it now when im not half asleep. thx
 49 2015-06-03 14:53:34 <cfields> np. I'm not sure what that path is telling you... My guess would be that you built with a toolchain that uses its own (its in /usr/local) stdlib, but you're hitting the system one at runtime
 50 2015-06-03 15:09:18 <cfields> BlueMatt: ping. What are the odds that there were local modifications to the .jar that is currently in-use for the pull-tests?
 51 2015-06-03 15:10:56 <cfields> unless you're 100% certain that it's exactly what's in git, I'm going to PR a new .jar that corresponds exactly, so that we can have correct line numbers in stacktraces and address the current test failures
 52 2015-06-03 15:25:13 <wumpus> cfields: yes, we should really try to get this travis issue in order
 53 2015-06-03 15:25:25 <wumpus> cfields: if it keeps up like this I'm going to disable the comparison tool
 54 2015-06-03 15:26:07 <wumpus> a few false positives are okay, but having to re-trigger about 10 travis builds per day is not acceptable
 55 2015-06-03 15:26:25 <cfields> yea, it's really annoying. I should think it'd be an easy fix too
 56 2015-06-03 15:27:07 <cfields> wumpus: how about i go ahead and PR a new .jar that will give us good line numbers so we can work on it? If you were thinking of disabling it anyway, i don't see the harm in poking at it a little first
 57 2015-06-03 15:27:19 <wumpus> I think we should add the latest version of the tool (as used for testing) into a repository under bitcoin/
 58 2015-06-03 15:27:27 <wumpus> so that everyone can find it and build it
 59 2015-06-03 15:27:39 <gavinandresen> +1 for making it easy to find and build
 60 2015-06-03 15:28:13 <cfields> wumpus: i think the reason that hasn't been done yet is because BlueMatt wants it to die in a fire
 61 2015-06-03 15:28:38 <gavinandresen> When's the last time it found an actual issue?  If more than six months, maybe it SHOULD be retired....
 62 2015-06-03 15:28:39 <wumpus> cfields: right, we're on the way to replacing it anyway
 63 2015-06-03 15:29:05 <cfields> gavinandresen: i saw it yelling at Luke-Jr's PRs a few days ago. Not sure if that was expected or not though
 64 2015-06-03 15:29:27 <hearn> it *is* easy to build
 65 2015-06-03 15:29:33 <hearn> i posted instructions for how to build it months ago
 66 2015-06-03 15:29:38 <wumpus> cfields: more and more python P2P tests in the repository
 67 2015-06-03 15:29:41 <hearn> it's a couple of commands, if you have the right tools
 68 2015-06-03 15:30:05 <cfields> hearn: sure, takes about 5sec. The current problem is actually tracking down the issue that Travis is currently running against
 69 2015-06-03 15:30:07 <wumpus> hearn: one problem is that we don't know where to find the latest source code
 70 2015-06-03 15:30:19 <cfields> *tracking down the version
 71 2015-06-03 15:30:33 <hearn> hmm, the latest one i know about is in the bitcoinj repository
 72 2015-06-03 15:30:36 <hearn> is there another?
 73 2015-06-03 15:30:53 <cfields> hearn: yea, it's a hacked up version in BlueMatt's repo
 74 2015-06-03 15:30:55 <wumpus> bluematt has had his own for a while
 75 2015-06-03 15:31:32 <hearn> i thought the patches were merged back in
 76 2015-06-03 15:31:39 <cfields> and worse, the specific commit has been rebased away, so it can't be cloned/fetched by git. I have a local clone for posterity
 77 2015-06-03 15:32:58 <cfields> hearn: https://github.com/TheBlueMatt/bitcoinj/commits/0f7b5d89b5f70c0803d36e690b702b5050771381
 78 2015-06-03 15:34:06 <hearn> yes i believe those commits are all in bitcoinj git msater
 79 2015-06-03 15:34:18 <cfields> that's what the .jar was built from. But I'm not sure there weren't local changes applied
 80 2015-06-03 15:34:31 <hearn> hm
 81 2015-06-03 15:34:48 <hearn> ok. well doing "mvn package" in bitcoinj (either last stable or git master) should produce a pull-tester.jar file that works
 82 2015-06-03 15:34:56 <hearn> i haven't tried it for a while in git master. i must do that before release.
 83 2015-06-03 15:35:01 <hearn> i doubt there are any regressions but you never know
 84 2015-06-03 15:35:46 <nsh> [nominally off-topic] can there be another consideration of cutting residual ties to sourceforge maybe? (i think it's just the mailing lists, are they particularly hard to migrate?)
 85 2015-06-03 15:35:50 <cfields> I can do that now and see how it fares
 86 2015-06-03 15:35:58 <wumpus> cfields: any luck with the pre-0.11 tag builds?
 87 2015-06-03 15:36:26 <cfields> wumpus: still building (has to build from scratch since we changed the cache path)
 88 2015-06-03 15:36:55 <cfields> osx/win32 built ok
 89 2015-06-03 15:41:27 <hulkhogan_> 'mvn package' worked for me last i checked, i had to pull in the dep list from bitcoinj upstream into bluematt's repo, but it was building
 90 2015-06-03 15:42:44 <hulkhogan_> one of the discouraging things about that comparisontool is the strongly worded warning near the header about modifying/updating the tool, but the other discouraging parts are the testcases that aren't well documented (and need contextual information to find out what is being tested)
 91 2015-06-03 15:43:59 <hearn> it could use a rewrite
 92 2015-06-03 15:44:02 <hearn> nobody has done it though
 93 2015-06-03 15:44:10 <hearn> i did a bit of refactoring a while ago to reduce the amount of duplication, but it's a big job
 94 2015-06-03 15:44:20 <wumpus> it's slowly being transitioned to the pyton P2P testing framework
 95 2015-06-03 15:44:59 <wumpus> sdaftuar did quite some work on it, among others
 96 2015-06-03 15:45:00 <hulkhogan_> is that code public? the port
 97 2015-06-03 15:45:27 <hulkhogan_> ah sorry nvm
 98 2015-06-03 15:45:57 <hearn> does anyone know of a problem whereby Core might sometimes not respond to a getblocks request?
 99 2015-06-03 15:45:57 <sdaftuar> i'm working on reimplementing the first few tests from the java tool in python, hoping to PR something in the next week
100 2015-06-03 15:46:22 <hulkhogan_> sdaftuar: nice!
101 2015-06-03 15:46:29 <cfields> imo we should just work to maintain the status quo. Anything else is unlikely to actually get done and fix the current false-positive problem. Ideally (imo) we'd just fix the current NPE and leave the rest as-is
102 2015-06-03 15:46:58 <cfields> (fix the problem in days, as opposed to weeks/months, that is)
103 2015-06-03 15:47:02 <wumpus> cfields: agreed, we just need to squash the random-hang issue now
104 2015-06-03 15:48:14 <hulkhogan_> its definitely due to a bad/outdated test... but there is some work in finding out what is going wrong (iirc it was near the 80th or so testblock)
105 2015-06-03 15:48:33 <cfields> wumpus: ok, then. Let's do that. I'll PR the change with a rebuilt .jar at the current git commit.
106 2015-06-03 15:49:27 <wumpus> hearn: not that I know of
107 2015-06-03 15:52:53 <sdaftuar> hearn: there's an open pull (ie not in master) to make pruning nodes not respond to getblocks requests for data they don't actually have on disk, but i assume that isn't what you're talking about.
108 2015-06-03 15:53:02 <hearn> no, don't think so
109 2015-06-03 15:53:30 <hearn> i'm chasing a rare bug where bitcoinj gets stuck. the logs strongly suggest that it sent a getdata (sorry, not getblocks) and never got a response.
110 2015-06-03 15:53:50 <hearn> this is new and i didn't change block download logic for a long time, so i'm trying to figure out if it's a regression in bcj or if it's some odd thing that started with headers-first
111 2015-06-03 15:54:06 <wumpus> this could explain the hang issue
112 2015-06-03 15:56:34 <hearn> possibly
113 2015-06-03 15:56:45 <hearn> i thought it was an NPE rather than a hang though
114 2015-06-03 15:56:50 <hearn> i guess we can investigate
115 2015-06-03 15:57:42 <cfields> hearn: yes, it's an NPE that causes the test to hang indefinitely
116 2015-06-03 15:57:57 <cfields> hearn: https://s3.amazonaws.com/archive.travis-ci.org/jobs/65112154/log.txt
117 2015-06-03 15:58:05 <cfields> and: https://s3.amazonaws.com/archive.travis-ci.org/jobs/62433593/log.txt
118 2015-06-03 15:58:59 <hearn> do you have a successful run to compare with?
119 2015-06-03 15:59:17 <hearn> huh line 311 vs 322
120 2015-06-03 15:59:41 <cfields> https://s3.amazonaws.com/archive.travis-ci.org/jobs/64925256/log.txt
121 2015-06-03 15:59:59 <cfields> hearn: yea, took me forever yesterday to find both occurances.
122 2015-06-03 16:00:10 <cfields> hearn: 99% die at line 311, but rarely it hits 322 also
123 2015-06-03 16:00:30 <cfields> the corresponding source is: https://github.com/TheBlueMatt/bitcoinj/blob/0f7b5d89b5f70c0803d36e690b702b5050771381/core/src/test/java/com/google/bitcoin/core/BitcoindComparisonTool.java#L311
124 2015-06-03 16:00:55 <cfields> but as you said yesterday, the line numbers can't be entirely trusted
125 2015-06-03 16:01:47 <cfields> i had a wacky theory wrt races on the ping.get(), but bad line numbers sounds much more reasonable
126 2015-06-03 16:04:34 <hearn> if you trace the code through an NPE on that line is impossible
127 2015-06-03 16:04:38 <hearn> even in the presence of races
128 2015-06-03 16:06:46 <hulkhogan_> need to wrap those and print a stacktrace eh
129 2015-06-03 16:13:54 <cfields> hearn: a pong sets the ping's future to null, no?
130 2015-06-03 16:14:08 <hearn> no
131 2015-06-03 16:14:10 <hearn> it completes the future
132 2015-06-03 16:14:29 <hearn> you can't erase an object reference some other code is holding on the stack in java anyway
133 2015-06-03 16:23:33 <cfields> hearn: the complete wacky theory was that if Math.random() (in ping()) was really bad on travis, it could result in a race where the wrong ping is complete()d
134 2015-06-03 16:24:08 <hearn> that'd cause a hang but not a crash, i think
135 2015-06-03 16:25:17 <cfields> complete() sets the future to null afterwards, though. Or am I trying really hard to make java work like c++ in my head? :)
136 2015-06-03 16:25:27 <hearn> yes :-)
137 2015-06-03 16:25:34 <cfields> heh, roger.
138 2015-06-03 16:25:37 <hearn> you cannot "set the future to null".
139 2015-06-03 16:25:44 <hearn> as long as some code has a reference to it, the object will live
140 2015-06-03 16:26:26 <cfields> ok
141 2015-06-03 16:30:38 <cfields> wumpus: gitian builds of osx/linux look good. Quickly sanity checked. windows built fine.
142 2015-06-03 16:32:08 <cfields> and the osx rename worked beautifully. Great work jonasschnelli.
143 2015-06-03 16:33:10 <wumpus> cfields: thanks for checking
144 2015-06-03 16:33:34 <wumpus> yes, great solution re:osx
145 2015-06-03 17:15:43 <wumpus> cfields: btw, re: https://github.com/bitcoin/bitcoin/pull/6220, we should try to get rid of the duplicated version information at some point
146 2015-06-03 17:16:02 <wumpus> too easy to forget one
147 2015-06-03 17:16:26 <cfields> wumpus: well we could just kill it, but it's useful for those who build outside of autotools (msvc)
148 2015-06-03 17:16:59 <wumpus> I guess, but there's no way we can make autoconf and the include file use the same source?
149 2015-06-03 17:17:01 <cfields> not really sure how we could de-duplicate without reducing functionality
150 2015-06-03 17:17:35 <cfields> well autoconf sets the version itself, that way it can be used for filenames
151 2015-06-03 17:18:02 <wumpus> maybe we can add a check that fails if the information is out of sync?
152 2015-06-03 17:18:16 <cfields> there may be some format that could be imported and also used by a header...
153 2015-06-03 17:18:42 <cfields> wumpus: how about just setting the version to UNKNOWN or so for the msvc case?
154 2015-06-03 17:19:11 <wumpus> or alternatively, make it possible to automatically generate the file before checking them in (eg make version or such)
155 2015-06-03 17:19:33 <cfields> as-is, i think it can be overridden with -DMAJORVERSION=1 or similar
156 2015-06-03 17:20:09 <cfields> i'll poke at it some
157 2015-06-03 17:20:19 <wumpus> thanks
158 2015-06-03 17:22:49 <wumpus> ok, going to tag - I also succeeded in gitian building 0.11 (well, windows and linux, I don't have the new macosx sdk)
159 2015-06-03 17:24:35 <wumpus> * [new tag]         v0.11.0rc1 -> v0.11.0rc1
160 2015-06-03 17:24:41 <cfields> :)
161 2015-06-03 17:30:49 <cfields> wumpus: ah, while i'm thinking about it, could you please create a repo for binary signatures? I've come up with a nice way for gitian to use the repo to fetch/apply the sigs as necessary
162 2015-06-03 17:34:49 <wumpus> cfields: sure, any preferences for a name?
163 2015-06-03 17:35:30 <wumpus> bitcoin-binary-sigs?
164 2015-06-03 17:35:32 <cfields> wumpus: detached-release-signatures ?
165 2015-06-03 17:35:54 <wumpus> ok, bitcoin-detached-sigs
166 2015-06-03 17:36:23 <cfields> sounds great, thanks
167 2015-06-03 17:39:35 <wumpus> cfields: you should have push access
168 2015-06-03 17:42:29 <cfields> great. Want me to target 0.11 for the change in procedure? Or skip to 0.12 ?
169 2015-06-03 17:44:15 <wumpus> cfields: well, 0.11 final is likely still some weeks away, I highly doubt this will be the last rc, so let's just target 0.11
170 2015-06-03 17:44:16 <cfields> it'll just change from "wget file && ./gbuild" to "./gbuild -c bitcoin-detached-sigs=v0.1x"
171 2015-06-03 17:44:29 <cfields> ok
172 2015-06-03 17:46:13 <wumpus> let's also put the previous detached sigs in the repository
173 2015-06-03 17:46:54 <wumpus> I still have a few, but you probably have a better idea what you want the directory structure to be like
174 2015-06-03 17:48:18 <BlueMatt> cfields: Ive been 100% on work stuff for the past few days, and plan to be for the next few....honestly i dont recall at all where the one running is anymore because of #5422
175 2015-06-03 17:49:19 <cfields> BlueMatt: i know where it's running, i just don't know if there were local modifications on top of that commit. Looks like it's safe to assume there were
176 2015-06-03 17:50:14 <cfields> wumpus: ok, i'll dump 'em there. I'm going to handle via tags rather than a list-of-version dir structure, that way it can be used with gitian's -c
177 2015-06-03 17:50:22 <cfields> the tags will just coincide with bitcoin release tags
178 2015-06-03 17:51:13 <wumpus> ok
179 2015-06-03 17:51:34 <BlueMatt> cfields: the build that is running absolutely had code on github for it
180 2015-06-03 17:51:47 <BlueMatt> though there may no longer be a branch pointing to it
181 2015-06-03 17:52:55 <cfields> BlueMatt: yes, https://github.com/TheBlueMatt/bitcoinj/commits/0f7b5d89b5f70c0803d36e690b702b5050771381. The question is: when you built the jar, what local changes did you have that weren't committed
182 2015-06-03 17:53:23 <BlueMatt> cfields: there is no way there were local changes when it was built
183 2015-06-03 17:53:35 <BlueMatt> if there were, I fucked up big time, but I certainly intended there not to be
184 2015-06-03 17:54:33 <cfields> BlueMatt: hearn is confident that NPEs can't be hit at the reported lines. You two can duke it out :)
185 2015-06-03 18:06:29 <BlueMatt> cfields: yes, I looked briefly at the lines and was very confused by that as well
186 2015-06-03 18:12:55 <BlueMatt> cfields: my only recommendation is to disable it for now and I'll try to fix #5422 soon
187 2015-06-03 18:13:42 <BlueMatt> (as in early next week)
188 2015-06-03 18:16:51 <cfields> ok. Before disabling, I'd still like to push up a clean .jar so that we can know if the line#s are good
189 2015-06-03 22:12:00 <jonasschnelli> 930b1796229986854623f7a76d47aa0a2f485f91c5f4a50087637418aedf667c  bitcoin-0.11.0-linux32.tar.gz --> match?
190 2015-06-03 22:18:51 <gmaxwell> ::sigh:: 0.11 does not compile foe me, barfing out scheduler.cpp:54:101: error: no match for ‘operator!=’ in
191 2015-06-03 22:19:36 <gmaxwell> (wait_until)
192 2015-06-03 22:21:39 <jonasschnelli> gmaxwell: hmm... we had this problem alerady... let me search the logs
193 2015-06-03 22:24:54 <jonasschnelli> http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/05/26#l1432630546.0
194 2015-06-03 22:25:59 <jonasschnelli> but there was no solution logged. Maybe a boost <1_55 issue
195 2015-06-03 22:27:19 <gmaxwell> jonasschnelli: I'd already tried autoregen and cleaning and such before mentioning it alas.
196 2015-06-03 22:32:10 <cfields> gmaxwell: what boost version?
197 2015-06-03 22:33:08 <gmaxwell> cfields: 1.52
198 2015-06-03 22:34:38 <cfields> gmaxwell: can you stick an #error in the correct ifdef chunk to make sure that the set versions are working?
199 2015-06-03 22:35:03 <cfields> whoops, nm. line number says it all
200 2015-06-03 22:38:49 <Luke-Jr> remember to remove src/bitcoin-config.h?
201 2015-06-03 23:04:01 <mssbrg> why do all the linux binaries appear as ELF shared objects instead of executables, when run under `file`?
202 2015-06-03 23:04:12 <mssbrg> talking about bitcoin core binaries
203 2015-06-03 23:09:05 <Luke-Jr> mssbrg: PIE
204 2015-06-03 23:11:25 <mssbrg> Luke-Jr: why do they need to be position independent?
205 2015-06-03 23:11:35 <Luke-Jr> mssbrg: it's a security enhancement
206 2015-06-03 23:11:51 <Luke-Jr> makes some exploits harder in practice
207 2015-06-03 23:23:33 <phantomcircuit> https://github.com/bitcoin/bitcoin/pull/6228
208 2015-06-03 23:23:44 <phantomcircuit> simple patch to jumpstart headers sync