1 2015-02-23 00:35:37 <gmaxwell> denisx: run test_bitcoin which will tell you specifically which test failed (probably broken exception handingly either in your compiler or stdc++) and pay a dollar into the sin-jar for trying to run the software without running the included tests first.
2 2015-02-23 00:37:04 <gmaxwell> :)
3 2015-02-23 01:44:02 <koobs> denisx: you get the error during build?
4 2015-02-23 01:44:14 <Luke-Jr> koobs: that's a runtime error
5 2015-02-23 01:44:32 <koobs> Anyone know which version of C++ bitcoin needs? c++0x c++11 ?
6 2015-02-23 01:44:56 <koobs> Luke-Jr: im seeing a test failure here in the bitcoin freebsd port that im trying to isolate too, wondering if it is the same
7 2015-02-23 01:45:00 <cfields> koobs: 98
8 2015-02-23 01:45:06 <moa> c++0x is best for now ...
9 2015-02-23 01:45:42 <koobs> hmm..
10 2015-02-23 01:45:52 <cfields> koobs: failed sanity test?
11 2015-02-23 01:45:58 <koobs> cfields: iirc, yes
12 2015-02-23 01:46:27 <koobs> cfields: im trying to grok the results when bitcoin is built without --disable-tests
13 2015-02-23 01:46:35 <koobs> cfields: in terms of behaviour at run time
14 2015-02-23 01:46:53 <cfields> koobs: erm, if sanity check failed, first step is to build the tests
15 2015-02-23 01:46:55 <koobs> is it still usable end-user software when built with tests?
16 2015-02-23 01:47:04 <cfields> not sure why you'd be trying to grok anything else first
17 2015-02-23 01:47:17 <koobs> cfields: well, the build matters clearly
18 2015-02-23 01:47:20 <cfields> koobs: yes, the tests are a separate binary
19 2015-02-23 01:47:44 <koobs> cfields: does builting with tests change the bitcoin binary in anyway? (that is, not the _test binary)
20 2015-02-23 01:47:48 <sipa> no
21 2015-02-23 01:47:50 <cfields> no
22 2015-02-23 01:47:52 <koobs> great
23 2015-02-23 01:47:56 <koobs> </clarity>
24 2015-02-23 01:48:16 <cfields> koobs: we've seen lots of reports of this lately on uncommon setups. Can you let me know exactly how to reproduce in a vm?
25 2015-02-23 01:48:41 <cfields> should it be as simple as installing fbsd 9 and bitcoin from ports? self-build?
26 2015-02-23 01:48:49 <koobs> cfields: im just isolating the issue in the freebsd port right now, i'll know/understand more once im confortable that the build mechanics give bitcoin what it needs without hacks
27 2015-02-23 01:49:10 <koobs> cfields: this is to upgrade the port to 0.10.0
28 2015-02-23 01:49:29 <koobs> cc robbak ^^
29 2015-02-23 01:49:46 <denisx> koobs: no
30 2015-02-23 01:49:52 <koobs> denisx: no what?
31 2015-02-23 01:50:15 <cfields> koobs: the issue is almost certainly the uncaught exception at startup, missed std::out_of_range.
32 2015-02-23 01:50:15 <denisx> i did not get the message during build
33 2015-02-23 01:50:36 <koobs> cfields: it should be a simple matter of installing the port yes, independent of freebsd version,. as long as the port declares the right c++ version requirement, the ports framework can handle installing the right compiler if necessary
34 2015-02-23 01:50:46 <koobs> denisx: k, thanks
35 2015-02-23 01:50:54 <koobs> denisx: bitcoin 0.10.0 should be in ports soon
36 2015-02-23 01:51:07 <cfields> koobs: what is the compiler/libstdc++ in this case?
37 2015-02-23 01:51:42 <koobs> cfields: whats in base depends on the version of freebsd, for < 10, its gcc 4.2.1, after 10, its clang 3.3 (or 3.4 iirc)
38 2015-02-23 01:52:01 <cfields> koobs: i'm only interested in your particular case for now
39 2015-02-23 01:52:07 <sipa> gcc 4.2 is likely too old
40 2015-02-23 01:52:19 <koobs> sipa: hence the question about the c++ features/version desired
41 2015-02-23 01:52:39 <koobs> cfields sipa See: https://svnweb.freebsd.org/ports/head/Mk/Uses/compiler.mk?revision=375758&view=markup
42 2015-02-23 01:52:42 <sipa> nothing special there
43 2015-02-23 01:52:58 <cfields> koobs: could you please try building with --disable-reduce-exports ?
44 2015-02-23 01:53:21 <koobs> cfields: i need to get the port into a decent foundation state first, so i can them reproduce cleanly
45 2015-02-23 01:53:27 <cfields> koobs: ok, dump all of the c++11 stuff
46 2015-02-23 01:53:28 <koobs> i dont want any other variables in the mix
47 2015-02-23 01:53:32 <koobs> cfields: ok
48 2015-02-23 01:54:00 <Luke-Jr> moa: koobs: there is no such thing as C++0x
49 2015-02-23 01:54:18 <cfields> Luke-Jr: it's a gcc std option
50 2015-02-23 01:54:20 <koobs> Luke-Jr: yeh, im not looking for a lesson in C++ version semantics here
51 2015-02-23 01:54:27 <Luke-Jr> cfields: just an alias for C++11, no?
52 2015-02-23 01:54:30 <koobs> Luke-Jr: i grok that those drafts were replaced
53 2015-02-23 01:54:33 <koobs> yes
54 2015-02-23 01:55:18 <cfields> Luke-Jr: afaik they have separate but similar meanings. could be wrong, though
55 2015-02-23 01:55:26 <Luke-Jr> koobs: anyhow, neither LLVM nor GCC afaik have final C++11 support yet, so I'd stick to C++98 as cfields suggested
56 2015-02-23 01:55:58 <Luke-Jr> koobs: BUT, if the rest of the OS is built with C++11, you probably need to be consistent with it :x
57 2015-02-23 01:56:05 <Luke-Jr> since the ABIs are not compatible
58 2015-02-23 01:56:11 <koobs> Luke-Jr: perhaps im not being clear, all i need to do is declare what bitcoin wnats/needs, and the (ports) framework takes care of making sure a compiler that supports those features is installed and used
59 2015-02-23 01:56:23 <koobs> Luke-Jr: if the answers is c++98, thats easy
60 2015-02-23 01:56:27 <sipa> ok, no c++11 needed
61 2015-02-23 01:56:29 <sipa> done
62 2015-02-23 01:56:31 <koobs> awesome
63 2015-02-23 01:56:36 <koobs> sipa: thank you :)
64 2015-02-23 01:56:44 <Luke-Jr> koobs: well, for example, if your bdb++ is built with C++11, using C++98 for Bitcoin may be dangerous
65 2015-02-23 01:56:48 <koobs> im building (-utils) without that now to test
66 2015-02-23 01:56:59 <koobs> Luke-Jr: secondary question, but understood
67 2015-02-23 01:57:10 <koobs> Luke-Jr: there may or may not be a way to ensure they match
68 2015-02-23 01:57:19 <koobs> noted though
69 2015-02-23 01:57:54 <denisx> koobs: I have testet the ports patch from Robert Backhaus on FreeBSD 10, there ir works, but not on 9
70 2015-02-23 01:58:14 <koobs> ok so utils builds fine without c11 foo on 9-stable (FreeBSD clang version 3.4.1)
71 2015-02-23 01:58:25 <Luke-Jr> koobs: also, please do open/work on upstreaming any patching you need to do for BSD support - we have nobody working on BSD in mainline right now, but it'd be best to have things reviewed and supported upstream
72 2015-02-23 01:58:33 <koobs> denisx: i have a further patch, his one needed substantial work
73 2015-02-23 01:58:38 <koobs> Luke-Jr: of course
74 2015-02-23 01:58:45 <koobs> Luke-Jr: whats your CI environment?
75 2015-02-23 01:58:48 <cfields> Luke-Jr: i have a fbsd cross build ready to add to depends, i just haven't gotten around to cleaning it up yet
76 2015-02-23 01:58:53 <koobs> Luke-Jr: if you have builtbot id be happy to provide slaves
77 2015-02-23 01:59:02 <koobs> i do for Python, buildbot, x264 among others
78 2015-02-23 01:59:09 <Luke-Jr> koobs: GitHub has Travis integrated with multiple targets - but last I checked they only run on x86_64 Linux :/
79 2015-02-23 01:59:19 <koobs> yeh that sucks, trav doesnt support freebsd (yet)
80 2015-02-23 01:59:22 <Luke-Jr> cfields: oh, nice. but will it handle BSD-specific issues like this?
81 2015-02-23 01:59:30 <koobs> Luke-Jr: there is some chatter about adding support
82 2015-02-23 01:59:42 <sipa> Luke-Jr: compile time; running tests is harder i guess
83 2015-02-23 02:00:00 <cfields> Luke-Jr: sure, it uses the supplied sysroot
84 2015-02-23 02:00:04 <koobs> sipa: at least theres a simple make check to use
85 2015-02-23 02:00:11 <koobs> testng against gcc 4.2.1 now
86 2015-02-23 02:00:33 <cfields> koobs: does that use upstream binutils ?
87 2015-02-23 02:00:42 <cfields> s/upstream/gnu/
88 2015-02-23 02:01:01 <moa> Luke-Jr: https://gcc.gnu.org/projects/cxx0x.html
89 2015-02-23 02:01:25 <koobs> cfields: couldnt tell you, unlikely
90 2015-02-23 02:01:53 <cfields> koobs: i suspect that the issue likes with linking and symbol visibility
91 2015-02-23 02:02:00 <cfields> so please note the ld version as you test
92 2015-02-23 02:02:06 <cfields> *lies with
93 2015-02-23 02:02:37 <koobs> cfields: ok
94 2015-02-23 02:02:42 <koobs> 4.2.1 does with - c++: Internal error: Killed: 9 (program cc1plus)
95 2015-02-23 02:02:44 <koobs> nice.
96 2015-02-23 02:02:56 <koobs> cfields: 4.2.1 has - GNU ld 2.17.50 [FreeBSD] 2007-07-03
97 2015-02-23 02:02:57 <sipa> koobs: sounds like out of memory
98 2015-02-23 02:03:01 <Luke-Jr> koobs: that's almost always..^
99 2015-02-23 02:03:15 <koobs> sipa: youre right :)
100 2015-02-23 02:03:17 <cfields> eating, back in a few
101 2015-02-23 02:03:37 <koobs> likewise
102 2015-02-23 02:03:55 <sipa> sleeping
103 2015-02-23 02:16:51 <Luke-Jr> so 0.10 seems to have problems with block files losing data in a crash..
104 2015-02-23 02:22:51 <koobs> mm back
105 2015-02-23 02:23:29 <koobs> moar vm memory!
106 2015-02-23 02:26:47 <sipa> Luke-Jr: yes, there are increasing reports about that
107 2015-02-23 02:27:19 <sipa> i don't understand it; it should have better ordering of db writes than older files
108 2015-02-23 02:27:23 <sipa> older releases
109 2015-02-23 02:27:26 <koobs> Hmm, builds on gcc 4.2.1 too.
110 2015-02-23 02:27:32 <koobs> well that is good.
111 2015-02-23 02:28:27 <koobs> *tests daemon*
112 2015-02-23 02:29:46 <gmaxwell> sipa: libc buffering?
113 2015-02-23 02:29:51 <Luke-Jr> sipa: the block files aren't db..
114 2015-02-23 02:30:07 <gmaxwell> Luke-Jr: right the software attempts to make sure the blocks are flushed to disk before updating the database.
115 2015-02-23 02:30:36 <Luke-Jr> maybe a better solution is to just tolerate the data being missing and tell the peer he has to get it elsewhere
116 2015-02-23 02:30:41 <Luke-Jr> or maybe refetch it ourselves
117 2015-02-23 02:31:10 <Luke-Jr> otoh, I'm not sure if perhaps undo data is missing as well, which would be a bigger problem
118 2015-02-23 02:31:16 <gmaxwell> certantly with pruning that starts looking more interesting. (though it doesn't help you for undo data)
119 2015-02-23 02:31:34 <sipa> i'll have a look tomorrow
120 2015-02-23 02:32:08 <Luke-Jr> right now my only solution is to reindex I think
121 2015-02-23 02:32:42 <sipa> is this with -txindex?
122 2015-02-23 02:34:18 <Luke-Jr> sipa: yes
123 2015-02-23 02:34:30 <Luke-Jr> not sure how that's relevant though?
124 2015-02-23 02:39:58 <sipa> Luke-Jr: when do you get an error?
125 2015-02-23 02:40:33 <Luke-Jr> sipa: when a peer asks for a block that's past the end of a truncated file
126 2015-02-23 02:40:43 <Luke-Jr> the assert
127 2015-02-23 02:40:54 <sipa> ok, then txindex isn't relevant, indeed
128 2015-02-23 02:44:55 <phantomcircuit> sipa, i suspect it has to do with bad filesystem/hdd firmware
129 2015-02-23 02:45:11 <phantomcircuit> there's a lot that can go wrong from fdatasync to data on persistent storage
130 2015-02-23 02:45:38 <phantomcircuit> potentially fixing the write ordering such that it's actually pretty much back to back got the timings close enough for there to be an issue
131 2015-02-23 02:45:48 <gmaxwell> phantomcircuit: I don't think so here, behavior is reproducable with kill -9ing the process I believe.
132 2015-02-23 02:50:24 <phantomcircuit> gmaxwell, huh
133 2015-02-23 02:50:25 <antizionist__> guys
134 2015-02-23 02:50:26 <phantomcircuit> interesting
135 2015-02-23 02:50:52 <antizionist__> i m having a 100% disk usage while starting from bootstrap
136 2015-02-23 02:51:04 <antizionist__> freezing pc and all
137 2015-02-23 02:51:12 <antizionist__> any solution for this?
138 2015-02-23 02:51:25 <gmaxwell> antizionist__: get a better operating system?
139 2015-02-23 02:51:41 <gmaxwell> Sorry to not be more helpful:
140 2015-02-23 02:51:47 <Luke-Jr> don't use bootstrap perhaps will help a bit
141 2015-02-23 02:51:52 <gmaxwell> But your OS is broken if actually using your computer makes it unresponsive.
142 2015-02-23 02:52:49 <antizionist__> it s wintrash
143 2015-02-23 02:53:25 <phantomcircuit> so then gmaxwell was right
144 2015-02-23 02:53:28 <antizionist__> had to refresh it because of it
145 2015-02-23 02:53:29 <phantomcircuit> i dont see the problem
146 2015-02-23 02:53:31 <gmaxwell> if you have a lot of ram and a 64 bit operating system, turning up the dbcache setting may help.
147 2015-02-23 02:53:52 <antizionist__> how to do that?
148 2015-02-23 02:54:55 <gmaxwell> antizionist__: you find the appdata directory for bitcoin and create a bitcoin.conf and in it put in, say, dbcache=2000 (to use 2000 mbytes of ram for additional caching).
149 2015-02-23 02:55:21 <gmaxwell> or start bitcoin-qt with a -dbcache=2000 command line paramter.
150 2015-02-23 02:55:55 <antizionist__> bitcoin.conf is alreasy there
151 2015-02-23 02:56:22 <antizionist__> so i ll add the line
152 2015-02-23 02:56:57 <Luke-Jr> gmaxwell: I thought 1024 was the max?
153 2015-02-23 02:57:03 <Luke-Jr> -help says it is, anyhow
154 2015-02-23 02:57:23 <Luke-Jr> or maybe it's because I'm 32-bit
155 2015-02-23 02:58:31 <gmaxwell> Speaking of that, someone was reporting on 32bit on the forum that they were running out of address space with just 500 set.
156 2015-02-23 02:58:50 <gmaxwell> so that may already be too high.
157 2015-02-23 02:59:01 <antizionist__> so 2000 is the maximum?
158 2015-02-23 02:59:01 <Luke-Jr> I had to lower it to 5 on my USB Armory which has 512 MB RAM
159 2015-02-23 02:59:55 <cfields> koobs: any results?
160 2015-02-23 03:00:37 <koobs> cfields: so far utils/daemon (alone) build fine with gcc 4.2.1 and clang 3.4 (after removing c++0X/c++11 bits)
161 2015-02-23 03:00:52 <koobs> cfields: thats im almost done building universe dependencies for qt
162 2015-02-23 03:01:11 <koobs> cfields: cfields once im happy that builds are fine, i'll move to tests/run
163 2015-02-23 03:01:38 <koobs> cfields: robbak can provide details of the sanity test fail (but his tests are without my build changes)
164 2015-02-23 03:02:07 <sipa> antizionist__: on 64-bit, you can go really high (as long as you have physical ram for it)
165 2015-02-23 03:02:19 <cfields> koobs: er, that seems like quite a bit of wasted effort until the builds actually work :)
166 2015-02-23 03:02:20 <sipa> but over 2000 will not gain you much
167 2015-02-23 03:02:27 <antizionist__> ok let me try 4000
168 2015-02-23 03:02:47 <gmaxwell> On 64bit 4096 is the maximum. But 2000 is high enough that its pretty much effectively infinite in any case.
169 2015-02-23 03:03:10 <koobs> cfields: i dont agree, since run and tests come post build stage, whats the point of diagnosing/isolating the issues if there are issues with the build
170 2015-02-23 03:03:34 <Luke-Jr> antizionist__: also, my suggestion to not use bootstrap was serious. it doesn't gain you much with 0.10, and increases I/O load significantly
171 2015-02-23 03:03:35 <koobs> cfields: waiting < an hour to isolate the build as a variable is prudent :)
172 2015-02-23 03:03:43 <cfields> koobs: if it's a toolchain issue, it's going to present with/without qt. May as well build the minimum until you've solved the basic issue
173 2015-02-23 03:03:55 <koobs> cfields: sure
174 2015-02-23 03:04:07 <koobs> cfields: qt is almost done building, so at this point the debate is moot :)
175 2015-02-23 03:04:22 <koobs> cfields: is make check the canonical method to run the test suite?
176 2015-02-23 03:04:27 <Luke-Jr> koobs: building just bitcoind is still faster, even if the deps for qt are present
177 2015-02-23 03:04:29 <cfields> yes
178 2015-02-23 03:04:35 <antizionist__> should it delete it or rename it by adding old?
179 2015-02-23 03:04:37 <koobs> cfields: is --enable-tests a requirement for make check ?
180 2015-02-23 03:04:47 <Luke-Jr> antizionist__: up to you
181 2015-02-23 03:04:51 <koobs> Luke-Jr: of course, ive already tested utils/daemon only builds
182 2015-02-23 03:04:55 <cfields> no, it's tests are enabled for all satisfied deps
183 2015-02-23 03:05:23 <koobs> cfields: right, so what is run is based on the build
184 2015-02-23 03:05:31 <cfields> koobs: so just do a quick fire of ./bitcoind. It'll crash instantly if it hits the libstdc++ issue
185 2015-02-23 03:05:50 <koobs> cfields: that is to say, a make check post configure will build/enable/run tests only for those bits that are satisfied/enabled
186 2015-02-23 03:05:57 <koobs> cfields: understood, thanks
187 2015-02-23 03:06:09 <cfields> koobs: correct
188 2015-02-23 03:06:27 <koobs> finally a project that does good things with autotools.
189 2015-02-23 03:06:45 <koobs> praise the ngu lords.
190 2015-02-23 03:06:47 <koobs> gnu*
191 2015-02-23 03:17:46 <phantomcircuit> gmaxwell, i guess i should have actually checked the machine i had where a block read failed more carefully
192 2015-02-23 03:17:48 <phantomcircuit> oh well
193 2015-02-23 04:16:43 <Luke-Jr> hm
194 2015-02-23 04:16:49 <Luke-Jr> reindex seems to have issues with a missing block
195 2015-02-23 04:17:09 <Luke-Jr> maybe I will need to delete the files and resync from the net :/
196 2015-02-23 04:25:31 <Emcy> what does the time bar at the bottom of the window mean now in realation to headers first sync
197 2015-02-23 04:25:44 <Emcy> cos its going really slow
198 2015-02-23 04:26:02 <Emcy> 13mb received in 5 mins
199 2015-02-23 04:27:24 <koobs> does bitcoin require qt4 webkit?
200 2015-02-23 04:28:11 <Luke-Jr> koobs: ⦠this is all documented and testable.
201 2015-02-23 04:28:19 <koobs> Luke-Jr: link to docs?
202 2015-02-23 04:28:26 <koobs> Luke-Jr: im trying to untangle port dependencies
203 2015-02-23 04:28:29 <Luke-Jr> the doc/ dir
204 2015-02-23 04:28:35 <koobs> Luke-Jr: dont assume i know anything about bitcoin dev right now
205 2015-02-23 04:28:44 <koobs> Luke-Jr: thanks, any particular page/doc ?
206 2015-02-23 04:28:49 <koobs> feel free to github link me
207 2015-02-23 04:29:06 <Luke-Jr> the one that talks about dependencies.
208 2015-02-23 04:29:23 <Emcy> if its still getting headers, why does it say its processed 2000 blocks
209 2015-02-23 04:29:51 <Emcy> this is my first time watching headers first
210 2015-02-23 04:30:39 <koobs> Luke-Jr: got it: https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md
211 2015-02-23 04:34:31 <Emcy> am i doing something wrong. Do i need an open port for it to go fast
212 2015-02-23 04:34:36 <Emcy> the changelog said 3 hours
213 2015-02-23 04:45:04 <Luke-Jr> Emcy: with good hardware
214 2015-02-23 04:46:10 <cfields> koobs: see depends/qt.mk
215 2015-02-23 04:47:06 <gmaxwell> Emcy: it's 'slow' at first because it fetches fewer of the empty blocks at a time but doesn't really slow further later in the chain. Getting it into 3 hours requires a pretty fast computer and network connection.
216 2015-02-23 04:47:21 <gmaxwell> People with slow computers and network connections are reddit seem to be reporting 8 hours or so.
217 2015-02-23 04:47:57 <koobs> cfields: cant see a qt.mk in gh ?
218 2015-02-23 04:48:18 <koobs> cfields: packages/qt.mk ?
219 2015-02-23 04:48:26 <cfields> sorry, missed a dir. https://github.com/bitcoin/bitcoin/blob/master/depends/packages/qt.mk
220 2015-02-23 04:48:31 <koobs> got it
221 2015-02-23 04:48:41 <koobs> the bitcoin port currently uses qt4
222 2015-02-23 04:49:07 <cfields> configure lines are pretty much the same
223 2015-02-23 04:49:09 <koobs> cfields: the dep chain resulting in qt4-webkit is: linguist_build -> linguist -> designer -> webkit
224 2015-02-23 04:49:16 <cfields> i was just giving you a reference for what we need/don't need
225 2015-02-23 04:49:18 <koobs> cfields: yep, i might provide an option to use qt4/5
226 2015-02-23 04:49:23 <koobs> cfields: appreciate it
227 2015-02-23 04:49:46 <cfields> koobs: it's all still moot until the thing runs...
228 2015-02-23 04:49:49 <koobs> cfields: the linguist build is (was) apparently needed for translations during build, but the docs dont menjtion that
229 2015-02-23 04:50:02 <koobs> cfields: two seperate things, im cleaning up while i fix things :)
230 2015-02-23 04:50:14 <koobs> cfields: having to wait 58 minutes to build qt4-webkit bothered me enough to investigate
231 2015-02-23 04:50:40 <Emcy> gmaxwell my hardware is an i7 quad and my bandwidth here is about 18mbits
232 2015-02-23 04:51:00 <cfields> koobs: well, i need to get to bed. Feel free to ping me when you've got a crash and can help debug.
233 2015-02-23 04:51:14 <koobs> cfields: much appreciated :) sleep well
234 2015-02-23 04:51:42 <Luke-Jr> 2015-02-23 04:51:56 Reindexing finished
235 2015-02-23 04:51:46 <Luke-Jr> yet I'm stuck on the missing block
236 2015-02-23 04:52:25 <Emcy> just what i read from the changelog, it made it sound like the headers would be pulled first slowish, then all the blocks would flood in in parallel at maximum speed
237 2015-02-23 04:53:00 <Emcy> also you made the spinny thing not spin any more
238 2015-02-23 04:54:47 <cfields> koobs: fwiw, lupdate isn't needed for build, only for translators. Builders need moc/uic/rcc/lrelease
239 2015-02-23 04:54:58 <koobs> cfields: linguist?
240 2015-02-23 04:55:08 <koobs> cfields: yeh i just found : https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md
241 2015-02-23 04:55:09 <cfields> koobs: you can see the hacks we use to avoid building all tools and only those we need
242 2015-02-23 04:55:22 <koobs> cfields: when you say builders, you mean ?
243 2015-02-23 04:55:27 <koobs> just generally to build?
244 2015-02-23 04:55:33 <cfields> anyone building from source
245 2015-02-23 04:55:33 <cfields> yes
246 2015-02-23 04:55:40 <koobs> cfields: currently the freebsd port has:
247 2015-02-23 04:55:42 <koobs> USE_QT4= corelib network gui qmake_build moc_build uic_build \
248 2015-02-23 04:55:44 <koobs> rcc_build linguist_build
249 2015-02-23 04:55:49 <koobs> so it looks like all but the last is correct
250 2015-02-23 04:55:55 <gmaxwell> Emcy: thats more or less true, except the initial blocks are a little 'slowish' because it only fetches 16 at a time from each peer. Later in that chain thats more than enough to keep any link filled to whatever capacity bitcoind could handle, but for the first 100k blocks not so much.
251 2015-02-23 04:56:05 <cfields> koobs: that should work
252 2015-02-23 04:56:09 <koobs> again for 0.10.0, cfields, is qmake still needed?
253 2015-02-23 04:56:24 <cfields> koobs: no, but qmake is a qt self-dependency
254 2015-02-23 04:56:25 <Emcy> interesting. Why only 16?
255 2015-02-23 04:56:32 <koobs> cfields: i'll start with the deps declared in the docs then go from there, if it turns out anything else is needed, i'll submit a docs issue or pr
256 2015-02-23 04:56:59 <Emcy> thats seems like a large undue impediment for the first 100k block sor so, as you said
257 2015-02-23 04:57:01 <koobs> cfields: i'll remove it from the bitcoin dependency list then, ports will handle whatever is needed to build/run qt
258 2015-02-23 04:57:16 <cfields> ok
259 2015-02-23 04:57:29 <koobs> cfields: thanks again :)
260 2015-02-23 04:57:46 <cfields> oh, you're not actually building qt there..
261 2015-02-23 04:58:12 <koobs> cfields: mm?
262 2015-02-23 04:58:19 <cfields> koobs: in that case, linguist will probably be needed. Because qt splits those utils quit arbitrarily
263 2015-02-23 04:58:40 <cfields> in order to get lrelease, you'll probably need all of linguist
264 2015-02-23 04:58:49 <koobs> cfields: the builds im running are in a cleanroom (nothing installed from the start)
265 2015-02-23 04:58:51 <koobs> oh.
266 2015-02-23 04:58:56 <Emcy> how big is the chain now anyway
267 2015-02-23 04:58:57 <koobs> whats lrelease?
268 2015-02-23 04:59:57 <koobs> cfields: ignore that question, i'll figure it out
269 2015-02-23 04:59:58 <cfields> koobs: builds translations from text. Necessary for build.
270 2015-02-23 05:00:17 <koobs> cfields: i'll test, goal is to reduce the dependency list where i can
271 2015-02-23 05:00:58 <cfields> well unless you're willing to patch qt's build (unless it already happens to be patched that way) you'll need linguist
272 2015-02-23 05:01:33 <koobs> cfields: thats what i'll test for, i expect ports gives me the qt4 bits i want/declare
273 2015-02-23 05:02:52 <cfields> ok. nnite.
274 2015-02-23 05:02:57 <koobs> night :)
275 2015-02-23 05:49:24 <Luke-Jr> ACTION wonders if 0.10's invalid block markers should have indicated version that checked it, and rechecked if it was old
276 2015-02-23 05:54:18 <koobs> Hmm, --with-{utils,daemon,libs} should be using --enable.
277 2015-02-23 05:54:30 <koobs> not with (which is for referengin external packages)
278 2015-02-23 05:54:55 <Luke-Jr> yes
279 2015-02-23 05:55:15 <Luke-Jr> sad mutation of the original --with[out]-qt
280 2015-02-23 05:59:56 <koobs> Luke-Jr: now that ive gottan all the build stuff sorted, where/how do i start getting verbosity for -> "Error: Initialization sanity check failed. Bitcoin Core is shutting down."
281 2015-02-23 06:00:34 <Luke-Jr> koobs: by running the unit tests
282 2015-02-23 06:00:51 <koobs> Luke-Jr: will a debug build help?
283 2015-02-23 06:00:59 <Luke-Jr> if you want to debug it
284 2015-02-23 06:01:04 <koobs> right
285 2015-02-23 06:05:59 <koobs> Luke-Jr: i presume this isnt expected/proper test suite output: https://dpaste.de/iS3D/raw
286 2015-02-23 06:06:25 <sipa> that means the tests wete not built
287 2015-02-23 06:06:34 <koobs> do the tests require --enable-tests ?
288 2015-02-23 06:07:03 <sipa> duh...
289 2015-02-23 06:07:34 <Luke-Jr> koobs: yes
290 2015-02-23 06:08:05 <Luke-Jr> sipa: to be fair, cfields told him it didn't (and I didn't verify that)
291 2015-02-23 06:09:08 <sipa> cfields told him that make chdcks runs all tests that are built
292 2015-02-23 06:10:16 <cfields> --enable-tests is default, and turns on whatever tests it can
293 2015-02-23 06:10:34 <Luke-Jr> sipa: that wasn't how I interpreted it :x
294 2015-02-23 06:10:50 <sipa> ah
295 2015-02-23 06:11:17 <cfields> i thought it was implied that --disable-tests would turn them off :)
296 2015-02-23 06:11:35 <sipa> koobs: sorry, my "duh" wasn't very poltie; i don't actually know how common this convention is, though it seems pretty obvious to me
297 2015-02-23 06:13:03 <koobs> sipa: normally tests can be run without a configure options, and theres no additional binary to speak of
298 2015-02-23 06:13:13 <sipa> ok
299 2015-02-23 06:13:31 <koobs> sipa: re it being a common convention, one would imagine, and im a ports maintainer, so ive seen plenty of 'test suites'
300 2015-02-23 06:13:34 <cfields> koobs: './configure' by default will build tests if it can, and run them via 'make check'. there's no need to specify it.
301 2015-02-23 06:13:40 <koobs> sipa: if im confused, i can imagine what its like for non technical users
302 2015-02-23 06:13:55 <sipa> fair enough; it's good to know
303 2015-02-23 06:14:04 <koobs> cfields: i understand. what i didnt understand was the nature of the test binary and how it related to the tests
304 2015-02-23 06:14:31 <koobs> im still not clear how test_foo and foo binaries differ, with or without --enable-tests
305 2015-02-23 06:15:06 <koobs> nor what make check invokes to execute the tests, whther just tests, or tests that utilise a binary, and in the later case, whether the test binary or the 'real' one
306 2015-02-23 06:15:18 <koobs> i guess i could look at make check, but im trying to fix our port :)
307 2015-02-23 06:15:37 <sipa> make check does more than just run the test binary
308 2015-02-23 06:15:45 <sipa> there are also rpc tests in python
309 2015-02-23 06:15:51 <koobs> sipa: i didnt even know it ran the test binary, so thats a good step forward
310 2015-02-23 06:16:05 <koobs> sipa: i noted that (well robbak did) it seems theres some portability improvements that can be made ont hat front
311 2015-02-23 06:16:31 <Luke-Jr> of course, we have no BSD maintainer.. someone should step up ;
312 2015-02-23 06:16:32 <Luke-Jr> ;)
313 2015-02-23 06:16:33 <sipa> and if configured, an external java-based integration test called comparison tool
314 2015-02-23 06:16:43 <koobs> Luke-Jr: portability is <> freebsd
315 2015-02-23 06:16:47 <koobs> Luke-Jr: for what its worth :)
316 2015-02-23 06:16:51 <midnightmagic> :-)
317 2015-02-23 06:16:53 <midnightmagic> \o
318 2015-02-23 06:17:04 <Luke-Jr> koobs: well, it works on Mac, Linux, and Windows.. pretty portable :p
319 2015-02-23 06:17:10 <koobs> Luke-Jr: but i get what you are getting at, strawman aside ;)
320 2015-02-23 06:17:21 <midnightmagic> it works on NetBSD too. At least, it syncs.
321 2015-02-23 06:17:24 <koobs> Luke-Jr: they may just be doing the hard work for you :)
322 2015-02-23 06:17:51 <koobs> Luke-Jr: but let's not digress, im here (and i presume you are) to make bitcoin as good as it can be
323 2015-02-23 06:18:01 <midnightmagic> (and the tests suite appears to run)
324 2015-02-23 06:18:08 <midnightmagic> (and testnet syncs)
325 2015-02-23 06:18:10 <Luke-Jr> âº
326 2015-02-23 06:18:43 <sipa> koobs: thanks!
327 2015-02-23 06:18:46 <midnightmagic> hey man you've switched to different symbols since I modified my font to see all your other ones
328 2015-02-23 06:18:48 <koobs> is the test binary *always* called 'test_bitcoin' (that is, for utils-only, daemon-only and gui-only builds as well) ?
329 2015-02-23 06:18:53 <Luke-Jr> midnightmagic: nope
330 2015-02-23 06:19:27 <Luke-Jr> koobs: test_bitcoin is always named as such, and independent from the utils/daemon/gui builds somewhat
331 2015-02-23 06:19:40 <koobs> mmm
332 2015-02-23 06:19:43 <Luke-Jr> personally I consider it "part" of libbitcoinconsensus
333 2015-02-23 06:19:52 <Luke-Jr> although it tests more than that of course
334 2015-02-23 06:19:52 <sipa> there are unit test binaries for libsecp and for qt as well
335 2015-02-23 06:20:19 <robbak> Luke-Jr: Well, I have been trying to do that, but I do have a skills deficit!
336 2015-02-23 06:22:50 <koobs> ok, time to add a tests option and set it to default
337 2015-02-23 06:26:09 <koobs> building with tests ...
338 2015-02-23 06:28:00 <koobs> Is there a way to not use the bundled LevelDB distribution? More precisely, bits to make it use an already installed version?
339 2015-02-23 06:28:17 <Luke-Jr> koobs: yes, but that's often a bad idea
340 2015-02-23 06:28:24 <koobs> Luke-Jr: qualify please? :)
341 2015-02-23 06:28:38 <Luke-Jr> koobs: LevelDB does not guarantee consensus compatibility between versions, which Bitcoin breaks without
342 2015-02-23 06:28:49 <koobs> Luke-Jr: between nodes?
343 2015-02-23 06:28:51 <koobs> or locally ?
344 2015-02-23 06:29:04 <Luke-Jr> globally
345 2015-02-23 06:29:15 <Luke-Jr> koobs: so to use a system LevelDB safely, you need to guarantee it does not break consensus-compatibility
346 2015-02-23 06:29:33 <Luke-Jr> which means using only versions someone has audited to be sure it's consensus-compatible, and disabling snappy compression
347 2015-02-23 06:29:46 <Luke-Jr> most systems can't do this
348 2015-02-23 06:29:49 <sipa> koobs: basically, if a bug in leveldb would be fixed, that could theoretically impact bitcoin's consensus, and we may prefer to not fix it in our version
349 2015-02-23 06:30:00 <koobs> Luke-Jr: consensus compatbility between what and what is my question
350 2015-02-23 06:30:04 <sipa> the chance for this is small, but it's not impossible
351 2015-02-23 06:30:12 <Luke-Jr> koobs: between all nodes
352 2015-02-23 06:30:17 <koobs> Luke-Jr: right
353 2015-02-23 06:30:19 <Luke-Jr> koobs: what sipa said
354 2015-02-23 06:30:28 <Luke-Jr> if LevelDB 1.19 fixes a bug, it will break Bitcoin
355 2015-02-23 06:30:31 <sipa> koobs: consensus compatibility means "do not ever change observable behaviour, even if it for a bug fix"
356 2015-02-23 06:30:40 <sipa> s/will/may/
357 2015-02-23 06:30:42 <Luke-Jr> s/will/quite possibly may/
358 2015-02-23 06:30:52 <koobs> Luke-Jr: so there's a requirement that all nodes are compatible in that manner, which relies on (from a fragmented leveldb implementation point of view) on bundling a leveldb version core/upstream is confident in
359 2015-02-23 06:31:15 <koobs> Luke-Jr: so effectively a fork
360 2015-02-23 06:31:16 <midnightmagic> koobs: current, functional versions, and future bitcoin versions whose underlying libraries change out from under them and prevent a block from otherwise being accepted. An related example of this has happened more than once in bitcoin's past.
361 2015-02-23 06:31:23 <Luke-Jr> koobs: you can de-bundle it safely, as long as those conditions are met - but it's very bad if you can't guarantee that
362 2015-02-23 06:31:38 <sipa> in maybe easier terms: we have stronger than usual requirements, and do our own qa on top of their upstream
363 2015-02-23 06:31:39 <koobs> Luke-Jr: our leveldb port has options for snappy (can be enabled or disabled)
364 2015-02-23 06:31:47 <koobs> Luke-Jr: so in that regard probably not (guarantee that is)
365 2015-02-23 06:32:01 <koobs> is there any work to decouple the compatibility from leveldb?
366 2015-02-23 06:32:34 <sipa> koobs: no, that would mean not using it
367 2015-02-23 06:32:39 <Luke-Jr> koobs: for example, Gentoo allows a dependency on specific tested leveldb versions, and only with snappy disabled - so we can get away with using the system install; but unless you can be that descriptive in the dependency, you'd best use the bundle
368 2015-02-23 06:33:19 <koobs> Luke-Jr: sure, i could create a leveldb version in ports pinned to a version compatible, and force snappy cop off
369 2015-02-23 06:33:32 <koobs> Luke-Jr: and have bitcoin depend on that, which is effectively the same as the bundled dist
370 2015-02-23 06:33:34 <Luke-Jr> koobs: eh, wouldn't that defeat the point?
371 2015-02-23 06:33:51 <koobs> Luke-Jr: you prempted me, my statement wasnt a position that that would be better :)
372 2015-02-23 06:34:09 <koobs> having said that, why does gentoo do that
373 2015-02-23 06:34:10 <sipa> leveldb is small, and only linked in statically
374 2015-02-23 06:34:24 <sipa> so i think there is little benefit in decoupling
375 2015-02-23 06:34:26 <Luke-Jr> koobs: because it can? :p
376 2015-02-23 06:34:31 <koobs> to no benefit?
377 2015-02-23 06:34:44 <koobs> i was hoping they had a compelling rationale :)
378 2015-02-23 06:34:44 <Luke-Jr> koobs: the usual shared library benefits
379 2015-02-23 06:34:48 <koobs> right
380 2015-02-23 06:35:00 <koobs> perhaps warranted then
381 2015-02-23 06:35:21 <koobs> Luke-Jr: other than the config requirements (version and compression) - are there any other changes upstream from the default distribution?
382 2015-02-23 06:35:34 <sipa> we used to have some differences
383 2015-02-23 06:35:45 <Luke-Jr> koobs: yes, actually⦠BSD support being one of them :p
384 2015-02-23 06:35:59 <sipa> right now, only the addition of mingw build, and disabling snappy
385 2015-02-23 06:36:01 <koobs> Luke-Jr: im confused, leveldb works fine on freebsd :)
386 2015-02-23 06:36:02 <sipa> Luke-Jr: huh?
387 2015-02-23 06:36:32 <Luke-Jr> GNU/kFreeBSD specifically
388 2015-02-23 06:37:09 <koobs> i'll let you off on that one :)
389 2015-02-23 06:37:15 <koobs> Luke-Jr: https://dpaste.de/YcC8/raw
390 2015-02-23 06:37:17 <Luke-Jr> koobs: does FreeBSD have fdatasync btw?
391 2015-02-23 06:37:23 <koobs> ignore the python failure, its likely a invocation issue
392 2015-02-23 06:37:32 <koobs> Luke-Jr: fdatasync(2) ?
393 2015-02-23 06:37:46 <Luke-Jr> yes
394 2015-02-23 06:38:00 <Luke-Jr> for some reason, LevelDB has that disabled on FreeBSD - and on Mac, but Bitcoin reenables it on Mac :o
395 2015-02-23 06:38:01 <koobs> not that i can see on 9-stable
396 2015-02-23 06:38:03 <koobs> linuxism?
397 2015-02-23 06:38:07 <Luke-Jr> ah, ok then
398 2015-02-23 06:38:22 <koobs> theres this though :) https://lists.freebsd.org/pipermail/freebsd-bugs/2004-March/006076.html
399 2015-02-23 06:38:46 <koobs> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=64875
400 2015-02-23 06:39:04 <koobs> stale.
401 2015-02-23 06:39:10 <Luke-Jr> koobs: stick a breakpoint on glibc_sanity_test and glibcxx_sanity_test
402 2015-02-23 06:39:20 <koobs> Luke-Jr: im going to need halp with that
403 2015-02-23 06:39:32 <koobs> Luke-Jr: this is a debug build if that helps
404 2015-02-23 06:39:37 <Luke-Jr> :/
405 2015-02-23 06:39:44 <Luke-Jr> gdb src/test/test_bitcoin
406 2015-02-23 06:39:49 <Luke-Jr> break glibc_sanity_test
407 2015-02-23 06:39:51 <Luke-Jr> break glibcxx_sanity_test
408 2015-02-23 06:39:53 <Luke-Jr> run
409 2015-02-23 06:40:03 <cfields> 99% it's in that catch/throw
410 2015-02-23 06:40:25 <cfields> koobs: really, it'd be helpful if you'd build with --disable-reduced-exports
411 2015-02-23 06:41:10 <koobs> cfields: i can and will
412 2015-02-23 06:42:41 <koobs> Luke-Jr: https://dpaste.de/6AEQ/raw
413 2015-02-23 06:43:02 <Luke-Jr> that's.. unexpected
414 2015-02-23 06:43:41 <koobs> ill build with --disable-reduced-exports
415 2015-02-23 06:43:43 <koobs> tick
416 2015-02-23 06:43:50 <koobs> Luke-Jr: if it helps, this is a daemon-only build
417 2015-02-23 06:45:17 <koobs> and *not* with --enable-hardening
418 2015-02-23 06:47:00 <koobs> cfields: werent you sleeping ?
419 2015-02-23 06:47:17 <sipa> no, i was
420 2015-02-23 06:47:36 <sipa> still recovering from jetlag
421 2015-02-23 06:48:39 <Luke-Jr> sipa: I'm still recovering from our walk in the 'park' :P
422 2015-02-23 06:49:00 <sipa> lol, what?
423 2015-02-23 06:49:06 <Luke-Jr> my legs :<
424 2015-02-23 06:49:17 <sipa> you need exercise
425 2015-02-23 06:49:26 <Luke-Jr> now you sound like my wife :p
426 2015-02-23 06:49:49 <koobs> Luke-Jr: same issue (with --disable-reduced-exports)
427 2015-02-23 06:49:54 <koobs> https://dpaste.de/nJzj/raw
428 2015-02-23 06:49:59 <sipa> Luke-Jr: i'd say she's right :D
429 2015-02-23 06:50:15 <Luke-Jr> she tends to be on these things <.<
430 2015-02-23 06:51:44 <cfields> koobs: compat/glibcxx_sanity.cpp. line 60. Remove each test (1by1) and make check until the tests pass
431 2015-02-23 06:52:08 <cfields> koobs: start by removing the last one (sanity_test_range_fmt)
432 2015-02-23 06:52:35 <Luke-Jr> cfields: how is it even getting there with the breakpoints not hitting?
433 2015-02-23 06:53:34 <cfields> Luke-Jr: no clue. easier not to fight with it though, imo
434 2015-02-23 06:56:02 <koobs> cfields: i presume in bool glibcxx_sanity_test() i just remove the reference to _fmt ?
435 2015-02-23 06:56:39 <cfields> return sanity_test_widen('a') && sanity_test_list(100);
436 2015-02-23 06:57:28 <koobs> yep
437 2015-02-23 06:57:41 <koobs> doesnt seem to be fmt
438 2015-02-23 06:58:05 <cfields> (i'll PR a change to split those up, since they've been popping up lately)
439 2015-02-23 06:59:30 <koobs> hmm wait, i need to recompile test)bitcoin i presume :D
440 2015-02-23 06:59:35 <koobs> brb quick shop run
441 2015-02-23 07:00:14 <cfields> back to bed, nnite
442 2015-02-23 07:27:45 <koobs> ok back
443 2015-02-23 07:36:07 <koobs> cfields Luke-Jr sipa its fmt
444 2015-02-23 07:38:56 <Luke-Jr> koobs: that means your std::string is broken and doesn't throw an exception on out-of-range values to .at()
445 2015-02-23 07:40:10 <koobs> Luke-Jr: this is clang 3.4
446 2015-02-23 07:40:23 <koobs> do you see this on any other platforms with 3.4 ?
447 2015-02-23 07:40:44 <Luke-Jr> dunno, I only have 3.5 at the moment
448 2015-02-23 07:41:06 <koobs> could it be throwing a different exception?
449 2015-02-23 07:41:19 <cfields> koobs: yes, i've seen this on clang 3.4
450 2015-02-23 07:41:23 <Luke-Jr> possible, but any other exception is breaking spec I think
451 2015-02-23 07:41:24 <cfields> koobs: can you build clang with a patch?
452 2015-02-23 07:41:24 <koobs> cfields: right
453 2015-02-23 07:41:32 <koobs> cfields: well, i could.
454 2015-02-23 07:41:59 <koobs> cfields: if i can see a bug id, or commit ref, i can check whether its been fixed in base
455 2015-02-23 07:42:01 <koobs> may not be required
456 2015-02-23 07:42:16 <cfields> koobs: i've bissected myself. It's fixed in 3.5.
457 2015-02-23 07:42:16 <koobs> i *am* running 9-stable, a month of so from head of branch
458 2015-02-23 07:42:32 <cfields> *bisected
459 2015-02-23 07:42:32 <Luke-Jr> cfields: why do we even have this check? it doesn't look like we use it?
460 2015-02-23 07:42:47 <koobs> can we have the test print the exception insteasd of returning false?
461 2015-02-23 07:42:51 <cfields> Luke-Jr: it's used in back-compat
462 2015-02-23 07:43:02 <koobs> in the test
463 2015-02-23 07:43:09 <Luke-Jr> oh
464 2015-02-23 07:44:18 <Luke-Jr> btw, the option appears to actually be --disable-reduce-exports, not reduceD
465 2015-02-23 07:46:03 <cfields> koobs: if it's the same error i've seen before, llvm 3.4 needs this backported: https://github.com/llvm-mirror/llvm/commit/b09f5054454d99002a69aa57b7c19094aadde9ad
466 2015-02-23 07:46:32 <koobs> cfields: roger, i'll touch base with our clang gurus and get back to you
467 2015-02-23 07:47:10 <cfields> koobs: that affects osx's clang build with 3.4. No idea if it has the same effect in fbsd though.
468 2015-02-23 07:47:33 <koobs> cfields: will testing against clang35 isolate?
469 2015-02-23 07:47:38 <cfields> yes
470 2015-02-23 07:47:43 <cfields> or 3.3
471 2015-02-23 07:47:49 <koobs> ill do that
472 2015-02-23 07:48:08 <koobs> cfields: if it matters, we're 3.4.1
473 2015-02-23 07:48:26 <cfields> koobs: doesn't matter.
474 2015-02-23 07:48:40 <cfields> iirc most recent is 3.4.2, still not fixed there
475 2015-02-23 07:48:45 <koobs> is there a workaround thats possible (local port patch) for 3.4 ?
476 2015-02-23 07:49:02 <cfields> i haven't been able to verify that it's not my weird setup, otherwise i'd report to upstream
477 2015-02-23 07:49:07 <koobs> cfields: and more importantly, is the sanity failure in the test still valid?
478 2015-02-23 07:49:10 <cfields> yes, the one i just pasted
479 2015-02-23 07:49:19 <koobs> cfields: i meant in bitcoin
480 2015-02-23 07:49:55 <koobs> cfields: is Luke's comment about std::string exceptions still relevant in light of the llvm change you mentioned?
481 2015-02-23 07:50:35 <cfields> koobs: whether we use that particular exception or not, the test failure is indicative of unreliable exception handling
482 2015-02-23 07:50:59 <cfields> i'm not sure what you're asking
483 2015-02-23 07:51:22 <koobs> cfields: im going to speak to our clang/llvm people, i want to know what to include (and not include) when reporting it
484 2015-02-23 07:51:34 <koobs> cfields: if luke's comment is relevent, i'll include it, if not, i wont
485 2015-02-23 07:52:12 <cfields> koobs: first try building with clang 3.5/3.3. If they also fail, you can ignore everything i've said as we're talking about different bugs
486 2015-02-23 07:52:31 <koobs> ok
487 2015-02-23 07:52:33 <koobs> ill do that first
488 2015-02-23 07:52:40 <cfields> if they succeed, i'll give you a small test-case that you can use for reporting
489 2015-02-23 07:53:50 <koobs> cfields: danke
490 2015-02-23 07:54:11 <cfields> actually, sec
491 2015-02-23 07:54:59 <cfields> koobs: http://pastebin.com/raw.php?i=N5GDgfQC
492 2015-02-23 07:55:13 <cfields> you don't need to mess with all of bitcoin, ^^ is enough to verify good/bad clang
493 2015-02-23 07:55:20 <koobs> roger :)
494 2015-02-23 07:55:26 <cfields> clang++ test.cpp -o test && ./test
495 2015-02-23 07:55:30 <koobs> <3
496 2015-02-23 07:59:19 <koobs> cfields: hmm, no output from ./test with 3.4.1 from that test case
497 2015-02-23 07:59:45 <sergiohlb> hello
498 2015-02-23 08:03:07 <cfields> koobs: try http://pastebin.com/raw.php?i=GcWQLfaY
499 2015-02-23 08:03:23 <cfields> clang++ -fvisibility=hidden test.cpp -o test
500 2015-02-23 08:04:44 <koobs> cfields: including the trailing ~ ?
501 2015-02-23 08:05:00 <cfields> whoops, stupid vi. no.
502 2015-02-23 08:05:15 <koobs> test.cpp:12:1: warning: control may reach end of non-void function [-Wreturn-type]
503 2015-02-23 08:05:16 <koobs> }
504 2015-02-23 08:05:18 <koobs> ^
505 2015-02-23 08:05:20 <koobs> 1 warning generated.
506 2015-02-23 08:05:22 <koobs> :)
507 2015-02-23 08:05:39 <koobs> ./test runs without output
508 2015-02-23 08:05:59 <cfields> ugh, ok
509 2015-02-23 08:06:17 <cfields> I'll bite the bullet and setup a fbsd vm tomorrow
510 2015-02-23 08:06:25 <koobs> i can give you an account if you like
511 2015-02-23 08:06:47 <cfields> not sure how to tell you how to debug remotely. Lots of things to poke/prod
512 2015-02-23 08:06:50 <cfields> sure, that'd be helpful
513 2015-02-23 08:06:53 <koobs> roger
514 2015-02-23 08:07:01 <koobs> cfields: pm me pubkey
515 2015-02-23 08:07:16 <koobs> and desired username
516 2015-02-23 09:03:43 <fanquake> ;;blocks
517 2015-02-23 09:03:44 <gribble> 344790
518 2015-02-23 10:24:58 <gdm85> hi there. suggestions to generate a large swath of testnet addresses and then import the private keys in core wallet?
519 2015-02-23 10:25:33 <Luke-Jr> getnewaddress many times?
520 2015-02-23 10:26:03 <gdm85> Luke-Jr: but that's hardly quick :\
521 2015-02-23 10:26:26 <Luke-Jr> use a batch RPC call
522 2015-02-23 10:26:44 <Luke-Jr> I suppose you could do a HD seed and make lots with pycoin
523 2015-02-23 10:33:16 <gdm85> mmh..maybe I should give that a try.
524 2015-02-23 10:48:55 <sipa> gdm85: use importwallet rpc
525 2015-02-23 10:50:29 <gdm85> sipa: wouldn't that need to check all addresses, thus be a bit slow too on large amount of keys?
526 2015-02-23 10:50:56 <sipa> define 'check all adresses'
527 2015-02-23 10:51:37 <gdm85> checking if they are valid
528 2015-02-23 10:51:54 <sipa> that takes around 100us or so
529 2015-02-23 10:52:10 <sipa> less
530 2015-02-23 10:52:10 <sipa> or less
531 2015-02-23 10:52:40 <sipa> i expect bdb to be slower, for storing the data about the key
532 2015-02-23 10:53:03 <gdm85> so it will not (attempt to) load the transactions associated to the newly imported keys
533 2015-02-23 10:53:30 <sipa> rescanning is separate
534 2015-02-23 10:53:41 <sipa> but you only need to do that once for all addresses
535 2015-02-23 10:54:01 <sipa> rtfm
536 2015-02-23 10:55:02 <gdm85> "This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes."
537 2015-02-23 10:55:41 <gdm85> this is not cutting the knot, about rescanning behavior ;)
538 2015-02-23 10:56:46 <sipa> you can skip rescanning
539 2015-02-23 10:56:55 <sipa> if you kniw the addresses are unused
540 2015-02-23 10:56:58 <sipa> *know
541 2015-02-23 10:57:00 <gdm85> yes, that's the case.
542 2015-02-23 10:57:09 <sipa> the importwallet format has a tinestamp per key
543 2015-02-23 10:57:30 <sipa> if you set that tinestamp to something recent, rescan will be fast
544 2015-02-23 11:05:19 <gdm85> I think I will use vanitygen and then importwallet, thanks!
545 2015-02-23 11:09:08 <phantomcircuit> gdm85, getnewaddress is going to be faster than that IF you have the datadir on a tmpfs
546 2015-02-23 11:09:27 <phantomcircuit> literally the only speed issue with getnewaddress is the fdatasync calls bdb makes
547 2015-02-23 11:09:33 <phantomcircuit> (iirc it's like a dozen per key)
548 2015-02-23 11:12:14 <gdm85> whoa
549 2015-02-23 11:12:57 <gdm85> phantomcircuit: I understand what you mean, but I am not sure I want to trade RAM for speed when I want to run many of these bitcoind's for testing purposes.
550 2015-02-23 11:15:06 <gdm85> any FMs about how reserve= and change= meaning in the dump wallet format? I'd like to know what to set them to for my generated addresses.
551 2015-02-23 11:15:33 <gdm85> intuitively, I think I'd set all of them to reserve=1
552 2015-02-23 11:15:44 <sipa> reserve is not very useful
553 2015-02-23 11:16:01 <sipa> they're essentially lost if you do
554 2015-02-23 11:16:14 <gdm85> in what status are addresses generated with keypool?
555 2015-02-23 11:16:22 <sipa> reserve
556 2015-02-23 11:16:27 <sipa> but they're not imported that way
557 2015-02-23 11:17:29 <gdm85> mmh..so if I want these newly imported addresses to be quickly accessible via getnewaddress, should they have any extra variable specification?
558 2015-02-23 11:17:55 <sipa> getnewaddress will always give you new addresses
559 2015-02-23 11:18:11 <sipa> not imported addresses
560 2015-02-23 11:18:17 <gdm85> right.
561 2015-02-23 11:36:14 <sipa> anyone able to build/run libsecp256k1 on a big-endian system? wumpus?
562 2015-02-23 11:36:35 <sipa> a test of #216 would be nice
563 2015-02-23 12:01:59 <wumpus> sure
564 2015-02-23 12:10:44 <bedeho> How does an SPV wallet figure out the total amount of funds associated with utxos of a given address? There is no wire message for anything like this, and I suppose you could not trust under reporting from full nodes anyway?
565 2015-02-23 12:11:20 <sipa> bedeho: it cannot
566 2015-02-23 12:11:30 <sipa> peers can withhold information
567 2015-02-23 12:11:50 <bedeho> exactly, so how is this actually done then? because lots of SPV wallets seem to do this?
568 2015-02-23 12:12:58 <Belxjander> bedeho: multiple full node queries with cross-comparison maybe?
569 2015-02-23 12:13:25 <sipa> bedeho: SPV wallets trust that at least full node is honest about this
570 2015-02-23 12:13:32 <bedeho> Belxjander: so even if you have honest full nodes, I dont see any practical way of doing this with the bitcoin wire protocol
571 2015-02-23 12:13:35 <sipa> bedeho: note that peers can't lie about credits
572 2015-02-23 12:13:48 <sipa> only about absence of spends
573 2015-02-23 12:14:11 <justanotheruser> *without cost
574 2015-02-23 12:14:15 <sipa> (or absence of credits)
575 2015-02-23 12:14:32 <gmaxwell> well can't like about credits, unless they have non-trivial hashpower.
576 2015-02-23 12:14:37 <gmaxwell> er s/like/lie/
577 2015-02-23 12:14:39 <sipa> under the SPV trust model of course; meaning no miner collusion, no sybil attack
578 2015-02-23 12:14:45 <bedeho> sipa: yes, but what wire message can you send to ask this question?
579 2015-02-23 12:14:48 <gmaxwell> (and are willing to undertake a costly attack)
580 2015-02-23 12:14:54 <sipa> bedeho: you sync transactions
581 2015-02-23 12:15:07 <sipa> bedeho: getdata for blocks
582 2015-02-23 12:15:57 <sipa> optionally partial blocks
583 2015-02-23 12:17:06 <bedeho> so I am thinking of situation where the wallet only knows the address, which may have utxo which are arbitrarily old, not only new ones. I dont see a wire message for "sync transactions", or am I missing something.
584 2015-02-23 12:17:26 <sipa> you have to synchronize history
585 2015-02-23 12:17:40 <sipa> there is no trustless way to ask for utxos
586 2015-02-23 12:18:42 <bedeho> I am not sure I understand what that means in practice, are you saying you have to download and parse all blocks even as a SPV wallet?
587 2015-02-23 12:19:19 <hearn> you use the getdata/getblocks commands
588 2015-02-23 12:19:19 <sipa> yes
589 2015-02-23 12:19:26 <sipa> but you can ask for filtered blocks
590 2015-02-23 12:19:29 <hearn> you might want to read the sources of such a wallet to see how it's done
591 2015-02-23 12:19:50 <sipa> which allow peers to hide transactions from you, but not lie about the ones they include
592 2015-02-23 12:20:09 <sipa> see BIP 37
593 2015-02-23 12:20:58 <bedeho> yes, I have read it, but I only thought it was used for new transactions, never considered this synching process.
594 2015-02-23 12:21:24 <bedeho> sipa: thanks
595 2015-02-23 12:25:21 <bedeho> hearn: is this where bitcoinj does this synching step https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/kits/WalletAppKit.java
596 2015-02-23 12:32:42 <stonecoldpat> thats just a class to make it easier, it will be in the peer group and wallet classes
597 2015-02-23 12:33:07 <stonecoldpat> so peergroup has a group of peers, and a peer will download the blockchain and check if you own it, if you own it its the wallet class that handles that (and then stored in the wallet file)
598 2015-02-23 12:33:19 <stonecoldpat> from my understanding *
599 2015-02-23 12:33:55 <stonecoldpat> (peer.java, peergroup.java, wallet.java)
600 2015-02-23 12:48:55 <wumpus> sipa: fails on mipsbe32, http://hastebin.com/ukozefolud.hs , for reference I've tried the tests w/ master and they passed
601 2015-02-23 12:49:47 <sipa> wumpus: interesting, thanls
602 2015-02-23 12:49:51 <sipa> *thanks
603 2015-02-23 12:50:39 <sipa> wumpus: is WORDS_BIGENDIAN defined?
604 2015-02-23 12:52:53 <bedeho> stonecoldpat : thanks
605 2015-02-23 12:58:19 <sipa> wumpus: could you try again?
606 2015-02-23 13:03:30 <wumpus> sipa: seems tot have improved it, at least it keeps running now
607 2015-02-23 13:06:19 <vayvanne> bitcoin-cli getnetworkinfo gives startup time IP addresses. the actual are changed many times since then. this causes impossible incoming connections.
608 2015-02-23 13:08:02 <wumpus> I don't get it - how can impossible incoming connections exist?
609 2015-02-23 13:08:19 <wumpus> that must mean something is misreported?
610 2015-02-23 13:09:16 <sipa> wumpus: awesome, thanks
611 2015-02-23 13:09:25 <gmaxwell> I think he's saying that getnetworkinfo gives his address at startup time, but it has since changed and he believes it inhibits incoming connections.
612 2015-02-23 13:09:30 <sipa> oh, not finished yet?
613 2015-02-23 13:09:45 <wumpus> sipa: it just finished, succesfully
614 2015-02-23 13:10:10 <gmaxwell> vayvanne: If that was a correct understanding of your statement; getnetworkinfo is not all the information bitcoin uses for incoming connections. You can happily recieve incomming connections even when it is wrong.
615 2015-02-23 13:12:11 <wumpus> yes the advertizing mechinism now just advertises the address that outgoing peers give it, so even though it may pick up some incorrect addresses along the way, it will also advertize the correct address
616 2015-02-23 13:13:43 <vayvanne> gmaxwell yes that is right. incoming connections works for some time only after startup. I see correct external IPs in version messages. will try to manually map port on router to resolve this.
617 2015-02-23 13:14:01 <wumpus> (at least if you're talking about 0.10, pre-0.10 only discovered the external IP at startup)
618 2015-02-23 13:14:20 <gmaxwell> well if the port isn't mapped anymore then indeed the new behavior cannot help that.
619 2015-02-23 13:15:18 <wumpus> that shouldn't happen though
620 2015-02-23 13:15:24 <vayvanne> yes I run v. 0.10. with old ISP it worked well using only UPnP. but version was 0.9.3
621 2015-02-23 13:16:09 <wumpus> (although I'm sure there are plenty of buggy routers that lose forwardings when IP changes, but there's nothing to be done then)
622 2015-02-23 13:17:24 <gmaxwell> nothing should have changed that could have made that work _worse_.
623 2015-02-23 13:17:40 <gmaxwell> the old behavior only ever fetched the addresses at startup and would never learn new ones.
624 2015-02-23 14:00:29 <koobs> PASS: test/test_bitcoin
625 2015-02-23 14:00:31 <koobs> FAIL: test/bitcoin-util-test.py
626 2015-02-23 14:00:36 <koobs> \o/ * 0.5
627 2015-02-23 14:00:46 <koobs> robbak: ^^
628 2015-02-23 14:01:04 <koobs> Luke-Jr cfields --disable-reduce-exports prevents sanity test from failing
629 2015-02-23 14:01:20 <koobs> I'll submit a PR for your horrible error messaging saying use --disable-reduced-exports
630 2015-02-23 15:21:41 <vayvanne> gmaxwell any chance to change debug options without restart?
631 2015-02-23 15:22:30 <sipa> no